Almost three years ago I started to think in the terms of having an infrastructure service to handle security like verifying users, getting which roles they belong to and so on. Back then it was WSE 3 in a beta and no information available on the Internet (that I could find anyway). I had heard of WS-Trust and I had also seen a sample on an event where a Swedish Microsoftie showed something that I think was a Security Token Service (I actually don't remember all the details). Well anyway after having big problems getting the pieces together with the certificates and everything I started to doubt that I was on the right direction. Fortunately I had the opportunity so sit down with Don Smith on the PDC 05 and also to get some hands on help from Siddharth in the WSE team to get my STS implementation running with correct signing and encryption (see my post
PDC Day Five: Interacting with Microsoft employees). So back in September 2005 I finally had my service running with a custom xml token. Not long after that pattern & practices released their whitepaper on
web service security and then also a
Quickstart for implementing a STS with a SAML token. I converted my solution to be based on their code and extended it to fit my needs. Now I want to also WCF enable this service and maybe also take some new steps to improve some parts of it based on the experience that I've gathered during this time. Today there a lot more samples (even in the .NET 3.0 SDK) to get you started on the subject and for example you could read two excellent articles on theserverside.net written by
Michéle Leroux Bustamente (
http://www.theserverside.net/tt/articles/showarticle.tss?id=ClaimsBasedSecurityModel and
http://www.theserverside.net/tt/articles/showarticle.tss?id=ClaimsBasedSecurityModel2).
It's not that difficult to create a working STS service from this samples that works great with wsFederationHttpBinding, but I have some other requirements that showed not be as easy to solve. This is a list of some of the requirements that I have:
I want to verify the users credentials immediately when he/she logs on. The wsFederationHttpBinding requires you to set the client credentials to be used against STS when calling the business service (relying party).
When the user logs on I will call Issue on the STS and get a SAML token back. When calling a business service I want to use this SMAL token for the wsFederationHttpBinding so that I won't be required to hang on to the clients username/password.
Extend the STS to support Cardspace (today it supports username/password and kerberos).
If the business service needs to call another business service, I want the SAML token to flow with it if the SAML token applies to that service too.
I want to be able to use information from the SAML token in the client to. For example if I have user roles in the SAML token, it would probably be useful to be able to set up a principal object on the client with this roles.
As I solve this problem (if I solve them), I also will blog about them because there are not so much information about it available. As I implement this I will try to do it so that the security will be as good as it is with the standard wsFederationHttpBinding (and that's better than what I have today based on the WSE Quickstart STS). I also have some other requirements like creating custom claims (SAML attributes) and I also want the STS to be very configurable so that I could easily extend the SAML token with more claims. I probably will not blog about this because there are great information available how to do this for example in the two articles referenced above. I would also be happy to hear from you dear reader if there are something that you find interesting in this area and I might try to solve that too and blog about it.