|
|
Browse by Tags
All Tags » Bindings » Indigo (RSS)
-
The basis of a channel stack is that there is a series of objects that share a common interface for communication. This leaves message encoders with something of a problem as the primitive operations for encoding and decoding messages are different than the primitive operations for sending and receiving messages. Message encoders avoid this problem by being contained within a channel rather than acting as a peer in the channel stack. However, this is different than the model used for bindings, which make the message encoding binding element a peer of the other channel binding elements. To make things harder, bindings use a "no lookahead" construction process where constructing an object cannot speculate about future construction by looking into the unprocessed information in the binding. That results in a subtle dance between a message encoder and a channel that wants to use a message encoder. During the construction process, a binding gives you only a context for storing computed information and the ability to initiate the next phase of the construction process. When we go to build a message encoder, it's not possible to actually build anything because the channel that will hold the message encoder doesn't exist yet. The message encoder doesn't know how or why it is going to be used. Instead, what a message encoding binding element does to build is add itself to the BindingParameters in the context. The message encoding binding element then initiates the next phase of the construction process. At some point in the future, a channel may look at the context to see if it contains a previously saved binding element, which can now be built. The delay in instantiation is what allows channels to have a different order for physical containment than the logical order of the binding elements. Next time: Quotas for Copying Messages Read More...
|
-
What channels can be used in a context binding? The primary limitation for building a context binding is that the channel stack has to have the right shape. The context exchange protocol used by a context binding requires that the first invoked operation be a request-reply operation. This is so that the initial context can be established. In order to support a request-reply operation, the channel stack needs to support one of a particular set of shapes. There are currently five channel shapes allowed when using a context binding: IRequestChannel IRequestSessionChannel IReplyChannel IReplySessionChannel IDuplexSessionChannel The request and reply channel shapes are paired for the client and server so on any particular endpoint there are three valid channel shapes. Conditions are limited further if you want to use HTTP cookies as your context exchange mechanism rather than the default of SOAP headers. In that case it's no longer possible to use a duplex channel so you're limited to variations on the request-reply message exchange pattern. Next time: Manual Context Management Read More...
|
-
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...
|
-
When packaging up a collection of settings, how do I know whether to use a CustomBinding, extend the Binding class, or extend one of the standard binding classes? In most cases this should be easily decidable by asking at most two questions. The first question is used to decide between creating a custom binding instance and creating a new class for your binding. Is your binding generally reusable such that you'd expect it to be dropped into other applications with few changes? If your binding is not generally reusable or you don't care to make it so, then use a custom binding. Otherwise, create a binding class by extending Binding or by extending one of the standard bindings. The second question is used to decide between those two alternatives when creating a new class for your binding. Can your binding be expressed as a simple derivative of one of the existing standard bindings? If you're changing some of the default settings of the standard binding, then your binding is probably a derivative. If you’re changing or exposing some of the settings of binding elements that the standard binding doesn't normally expose, then your binding is probably a derivative. If you're adding a layered channel that doesn't have any protocol impact, such as logging, then your binding is probably a derivative. If you're adding or removing layered or transport channels that do have an impact on the protocol, then your binding is probably not a derivative. A derivative of one of the standard bindings should be made by subclassing the standard binding class. A new binding is made by subclassing the base Binding class. Next time: Resolving Conflicts in Serialization Read More...
|
-
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...
|
-
I've done a bit of grouping for the remaining binding elements as there are fourteen non-transport binding elements that I'm covering in this list. I've pointed out the ones that respond to a type with GetProperty on the base class as opposed to repeating the same code in each subclass. Our standard message encoders respond to two types, although only one is on the base class. These two interfaces will override the ones given by the transport if a message encoder is in the binding. The transport delegates to the message encoder before giving its useless default response. MessageVersion (on the message encoder base class) XmlDictionaryReaderQuotas (on the Text, MTOM, and Binary encoders) The one-way and transaction channels both support just a single interface. ChannelProtectionRequirements All of the security binding elements support a pair of interfaces and the actual security channels add an additional type. ISecurityCapabilities (on the security base class and on the Windows and SSL stream upgrades) IdentityVerifier (on the security base class and on the Windows and SSL stream upgrades) ChannelProtectionRequirements (on the asymmetric, symmetric, and transport security binding elements) The reliable message binding element supports a pair of interfaces as well. ChannelProtectionRequirements IBindingDeliveryCapabilities Finally, the composite duplex binding element has a pair of types. If you're curious why composite duplex is interacting with a security interface, then you should read the earlier article on layering between composite duplex and security . ISecurityCapabilities ChannelProtectionRequirements Next time: Starting a Hosted Service Read More...
|
-
This is more of a reference than anything else. People have asked me what interfaces do something when used with GetProperty on a binding element. Of course, a custom implementation can do whatever it wishes in its GetProperty, so I can only tell you what the standard implementations have done. Also, GetProperty is chained from one place to another. For example, if a property is not found on a channel binding element, it is likely to go off looking at lower binding elements in the channel stack, the message encoder, and so on. What's listed here is just what is specifically handled in a given implementation. I've split this list into "transports" and "everything else". The base class for transport responds to three types. ChannelProtectionRequirements (this just give the default values) MessageVersion (SOAP 1.2, WS-Addressing 1.0) XmlDictionaryQuotas (this just gives the default values) The HTTP and HTTPS transports respond to three additional types. Also, these transports automatically check against the properties of a text message encoder if you didn't specify any encoder at all. None of the other transports do this for you. ISecurityCapabilities IBindingDeliveryCapabilities TransferMode The TCP and Named Pipes transports respond to only two additional types. IBindingDeliveryCapabilities TransferMode The Peer transport responds to three additional types. IBindingMulticastCapabilities ISecurityCapabilities IBindingDeliveryCapabilities The MSMQ transports respond to three additional types. The last one only occurs for the Integration mode of MSMQ. ISecurityCapabilities IBindingDeliveryCapabilities MessageVersion (always set to None for Integration mode) Next time: Interfaces for GetProperty, Part 2 Read More...
|
-
In the past I've talked a lot about the absolute minimum you need to do to write a working channel. However, what about the people that want all of the optional bells and whistles that can go along with channel development? There are several interfaces that you can implement on the binding element or in your custom channel solution to add functionality. I'm not going to go over these interfaces in detail today, but I did want to at least catalog the interfaces that are available. The base class for a channel binding element is taken up by the fact that you have to subclass BindingElement or TransportBindingElement. Therefore, the optional functionality is generally provided through interfaces that you can add to the binding element or on separate objects. WS-Policy export. The IPolicyExportExtension interface lets you define an ExportPolicy method that overrides the policy construction process. Metadata export. The IWsdlExportExtension interface lets you define an ExportContract and an ExportEndpoint method that override the metadata construction process. WS-Policy import. The IPolicyImportExtension interface has the reverse method ImportPolicy to consume policy statements. Metadata import. The IWsdlImportExtension interface has the reverse methods ImportContract and ImportEndpoint to consume metadata. IWsdlImportExtension also has a method called BeforeImport. Metadata consumption is done using a multi-phase process, where all of the importers get to look at the metadata once before actually doing the work. Configuration import and export. Configuration on the binding element is added by subclassing BindingElementExtensionElement. This is a separate object that has to parallel all of the settable properties on the binding element. Binding configuration import and export. If you put your binding element into a standard binding, then you can provide configuration for that binding as well. You need two separate objects subclassing StandardBindingElement and StandardBindingCollectionElement. Next time: Messaging is not a Transaction 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...
|
-
I've created a custom implementation of GetProperty for my binding but now I'm getting errors when I go to use the channels. Why is the validation for these channels failing? This is an implementation problem that I've talked about in the past. There is a requirement that the values queried from design time objects, such as bindings and binding elements, match the values queried from runtime objects, such as a channels. If the two don't agree on a property value, then you can experience problems ranging from an error creating the channel to mysterious failures sending and receiving messages. This problem most commonly happens when you override an existing property value on the binding but forget to override the property in the same way on the channels. Use this picture illustrating GetProperty to follow the chain of property values. However, this problem can also happen even when you're not overriding an existing value. If you write a GetProperty implementation but forget to delegate to the inner channel or binding element, then the chain of GetProperty calls terminates right there. Any further channels or binding elements do not get to contribute to GetProperty evaluations. This can easily cause a discrepancy between the design time and runtime values of a property despite the fact that you didn't explicitly modify that property. In most cases, this is a severe enough problem to fail very quickly. If you've written a GetProperty method and are suddenly seeing property value mismatches for properties that you didn't touch though, then make sure that your GetProperty method is delegating any unhandled properties to the right place. Next time: Preventing Anonymous Access Read More...
|
-
We're back to the channel development tour for another pair of articles. Today's article is the first of four in this segment on channel construction. The first half of the segment is background and the second half of the segment talks about code. In each half, there is an article on bindings and an article on channel managers. After we're done with this segment, everything else in the series deals directly with implementing the channel interfaces. Channels go through a somewhat complicated construction process . This construction process essentially has three stages: design, evaluate, and build. Bindings are the typical user-accessible part of the construction process and correspond to the design stage. We have to take a few steps back before it becomes clear how bindings fit into the model. You have a service. Your service has endpoints that enforce a particular contract for exchanging data. One part of your endpoint's contract is the protocol for how the client and server can send each other a message. The implementation of a protocol contract is called a binding. There are many ways to build this implementation, including through configuration files or writing code. Bindings expose design settings that allow the user to configure various aspects of the network protocols. The binding is a rough equivalent to the channel stack, a composition of all of the chosen protocols. Given a specific set of design settings, the binding can produce a set of binding elements that correspond to those settings. Each binding element is a rough equivalent to one channel in the channel stack. We'll see some examples latter where that isn't true, but it's generally the case. We'll stop here in the process for now because at the next step we'll be producing the channel managers that are the subject of tomorrow's article. The binding and binding element expose methods that allow us to perform the evaluate and build stages. The evaluate stage allows the user to query whether the chosen design settings of the binding make sense for building a channel manager. This is a cheap way of verifying the build process without having to actually initiate a build. The build stage locks the design settings of the binding in place and produces the corresponding channel manager. From the channel manager, the build process is going to continue a little bit farther until we have actual channels. Next time: Channel Managers 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...
|
|
|
|