When a business service receives a SAML token, WCF will extract the SAML attributes (containing the information) as claims and make it available as a ClaimSet that can be reached through the AuthorizationContext. This not the way I would like my business logic to work with the information available in the SAML token though, because that will thigh my business logic to WCF. I have instead chosen to expose the information in the SAML token through a custom principal object. This custom principal object has some parts that is equal to ClaimsPrincipal that by Michéle Leroux Bustamente presents in her article, but I have also let the principal object to have specific knowledge of some claims. For example there are standard claims for groups (roles) and user name defined in WS-Federation, that I use and extract to be the user name in the identity object and the roles are used for the IsInRole method.

This solves the problem for me that the business logic code does not need to handle claims (at least not through AuthorizationContext), but could instead use the principal and identity objects that is a common practices already. Beside this, I also have chosen to create an ITokenPrincipal interface that exposes the SAML token, which therefore must be stored in the principal object. The reason I do this is that I want to be able to create a custom behavior for my WCF clients (could be a service calling another service) that adds the SAML token to the call so that the SAML token could flow between services. More on this in later post(s).