Browse by Tags

• Answers
• Hosting
• HTTP
• Message Security
• Orcas
• Standard Bindings
• Transport Security
• Transports

• Default ProtectionLevel for Standard Bindings

  Previously I've described how messages are protected by using the ProtectionLevel attribute to specify the minimum level of protection. If you don't specify a protection level explicitly, then you'll get one by default that is computed based on the binding. This default protection level is the maximum protection level that the binding can achieve with the configuration that you've given it. Every configuration is going to be different so the only way to definitively know your protection level is to check. If you start with one of the standard bindings though, then here's what your protection level will be assuming that you haven't applied any configuration changes. BasicHttpBinding: None BasicHttpContextBinding: None NetNamedPipeBinding: EncryptAndSign NetPeerTcpBinding: None NetTcpBinding: EncryptAndSign NetTcpContextBinding: EncryptAndSign WebHttpBinding: None WSDualHttpBinding: EncryptAndSign WSFederationHttpBinding: EncryptAndSign WSHttpBinding: EncryptAndSign WSHttpContextBinding: EncryptAndSign WS2007FederationHttpBinding: EncryptAndSign WS2007HttpBinding: EncryptAndSign Next time: Running Setup with Pkgmgr Read More... Posted Tuesday, April 08, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Bindings, Security, Standard Bindings

• Partial Trust Binding Black List

  Partial trust support in WCF is an Orcas feature that allows clients and services to be run in an environment with restricted permissions. WCF is part of a fully trusted installation, so by default partially trusted callers are not allowed to call into the assembly. However, there is a standard mechanism to change that, which is to mark the assembly with the AllowPartiallyTrustedCallers attribute. Once an assembly is marked, it is then the responsibility of that code to make sure that partially trusted callers can't do bad things through the exposed API of the fully-trusted assembly. To implement this restriction, one of the things that WCF does is limit the bindings that you can build using the out-of-the-box components (custom components would have to join into this same security model and do their own validation before they could be used). There are two rounds of checks, first to knock out the bindings that are not safe for partially trusted callers and then to knock out the binding elements. WCF ships with 15 bindings (plus custom binding) in the box for Orcas. Of these, eight immediately get knocked out: MsmqIntegrationBinding NetMsmqBinding NetNamedPipeBinding NetPeerTcpBinding NetTcpBinding WSDualHttpBinding WS2007FederationHttpBinding WSFederationHttpBinding Then, any binding that contains one of these binding elements gets knocked out: AsymmetricSecurityBindingElement CompositeDuplexBindingElement MsmqTransportBindingElement MtomMessageEncodingBindingElement NamedPipeTransportBindingElement OneWayBindingElement PeerCustomResolverBindingElement PeerTransportBindingElement PnrpPeerResolverBindingElement ReliableSessionBindingElement SymmetricSecurityBindingElement TcpTransportBindingElement TransportSecurityBindingElement That basically allows for the following standard bindings to operate: BasicHttpBinding, BasicHttpContextBinding, WebHttpBinding, WSHttpBinding, WSHttpContextBinding, and WS2007HttpBinding. The WSHttp bindings will be quite limited because many of their features are blocked by the binding element checks. Now you can figure out all of the supported binding configurations if you still haven't read the partial trust feature compatibility guide . Next time: Built In ServiceHost Validation Behaviors Read More... Posted Thursday, March 13, 2008 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Bindings, Security, Standard Bindings, Orcas

• 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... Posted Monday, December 31, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 1 Comments Filed under: Indigo, Bindings, Transports, Transport Security, HTTP, Security, Standard Bindings

• 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... Posted Friday, August 17, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Bindings, Transport Security, Answers, Security, Message Security

• 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... Posted Friday, March 23, 2007 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Bindings, Transport Security, HTTP, Answers, Security, Hosting, Standard Bindings

• Building a Secure Composite Duplex

  I'm getting this error message even though I have security enabled for my service: Unhandled Exception: System.InvalidOperationException: The response message must be protected. This is required by an operation of the contract ('ICalculator', 'http://Microsoft.ServiceModel.Samples'). The protection must be provided by the binding ('CustomBinding', 'http://tempuri.org/'). This is sometimes a symptom of incorrect layering between security and composite duplex. Composite duplex correlates two channels together. If the security binding element is below composite duplex in the channel stack, then you'll get this error message because the security channel that is protecting the requests is not able to protect the responses that come in along the back channel. The solution is to reverse the ordering and put security on top of the composite duplex channel. Additionally, you need to specify the use of SecureConversation for that security channel. The security method that you are actually using (user name/password, certificates, Kerberos, whatever) should be specified as the bootstrapping method for the secure conversation. Here's an example of a server with the right layering. CustomBinding binding = new CustomBinding(); SecurityBindingElement security = SecurityBindingElement.CreateAnonymousForCertificateBindingElement(); binding.Elements.Add(SecurityBindingElement.CreateSecureConversationBindingElement(security)); binding.Elements.Add( new CompositeDuplexBindingElement()); binding.Elements.Add( new OneWayBindingElement()); binding.Elements.Add( new TextMessageEncodingBindingElement()); binding.Elements.Add( new HttpTransportBindingElement()); ServiceHost host = new ServiceHost( typeof (CalculatorService), new Uri( "http://localhost:8000/" )); host.Credentials.ServiceCertificate.SetCertificate(StoreLocation.CurrentUser, StoreName.My, X509FindType.FindBySubjectName, "localhost" ); host.AddServiceEndpoint( typeof (ICalculator), binding, "" ); host.Open(); Console.WriteLine( "Press <ENTER> to terminate service." ); Console.ReadLine(); host.Close(); Next time: Getting the Client's Password Read More... Posted Friday, November 17, 2006 8:00 AM from Nicholas Allen's Indigo Blog | 0 Comments Filed under: Indigo, Bindings, Answers, Security