Govind's WebLog : SAML

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!

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.

Re-Serialize SAML token

govindr — Wed, 25 Oct 2006 03:05:00 GMT

In a Federation Scenario a client might want to access the services by using a SAML token that was issued to it by a STS. The service in turn might have to call other services (like a intermediary) to fulfill the request. When calling the backend service the service might want to use the SAML token that was presented to it by the client. This is a very common enterprise scenario. WCF currently does not enable this scenario. You can get around this by writing some custom code on the service side. Basically you need to write a custom SAML assertion that will remember the stream and will write it out when it has to. This also involves registering your own serializer and so on. Below is some code samples,

Write a Custom SAML Assertion

public class CustomSamlAssertion : SamlAssertion

{

MemoryStream ms;

public override void ReadXml(XmlDictionaryReader reader, SamlSerializer samlSerializer, SecurityTokenSerializer keyInfoSerializer, SecurityTokenResolver outOfBandTokenResolver)

{

ms = new MemoryStream(Encoding.UTF8.GetBytes(reader.ReadOuterXml()));

ms.Position = 0;

XmlDictionaryReader dicReader = XmlDictionaryReader.CreateTextReader(ms, XmlDictionaryReaderQuotas.Max);

base.ReadXml(dicReader, samlSerializer, keyInfoSerializer, outOfBandTokenResolver);

}

public override void WriteXml(XmlDictionaryWriter writer, SamlSerializer samlSerializer, SecurityTokenSerializer keyInfoSerializer)

{

if (ms != null)

{

ms.Position = 0;

XmlDocument dom = new XmlDocument();

dom.Load(ms);

dom.DocumentElement.WriteTo(writer);

return;

}

base.WriteXml(writer, samlSerializer, keyInfoSerializer);

}

The above assertion just stores the incoming SAML Assertion in a memory stream and writes out the stream when you try to re-send the assertion. Note, if you want to create a new SAML assertion you will have to new up the built in SAML Assertion. The way signature processing is handled on the send side will prevent from writing out the signature if the CustomSamlAssertion is new'ed up to build a new assertion. The next step would be to provide a custom SAML serializer,

Write a Custom SAML Serializer

public class CustomSamlSerializer : SamlSerializer

{

public override SamlAssertion LoadAssertion(XmlDictionaryReader reader, SecurityTokenSerializer keyInfoSerializer, SecurityTokenResolver outOfBandTokenResolver)

{

CustomSamlAssertion assertion = new CustomSamlAssertion();

assertion.ReadXml(reader, this, keyInfoSerializer, outOfBandTokenResolver);

return assertion;

}

Now we need to plug the Custom Serializer with the way Token Serialization is handled in WCF. So we need to write a

Write a Custom Token Serializer

public class CustomTokenSerializer : WSSecurityTokenSerializer

{

protected override void WriteTokenCore(XmlWriter writer, SecurityToken token)

{

if (token is SamlSecurityToken)

{

SamlAssertion assertion = ((SamlSecurityToken)token).Assertion;

if (assertion is CustomSamlAssertion)

{

XmlDictionaryWriter dicWriter = XmlDictionaryWriter.CreateDictionaryWriter(writer);

((CustomSamlAssertion)assertion).WriteXml(dicWriter, new SamlSerializer(), WSSecurityTokenSerializer.DefaultInstance);

return;

}

base.WriteTokenCore(writer, token);

}

The above code delegates all token serialization to the base class except for SAML.

Next, we need to provide a TokenManager that gives out our Custom Serializer instead of the default serializer.

Write a Custom Token Manager

public class CustomTokenManager : ClientCredentialsSecurityTokenManager

{

public CustomTokenManager(CustomClientCredentials clientCredentials)

: base(clientCredentials)

{

this.tokenProvider = new SamlTokenProvider(token as SamlSecurityToken);

}

public override SecurityTokenSerializer CreateSecurityTokenSerializer(SecurityTokenVersion version)

{

return new CustomTokenSerializer();

}

All Credentials related stuff should end up in ClientCredentials or ServiceCredentials in object in WCF. So let's implement a Custom Client Credentials that wraps the Token Manager.

Write Custom Client Credentials

public class CustomClientCredentials : ClientCredentials

{

SecurityToken securityToken;

public override SecurityTokenManager CreateSecurityTokenManager()

{

return new CustomTokenManager(this);

}

protected override ClientCredentials CloneCore()

{

return this;

}

When you are receiving the SAML token (you are the service) all that you need is the custom SAML Serializer. Below is how you would configure this,

ServiceHost serviceHost = new ServiceHost(typeof(CalculatorService));

serviceHost.Credentials.IssuedTokenAuthentication.SamlSerializer = new CustomSamlSerializer();

serviceHost.Open();

Now any SAML token received via this serviceHost will be loaded into the Custom SAML Assertion we have created.

When you want to re-serialize the SAML token, you have to register your Custom Client Credentials with the Channel Factory (Note: you will be acting as a client in this case). Below is how you would configure this,

EndpointAddress er = new EndpointAddress(new Uri(backEndServiceUri), EndpointIdentity.CreateDnsIdentity("Server-Cert"));

ChannelFactory<ICalculator> factory = new ChannelFactory<ICalculator>(GetCustomBinding(), er);

CustomClientCredentials clientCredentials = new CustomClientCredentials();

factory.Endpoint.Behaviors.Remove<ClientCredentials>();

factory.Endpoint.Behaviors.Add(clientCredentials);

ICalculator client = factory.CreateChannel();

That's it, you can now receive SAML tokens and re-serialize the token to a backend service.

The attached project has code for this scenario.

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.