Govind's WebLog : WCF

Patterns and Practices: WCF Security Guidance available online

govindr — Tue, 01 Apr 2008 23:00:00 GMT

The Microsoft Patterns and Practices team has created a guide for WCF security.

http://blogs.msdn.com/jmeier/archive/2008/03/27/patterns-and-practices-wcf-security-guidance-now-available.aspx

You can find more information at the root site

http://www.codeplex.com/WCFSecurity/

Reliable Messaging and SecurityToken validation

govindr — Tue, 28 Aug 2007 02:04:00 GMT

One of the things that have come up many times is how the service could stop a client from retrying a request for a valid security validation error while Reliable Messaging is enabled. If you are not familiar with the situation the essence of the problem is this,

Binding on the Service has Reliable Messaging (RM) enabled. You can do this using WsHttpBinding and setting the ReliableSession.Enabled property to true. What this would mean is that the client will re-try the request when the service responds with any random failure, after a session has been established. By random failure I mean failures that does not close the RM session while sending back the response. A fault sent back with proper RM headers to close the message would not result in a retry of the failed request. Unfortunately all SecurityToken validation and SecurityHeader validation exceptions are treated random exceptions as the response does not contain any required header or is the response secured.

One of the most common cases when this happens is when RM is enabled and a Username/Password validation fails. WCF provides extensibility points to plug in your Custom Username/Password validator, but any exception from the validator does not close the RM session and hence the client keep retrying the request until it finally times out. The post discusses a work around to close the RM session when such failures occur.

Write a Custom Username/Password Authenticator and plug this into the service using a Custom ServiceCredentials. The Custom Authenticator should add a specific failure claim to the AuthorizationContext. A sample code for the Custom Username/Password Authenticator is shown below.

class CustomUsernamePasswordAuthenticator : UserNameSecurityTokenAuthenticator

