|
|
Browse by Tags
All Tags » Bindings » Standard Bindings (RSS)
-
You may have noticed that bindings use two different classes for configuring reliability: ReliableSession and OptionalReliableSession. The only difference between the two is that OptionalReliableSession has an Enabled property that allows the reliable session to be turned off. If you only have a ReliableSession to work with, then there is no way for it to be disabled. The only standard binding that uses ReliableSession is WSDualHttpBinding. All of the other standard bindings that support reliability, such as NetTcpBinding and WSHttpBinding, use OptionalReliableSession. Why is WSDualHttpBinding the only one that has to be reliable? The reason for this is that WSDualHttpBinding has to coordinate together two different connections. The stack of binding elements for WSDualHttpBinding looks like this: TransactionFlowBindingElement ReliableSessionBindingElement SecurityBindingElement (optional) CompositeDuplexBindingElement OneWayBindingElement TextMessageEncodingBindingElement (or MtomMessageEncodingBindingElement) HttpTransportBindingElement Composite duplex splits the binding into separate input and output connections, and relies on a higher-level component to correlate the two. There are many ways to provide that correlation, one of which is a reliable session. Requiring that the reliable session be present matches the most common usage pattern and allows the other potential correlation mechanisms to be omitted without having to validate the resulting binding configuration. That's why WSDualHttpBinding requires a reliable session. If you have a different correlation mechanism that you want to use together with composite duplex, then you can build that with a custom binding. Next time: Context Channel Shapes Read More...
|
-
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...
|
-
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...
|
-
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...
|
-
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...
|
-
What's the fastest binding for securely communicating over an intranet? How about if the client and server don't share a domain? A lot of attention gets paid to Internet configurations, where HTTP rules the world. HTTP is so dominant in that environment because it is a very open and standardized protocol. Servers that support HTTP as their primary network transport protocol have a lot of reach. It's easy to write clients that connect to these servers, which means a lot more clients will get written than would be the case if the server used some obscure network transport protocol. The world is completely different on an intranet because suddenly reach is no longer a critical factor for adoption. It is possible to use both political and technical means to control the technology that the client and server commonly share. This sharing is helpful in a lot of ways because it allows the use of specialized network transport protocols that are faster and more efficient than the standardized protocols. By removing the requirement of reach, it is possible to do better at meeting other requirements, such as performance. In the general case, the fastest transport in WCF for communicating between machines is the TCP transport. The fastest encoding in WCF is the binary message encoder. Since we control the technology in this scenario, we can enforce support for these protocols. That combination is the default setting for the NetTcpBinding. However, NetTcp has other features turned on by default that take back some of these performance advantages. For example, leaving security enabled is going to roughly cut the network transfer performance of TCP in half. Security is an example of a desirable feature with significant cost, but allows you to get away with not paying if you don't need the feature. That's the essence of the "pay as you go" model. We need security in this case, but we can go with the lightest strategy for securing the connection. Without a trust relationship between the client and server, we can't rely on a third-party service to broker trust between us. The simple and direct approach in this case is to use NetTcp with transport security and rely on the plain old Windows NTLM authentication. NTLM is pretty cheap and allows us to use the basic username and password model for transferring data to a remote machine. Next time: Actions for FaultExceptions Read More...
|
-
Why are there two MSMQ bindings? This is an easy question to answer: there are two bindings for MSMQ because they do different things. Go ahead and take a look at each of the bindings. The NetMsmqBinding looks like a normal binding with an MSMQ transport, binary message encoder, and all of the normal features that you'd expect to find on a binding. On top of that, there a whole bunch of features that are specific to configuring a queue, like dead letter handling. The MsmqIntegrationBinding on the other hand looks totally different. Ok, the integration binding doesn't actually look all that different. All of the queue-specific features are shared between the two and that makes up a large portion of each of the bindings. However, the rest of the integration binding looks quite unusual compared to all of the standard bindings. For instance, everything is wrapped into a single MSMQ integration binding element. There's no message encoder or configuration of message features. Addressing for messages with this binding element uses a very particular syntax. There's no support for message security. Actually, there's almost no support for composing the MSMQ integration binding element with any other type of protocol channel binding element, not just security channels. You'll find that services using this binding are very limited in terms of contracts. The MsmqIntegrationBinding is intended for use with existing, already-written native MSMQ applications. The NetMsmqBinding is a lot better to use but only works if you have WCF on both ends of the queue. Therefore, one of these is always the clear choice for your queuing scenario depending on what's on the other side. There's nothing stopping you from hosting separate endpoints for each of these bindings at the same time if you need communication with both native and WCF clients. However, the two endpoints need to be kept with separate queues because the messages are not compatible. Next time: Serialization of Client Calls Read More...
|
|
|
|