Nicholas Allen's Indigo Blog

Inside the Standard Bindings: WSFederationHttp

The final HTTP binding that I'm covering in this series is WSFederationHttp. Federation is the ability to share identities across multiple systems for authentication and authorization. These identities could either be for users or machines. This binding is intended for the very specific scenario of federated security.

Standard disclaimer:

I've cut down on the number of properties presented by eliminating duplicates between the binding settings and binding element settings. For instance, the XML reader quotas can be set on either the binding or the message encoder binding element, but I'm only going to show them on the message encoder. I've also omitted most of the security credential settings because they're very messy and you hopefully won't need to change them much.

Federated HTTP supports SOAP security as well as mixed-mode security, but it doesn't support exclusively using transport security. I'll begin with the usual pattern of first presenting the binding with security disabled.

1. System.ServiceModel.Channels.TransactionFlowBindingElement

   TransactionProtocol: WSAtomicTransactions
   

2. System.ServiceModel.Channels.TextMessageEncodingBindingElement

   AddressingVersion: Addressing10 (http://www.w3.org/2005/08/addressing)
   MaxReadPoolSize: 64
   MaxWritePoolSize: 16
   ReaderQuotas: 
     MaxArrayLength: 16384
     MaxBytesPerRead: 4096
     MaxDepth: 32
     MaxNameTableCharCount: 16384
     MaxStringContentLength: 8192
   

3. System.ServiceModel.Channels.HttpTransportBindingElement

   AllowCookies: False
   AuthenticationScheme: Anonymous
   BypassProxyOnLocal: False
   HostNameComparisonMode: StrongWildcard
   ManualAddressing: False
   MappingMode: SoapWithWSAddressing
   MaxBufferPoolSize: 524288
   MaxBufferSize: 65536
   MaxReceivedMessageSize: 65536
   ProxyAddress: 
   ProxyAuthenticationScheme: Anonymous
   Realm: 
   Scheme: http
   TransferMode: Buffered
   UnsafeConnectionNtlmAuthentication: False
   UseDefaultWebProxy: True
   

There's nothing unusual about these settings compared to any of the other HTTP bindings. However, if you look at the top-level settings on the binding, there are two new components. The first is an address for a privacy notice. The second is buried inside the security settings. If you drill down to the settings for message security (not pictured here) there's now more than a dozen settings instead of the normal two or three.

CloseTimeout: 00:01:00
EnvelopeVersion: Soap12 (http://www.w3.org/2003/05/soap-envelope)
Namespace: http://tempuri.org/
OpenTimeout: 00:01:00
PrivacyNoticeAt: 
ReceiveTimeout: 00:01:00
ReliableSession: 
  Enabled: False
  InactivityTimeout: 00:10:00
  Ordered: True
SendTimeout: 00:01:00
TextEncoding: System.Text.UTF8Encoding
TransactionFlow: False

The channel stack is identical to the WSHttp binding when Security.Mode is set to Message.

1. System.ServiceModel.Channels.TransactionFlowBindingElement
2. System.ServiceModel.Channels.SymmetricSecurityBindingElement
3. System.ServiceModel.Channels.TextMessageEncodingBindingElement
4. System.ServiceModel.Channels.HttpTransportBindingElement

However, setting Security.Mode to TransportWithMessageCredential results in something of a hybrid between the WSHttp and BasicHttp bindings.

1. System.ServiceModel.Channels.TransactionFlowBindingElement
2. System.ServiceModel.Channels.TransportSecurityBindingElement
3. System.ServiceModel.Channels.TextMessageEncodingBindingElement
4. System.ServiceModel.Channels.HttpsTransportBindingElement

   RequireClientCertificate: False
   Scheme: https
   

Finally, using the MTOM encoder looks exactly the same as for WSHttp.

1. System.ServiceModel.Channels.TransactionFlowBindingElement
2. System.ServiceModel.Channels.MtomMessageEncodingBindingElement
3. System.ServiceModel.Channels.HttpTransportBindingElement

Next time: It's All in the BindingContext