Welcome to Windows Communication Foundation (WCF)
Top Tasks :

WCF Team Bloggers

Browse by Tags

All Tags » Bindings » Transport Security   (RSS)

  • Mapping Credentials to Authentication Schemes

    You may have noticed that an HTTP binding is configured with an HttpClientCredentialType whereas an HTTP binding element is configured with an AuthenticationScheme. How are these two settings related? If you want to switch between a custom binding and a standard binding for HTTP, then you need to know how to do the translation. Here's how client credentials map to authentication schemes: HttpClientCredentialType.None becomes AuthenticationSchemes.Anonymous HttpClientCredentialType.Certificate also becomes AuthenticationSchemes.Anonymous. Certificates are used with HTTPS rather than as authentication credentials on top of HTTP. This will be caught in validation if you try to use certificates with the TransportCredentialOnly security mode. HttpClientCredentialType.Basic becomes AuthenticationSchemes.Basic HttpClientCredentialType.Digest becomes AuthenticationSchemes.Digest HttpClientCredentialType.Ntlm becomes AuthenticationSchemes.Ntlm HttpClientCredentialType.Windows becomes AuthenticationSchemes.Negotiate Translation works the same way with proxy credentials and the proxy authentication scheme except that proxies don't have to worry about the issue with certificates. Next time: Get a Real XML Parser Read More...
  • Supporting Multiple Security Mechanisms

    How do I write a service that gives clients the option to choose between different security mechanisms for protecting a service call? For example, how can I allow clients to choose between certificates and passwords? I think that if the example choice had been between message security and transport security, then many people would have immediately suggested having two bindings for the different security mechanisms hosted on two different endpoints of the same service. There's no reason why you couldn't use the same strategy in this case where the alternatives are two different kinds of message security. The binding configuration process involves a series of choices, including choosing from enumerations of security mechanisms. It's difficult to craft configurations that accept a wide range of valid formats at the same time. This choice of configurations can of course also be made less apparent by moving the choice farther away from the service endpoint. If you create an abstraction by defining an intermediate credential type, then the service endpoint is simplified by only accepting the intermediate credentials and the choice is offered by giving multiple mechanisms to obtain those intermediate credentials. Next time: Trace Transfer Read More...
  • Preventing Anonymous Access

    How do I prevent clients from accessing my service anonymously? I've changed the settings in IIS from Anonymous Access to Integrated Windows Authentication. However, now I'm getting the error message: "Security settings for this service require 'Anonymous' Authentication but it is not enabled for the IIS application that hosts this service." Disabling anonymous access requires coordinating the settings in IIS and in your service configuration. Those two sources must be in agreement about whether anonymous access is expected. IIS is already using Windows authentication in this case, so let's look at what needs to happen to the service configuration file. I'm assuming that this is IIS6 so the only network transport we're talking about here is HTTP. There are two cases depending on whether you want the protocol that gets exposed to be HTTP or HTTPS. The simplest is to keep using HTTP since that's probably what you were using if anonymous access was allowed in the past. To switch off anonymous access with HTTP, you need to set the security mode to TransportCredentialOnly. < basicHttpBinding > < binding > < security mode ="TransportCredentialOnly" > < transport clientCredentialType ="Windows" /> </ security > </ binding > </ basicHttpBinding > Note that TransportCredentialOnly is not supported for every binding (in this case we're using BasicHttp). For WSHttp, the only choice is going to be to use HTTPS. To switch off anonymous access with HTTPS, you need to set the security mode to Transport. < wsHttpBinding > < binding > < security mode ="Transport" > < transport clientCredentialType ="Windows" /> </ security > </ binding > </ wsHttpBinding > Other bindings can be made to work in this situation as well, including custom bindings. I'm just showing you the most common examples. The key in both cases though is that we're getting transport security with the right kind of credentials associated. Next time: Writing Binding Element Essentials Read More...
  • Which Client Credential Does TransportWithMessageCredential Use?

    I’m trying to use a Certificate credential with security mode TransportWithMessageCredential. Certificate credentials were working with transport security but now my clients can’t connect. Why isn’t this working? This one is fairly quick to diagnose if you look at what your service is telling you. I’ve set up a service with the WSHttpBinding and the security mode set to TransportWithMessageCredential. What’s probably gone wrong is that the configuration is setting the transport client credential type to Certificate. binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.Certificate; Let’s look at what the service metadata says that is doing. < wsHttpBinding > < binding name ="WSHttpBinding_Service" closeTimeout ="00:01:00" openTimeout ="00:01:00" receiveTimeout ="00:10:00" sendTimeout ="00:01:00" bypassProxyOnLocal ="false" transactionFlow ="false" hostNameComparisonMode ="StrongWildcard" maxBufferPoolSize ="524288" maxReceivedMessageSize ="65536" messageEncoding ="Text" textEncoding ="utf-8" useDefaultWebProxy ="true" allowCookies ="false" > < readerQuotas maxDepth ="32" maxStringContentLength ="8192" maxArrayLength ="16384" maxBytesPerRead ="4096" maxNameTableCharCount ="16384" /> < reliableSession ordered ="true" inactivityTimeout ="00:10:00" enabled ="false" /> < security mode ="TransportWithMessageCredential" > < transport clientCredentialType ="None" proxyCredentialType ="None" realm ="" /> < message clientCredentialType ="Windows" negotiateServiceCredential ="true" algorithmSuite ="Default" establishSecurityContext ="true" /> </ security > </ binding > </ wsHttpBinding > Hmm, the transport client credential type seems to be ignoring the setting and the message client credential type is Windows. What’s going on is that TransportWithMessageCredential only uses the message security credentials. The transport (HTTPS in this case) is locked to anonymous authentication and the message credentials are using Windows because that’s the default if you don’t change any of the settings. The mismatch between Windows and Certificate credentials are why the clients are failing. We can fix this by changing the client credential type line to set the message security credentials instead. binding.Security.Message.ClientCredentialType = MessageCredentialType.Certificate; Now, the security block in the metadata gives us exactly what we want. < security mode ="TransportWithMessageCredential" Read More...

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us