{

protected override ReadOnlyCollection<IAuthorizationPolicy> ValidateUserNamePasswordCore(string userName, string password)

{

Claim claim = null;

if (String.CompareOrdinal(userName, password) == 0)

{

claim = Claim.CreateNameClaim(userName);

}

else

{

claim = new Claim("http://contoso.com/InvalidUsernameClaim", true, Rights.PossessProperty);

}

List<IAuthorizationPolicy> policies = new List<IAuthorizationPolicy>();

List<ClaimSet> claimsets = new List<ClaimSet>();

claimsets.Add(new DefaultClaimSet(claim));

policies.Add(new ClaimFactoryPolicy(claimsets.AsReadOnly()));

return policies.AsReadOnly();

}

As you can see the above code is adding a specific claim of type http://contoso.com/InvalidUsernameClaim to the AuthorizationContext. For more information on how to plug custom authenticators in WCF you can take a look at http://msdn2.microsoft.com/en-us/library/ms730079.aspx.

The next we would do is to write a Custom Service Authorization Manager (SAM). The SAM gets called when the request has finally passed through all the binding elements so the RM header on the Request has been consumed. When an Access Denied result is returned by the SAM the failure response returned will be returned as Access Denied fault with the RM header enabled in the response that closes the RM session. Our Custom SAML will look for the specific Claim of type http://contoso.com/InvalidUsernameClaim to check whether to Authorize the user or not.

class CustomServiceAuthorizationManager : ServiceAuthorizationManager

{

public override bool CheckAccess(OperationContext operationContext)

{

ReadOnlyCollection<ClaimSet> claimsets = operationContext.ServiceSecurityContext.AuthorizationContext.ClaimSets;

foreach (ClaimSet claimSet in claimsets)

{

if (claimSet.ContainsClaim(new Claim("http://contoso.com/InvalidUsernameClaim", true, Rights.PossessProperty)))

{

return false;

}

return true;

}

Custom SAM can be plugged into the ServiceCredentials as shown below,

service.Authorization.ServiceAuthorizationManager = new CustomServiceAuthorizationManager();

The fault returned by the Custom SAM will stop the client from retrying when a token validation failure happens on the Service end.

Handling Mismatched Trust Versions on the Client

govindr — Wed, 22 Aug 2007 00:47:00 GMT

Federation Clients might have scenarios where it is talking to a Service and STS that don't have the same trust version. The Service WSDL can contain a RequestSecurityTokenTemplate with Trust elements that are in different version than the STS. In these cases a WCF client will convert the Trust elements received from the Service's RequestSecurityTokenTemplate to match the STS Trust version. WCF will handle mismatched Trust version only for Standard Binding. All algorithm parameters that we recognize as standard are part of the Standard Binding. Below is our behavior under various Trust settings between the Service and the STS.

In the below description RP refers to "Relying Party" or the "Service" and STS refers to "Security Token Service".

RP Feb 2005 & STS Feb 2005

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

1. CanonicalizationAlgorithm
2. EncryptionAlgorithm
3. EncryptWith
4. SignWith
5. KeySize
6. KeyType

Client Config contains a list of parameters.

WCF cannot differentiate between client and service parameters. We just add all the parameters and send them over the RST.

RP Trust 1.3 & STS Trust 1.3

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

1. CanonicalizationAlgorithm
2. EncryptionAlgorithm
3. EncryptWith
4. SignWith
5. KeySize
6. KeyType
7. KeyWrapAlgorithm

Client config contains a "secondaryParamters" element that wraps the RP specified parameters.

WCF removes the EncryptionAlgorithm, CanonicalizationAlgorithm and KeyWrapAlgorithm from the top-level element under the RST if these are present inside the SecondaryParameters. We append the SecondaryParamters element as is to the outgoing RST.

RP Trust Feb 2005 & STS Trust 1.3

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

1. CanonicalizationAlgorithm
2. EncryptionAlgorithm
3. EncryptWith
4. SignWith
5. KeySize
6. KeyType

Client Config contains a list of parameters.

WCF cannot differentiate between the Service and Client parameters in this case from config on the client side. So we convert all the parameters to Trust 1.3 namespace.

Our handling of KeyType, KeySize and TokenType elements in this case is as follows,

We download WSDL and create the binding and assign KeyType, KeySize and TokenType from RP's parameters and the client config is generated.
Client can now change any parameter in the config.
During Runtime WCF will copy all parameters specified inside the AdditionalTokenParameters section of the client config except KeyType, KeySize and TokenType as they were accounted for during config generation.

RP Trust 1.3 & STS Trust Feb 2005

RP's WSDL contains the following elements in the RequestSecurityTokenTemplate.

1. CanonicalizationAlgorithm
2. EncryptionAlgorithm
3. EncryptWith
4. SignWith
5. KeySize
6. KeyType
7. KeyWrapAlgorithm

Client config contains a "secondaryParamters" element that wraps the RP specified parameters.

WCF converts only EncryptionAlgorithm and CanonicalizationAlgorithm specified inside the "SecondaryParameters" and move them as top-level under the RST and replace the client specified values. The "SecondaryParameters" element is dropped from the AdditionalRequestParameters.

Security element and "actor" attribute.

govindr — Tue, 17 Jul 2007 09:15:00 GMT

SOAP 1.1 defines the attribute "actor" that can be on any SOAP header which will indicate who the ultimate processor of the header is going to be. It also defines a standard URI value for this actor attribute that is "http://schemas.xmlsoap.org/soap/actor/next" which implies that the header is intended for the very first SOAP application that processes the message. The absence of the actor attribute would mean the same as well.

SOAP 1.2 renamed this attribute to "role". But the semantics remanis the same as SOAP 1.1.

WCF Security does not recognize this attribute. WCF will not emit this attribute in the Security header element in any messages it emits. If a received message contains a actor attribute in the Security header the header will not be recognized even if the value is set to http://schemas.xmlsoap.org/soap/actor/next. You will see an exception that says "No Security header present in the message.". To work around this do not emit this attribute in the Security header in your messages to WCF.

Updated Re-Serialize SAML token

govindr — Thu, 03 May 2007 20:57:00 GMT

There has been a lot of interest around this and hence I have attached some code listing to this post. Check it out!

Using Visual Studio Intellisense to Edit WCF Configuration files.

govindr — Wed, 07 Mar 2007 02:33:00 GMT

If you are using Visual Studio 2005 below is how you can enable intellisense to edit your WCF config files.

Copy the Attached WCF Configuration schema file to your VS installation folder at %Program Files%\Visual Studio 8\Xml\Schemas. You will find DotNetConfig.xsd in the same directory. Open this file in notepad and following right after the xs:schema element add the below line,

<xs:include schemaLocation="WCFConfig.xsd" />

You will now have intellisense support for your WCF configuration files in VS!

Daylight savings changes and WCF Security Processing

govindr — Wed, 21 Feb 2007 07:26:00 GMT

I had a question today from a customer who was concerned that his WCF application might start to behave erratically due to the new Daylight savings schedule. Then I realized that there has been quite some noise around this area and people are predicting systems to stop responding when the new Daylight savings goes into effect. It reminded me of the Y2K days which was hyped as the doomsday of the Millennium.

In actual fact you don't have to worry about anything. WCF security has been tested for daylight savings time changes and the fact that the change happens earlier is not of concern. To be specific, WCF is using UTC time in all its code that the local time really doesn't affect us. As long as you have the Windows patch to adjust your clock at the correct time you should be fine. So, Enjoy! Keep coding with WCF!

Asymmetric tokens and Mixed-Mode Security

govindr — Wed, 07 Feb 2007 09:10:00 GMT

When you are using a X.509 Certificate as the client authentication token in Mixed-Mode Security - apart from signing the Timestamp WCF will sign the 'To' header as well. This is to prevent a client spoofing attack by a rougue service. Consider the situation where the client does not sign the 'To' header and sends the message to a rogue service. As long as the Timestamp is valid the rogue service can just forward the message to another service that trusts the client's certificate. The receiving service would validate the signature on the Timestamp and will accept the message and will respond back to the rogue service as if it is the client.

To prevent this WCF will sign the 'To' header as well when the client token used with Mixed-Mode security is an Asymmetric token. It will enforce the check on the receiving side as well. Now the rogue service cannot forward the message as the 'To' header needs to change for the called service and hence forces the service to create a new signature.

WCF Security Modes

govindr — Wed, 07 Feb 2007 08:41:00 GMT

WCF supports three types of Security. They are,

Transport Security
Mixed-Mode Security
Message Security

Let's discuss the various Security Modes below.

Transport Security is applied at the transport byte stream below the message layer. The message does not have a Security header and the message does not carry any user authentication data. It is the least flexible in terms of WS-Security usage and it is highly dependent on the transport. It is the fastest in terms of performance.

Message Security is applied at the message layer and it is transport independent. It is a point to point security model with maximum flexibility in terms of having the message routed over different transports. WS-Security defines different ways to secure a message and the tokens that can be used. Message Security provides the maximum flexibility in terms of that as well. Message Security is slowest in terms of performance.

Mixed-Mode Security is a hybrid between Transport and Message Security. The transport is encrypted and the message contains some user authentication tokens. If the token can provide a key (i.e., it is not a username/password token) then it will sign the timestamp in the security header. If the client token is a Asymmetric token then the 'To' header will be signed as well. It is faster than Message Security.

Security Header Layout

govindr — Tue, 23 Jan 2007 00:42:00 GMT

There are four different security header layout that can be specified in WCF. The values are defined in WS-SecurityPolicy. They are,

Strict - All security tokens are defined in the security header before its first use. The primary signature should be specified before any endorsing signatures.
Lax - All elements inside the security header can appear in any order.
LaxWithTimestampFirst - Timestamp element should be the first element that appears inside the security header. All other elements can appear in any order.
LaxWithTimestampLast - Timestamp element should be the last element inside the security header.

WCF provides a way to specify the security header layout using a switch on the security binding element called securityHeaderLayout.

Strict is the default mode in WCF. Lax mode can be slower in rejecting invalid messages as most of the validations are done after the security header is consumed. LaxWithTimestampLast serves the least purpose among the different header layouts but is defined for Interop reasons.

So what should you use? Lax is predominantly used when incoming message can be generated by different stacks. If all your messages are from WCF then using the default of Strict gives the maximum benefit.

WCF Support in Compact Framework

govindr — Wed, 10 Jan 2007 01:43:00 GMT

In a nutshell, .NET Compact Framework 3.5 supported features for WCF include: messaging-layer communication, WS-security, and http and mail transports. All of these a subsets of what the desktop supports, with the exception of the mail transport, which is new with NetCF. There is also some plans to provide a tool to generate code for a NetCF app that will allow the app to call a service on a desktop.

Configuring HTTP in Windows Vista

govindr — Tue, 09 Jan 2007 23:43:00 GMT

Hosting a WCF service on a HTTP endpoint on Windows Vista has some issues given that you are not running with Administrator privileges. Following blogs discusses how to get around this issue,

http://blogs.msdn.com/drnick/archive/2006/10/16/configuring-http-for-windows-vista.aspx

http://kennyw.com/indigo/145

Federation and Bearer Tokens

govindr — Wed, 22 Nov 2006 14:06:00 GMT

The latest WS-Trust spec (yet to be ratified by OASIS) introduces a concept called Bearer Tokens. This basically is a keyless token that a client requests from an STS (Security Token Service). The only purpose this token serves is to provide more information about the client to the service while the client already has a way to secure its conversation with the service. (Read my other post on Federation for more details on how client uses that key obtained from a STS token.)

This introduces some qurikiness. The obtained issued token can now be added only as a supporting token. In case of transport secured messages this can just be a signed supporting tokens. In messages level security scenarios, this token should be added as a signed encrypted supporting token. Note, the client doesn't have a key so there is no need for the client to prove to the service that it did obtain the token for the STS and it does know some secret information of the token. So just adding the token as signed token in message level security will expose the token for a third party, who can just snoop the token and replay it to the service as if it is the client.

Bearer tokens issued by a STS should be some how verifiale by the service. For this purpose the Bearer token should be signed by the STS. A SAML 1.1, SAML 2.0 or a custom token fits well for this purpose. WCF will require a wsu:Id to be on the issued token to be able to sign it (In message level security case). A SAML 1.1 does not have a wsu:Id on it and its attribute list is not extendable by the schema and hence it is not possible to use SAML 1.1 as bearer tokens in WCF with message level security. The only choices are SAML 2.0 or a custom token that contains a wsu:Id on it.

The cool feature of Bearer tokens in my opinion is that it enables the client to get multiple such tokens from different STS and present all of it to the service. The service might need information from multiple sources to allow or deny permissions for a client and instead of doing multiple round trips the client can present all information to the service at once.

WCF v1 does not support this token type and we might be adding support for this in the future. The idea behind this post is to explain the issues involved in using such tokens and how it plays with message level and transport level security.

.Net Framework 3.0 is Live!!

govindr — Wed, 08 Nov 2006 02:59:00 GMT

Get the latest version of .Net Framework 3.0 at

http://www.microsoft.com/downloads/details.aspx?FamilyId=10CC340B-F857-4A14-83F5-25634C3BF043&displaylang=en

Debugging WCF - Traces and Message Logs

govindr — Thu, 02 Nov 2006 09:40:00 GMT

There has been enough posts on this topic. But this topic cannot be over emphasized. The best way to debug any WCF issue is to get a complete Message log and trace. We write tons of information to the trace that there is very little (if any) issues that traces cannot solve. Below is a config to generate Message logs and Traces in the Verbose level. The config will create a file e2eTraceTest.e2e in the directory where the config lives.

<configuration>

         <system.serviceModel>

                 <diagnostics>

                         <messageLogging maxMessagesToLog="30000"

                                 logEntireMessage="true"

                                 logMessagesAtServiceLevel="true"

                                 logMalformedMessages="true"

                                 logMessagesAtTransportLevel="true">

                         </messageLogging>

                 </diagnostics>

         </system.serviceModel>

         <system.diagnostics>

                 <sources>

                         <source name="System.ServiceModel"

                                 switchValue="Verbose, ActivityTracing"

                                 propagateActivity="true" >

                                 <listeners>

                                         <add name="xml" />

                                 </listeners>

                         </source>

                         <source name="System.ServiceModel.MessageLogging"

                                 switchValue="Verbose">

                                 <listeners>

                                         <add name="xml" />

                                 </listeners>

                         </source>

                 </sources>

                 <sharedListeners>

                         <add name="xml"

                              type="System.Diagnostics.XmlWriterTraceListener"

                              initializeData="e2eTraceTest.e2e" />

                 </sharedListeners>

                 <trace autoflush="true" />

         </system.diagnostics>

 </configuration>