Govind's WebLog : Security Tokens

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.

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.

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.

Federation

govindr — Thu, 19 Oct 2006 01:38:00 GMT

As you are moving to Web Services world one of the buzz words that you will hear time and again is "Federation". This is simply a security scenario that involves 3 parties to secure a Message. The 3 parties in the scenario are,

Client
Security Token Service (STS)
Target Service

This is very similar to Kerberos authentication. In a typical Federation Scenario, a client that wants to talk to a Target Service will first go to the STS and present its credentials and will ask the STS to issue it a token with which it can talk to the Service. The STS then issues a token to the Client which the client presents to the Service to gain access to the Service's functionality.

What the Client has effectively done here is to transfer its one set of credentials to another that the Target Service will understand.

One simple scenario is Microsoft Passport. Once you login to passport with your username/password then you can access other sites which accepts the passport credentials. All the other sites now don't have to know your username and password to authenticate you. They know you have a Passport ticket and that is good enough for them.

So, is Federation all about Single Sign On (SSO)? Not really. SSO is just one feature of Federation. Let's consider another scenario. Company A and Company B might come to agreement that all of Company A's employees can access certain resources inside Company B. Now, let's say both Company A and B has an Active Directory (AD) which contains credentials for all their own employees. Now to allow access to Company A's employees, Company B can create accounts for all of Company A's employees in its AD. As you would realize this is not a viable/scalable solution. Instead, Company B can ask Company A to setup a STS on its end that will authenticate its employees based on their credentials in AD and issue a new token that the Service at Company B will understand and also contains the permission set associated with that employee. Now there is a implicit understanding between Company A's STS and Company B's Serivce on how this token should look like and how to verify the authenticity of this token and so on. SAML (Security Assertion Markup Language) is a great option for the token that gets passed between the STS and the Service.

WCF has good support for Federation and SAML 1.1. The latest specification of SAML is SAML 2.0 which WCF does not support out of the box. You can create SAML 2.0 as a custom token using the extensibility points available in WCF. I will post more information about Federation and SAML later.

Supporting Tokens

govindr — Mon, 16 Oct 2006 20:57:00 GMT

Web Services Message Security has the concept of Primary and Supporting Tokens. The Primary token is the main token that provides security to the message. This signs the message body and other headers as required and serves as the main identity token for the sending party. There is also a concept of Supporting Tokens. As the name suggests this provides more information about the client. An example of a supporting token can be a Username/Password Token. WCF does not derive tokens from Username/Password and hence this cannot be used as the primary token. In this case the binding between the client and service can be secured with a Mutual Certificate or Kerberos, as the case be, and then you can add the Username/Password token as a Supporting token. Bearer Tokens are another place where you will use a Supporting token.

There are various methods to add the supporting tokens.

Signed Supporting Tokens
Signed & Encrypted Supporting Tokens

In the first case the Supporting token is just signed with the primary token. In the second case the supporting token is signed and encrypted by the primary token.

There is a class of Supporting tokens called Endorsing Tokens. These are just like supporting tokens except that these tokens have keys associated with them and will sign the primary signature and add another signature element to the message called the secondary signature. As you would imagine the secondary signature contains only one reference and it is the signature over the primary signature. I have seen in Interop with other stacks that some do tend to use secondary signature to add more security to the message by signing other parts of the message, re-signing the Body and signing the endorsing token itself. These over secure measures are unnecessary. There is a valid claim that some one can spoof the message and remove the endorsing token and put a different token and re-sign the primary signature. To avoid this you can sign the endorsing token as part of the primary signature. This is called Signed Endorsing Supporting Tokens. You can go a step ahead to encrypt the endorsing token too to create a Signed Encrypted Endorsing Supporting token.