WIF and Claims Based Security Tokens

CodeProject

Windows Identity Foundation

Security is really a deceptively simple problem of merely two parts, Authenticating and Authorizing users. The problem is that there's been an absence of standards and interoperability is really impossible without them. However there's been quite a few advancements recently that I wanted to point out and discuss in this article.

Standard Challenges

In a typical security scenario, an application either contains a custom forms based authenticating systems (web) that uses a username-email/password combination to authenticate the user or it relies on the corporate authenticating system (intranet) to do the same. The application then queries their user repository to retrieve user information to determine their level of access, preferences and anything else that might be needed. The user repository is typically local to the application (a database for example), or the user directory managed by the authenticating system (active directory) if minimal information needs to be stored (role information for example). This information is then used to authorize the users level of access to the system.

Most applications require more information than just a username and password to customize the user experience. In order to provide the convenience of pre-filling forms, information such as the personal, business and shipping address is also usually needed. Business applications typically need role information that is more fine grained than the roles stored in the directory. These roles are used to customize access and provide the right features to enhance the user experience and ensure that the right users have access to the features they need to do their work efficiently. Querying a repository each time this information is needed can be cumbersome especially when that directory is not local to the system. The other option is to store specific user information within the applications native repository. The problem with that is that this information is typically duplicated and distributed in the various places this information is needed. Managing this distributed system can be quite a challenge.

Claims based identity model

Claims based security is based on the concept that the identity of a person can be represented by a set of claims about that person. A claim is a bit of information that describes the person in a way that is digitally useful. Claims typically contain the usual user name, or email, but they can include much more. Information such as roles, phone numbers, zip codes, addresses, anything that is typically used by applications to customize the user experience. An authenticating system creates a security token containing those claims and applications can customize their applications using the content contained in those claims. Such a system is especially beneficial in a federated environment, the federated system can construct the claims token within the local network and make that information available to a system external to that network.

There are several token standards such as the Simple Web Token (SWT), or the XML-based Security Markup Language (SAML), there's currently a proposal out to create a standard JSON formatted security token called the JSON Web Token (JWT). There were several drivers for creating these standards, cookies were proving insufficient to contain all of this information due to their size limitations. Federation requires a standard way to communicate security information across network boundaries and Web Services need a common security language to communicate between the communicating parties.

So who issues these tokens?
There are many systems that issue these tokens, they are as far ranging as the Kerberos driven domain controllers in your windows network to the Facebook token that's generated when you log in to facebook. Google, Yahoo, Microsoft Live all generate claims based security tokens. These tokens are digitally signed by the issuing authority, and it's up to the application to determine if it trusts the issuer.

The System

The systems that issue these tokens are called security token services (STS), they build the token, sign it and then return it to calling application. They systems follows these steps to generate the token

1. In this step the user interacts with an application
2. The application requests an Claims based token from the STS
3. The STS authenticates the user and queries the directory for claims relating to the user.
4. The STS builds the Token and returns it to the application, the application uses the claims to authorize the user.

The application can be configured to accept tokens from various trusted issuers. If the application trusts the issuer it can assume that the claims contained in the token are correct and authorize the users level of access. The benefit of this is that the responsibility of authenticating and assembling user information is removed from the application. The user information is centralized and easier to manage. This does assume that an administrator or administrative system has to configured STS to with the claims the application will need. This is not an extra step in the system, because this would have had to be done anyway, the difference is the place that this is done. The information is centralized and in a complex system, easy to manage.

By organizing the system in this way, STS becomes an expert system that knows everything about users, knows how to secure the user information and knows how to secure the transmission of that information.

Implementing all of this is a set of .Net libraries called Windows Identity Foundation, these libraries make it easy to integrate STS into your application.
With WIF you'll be able to receive a claims based token, verify the signature and read the claims it contains. WIF supports tokens created using SAML 1.1 or SAML 2.0 formats. ADFS 2.0 and ACS are able to issue tokens in those formats and WIF can work with those issuers as well as other STSs as long as they produce tokens using SAML version 1.1 and higher.

STSs communicate using WS-* standards, policy is retrieved using HTTP GET technology. The claims token is written using the SAML standard mentioned above and all of that together provides an interoperable way for STSs to communicate with each other. This is especially useful in federated system, where STSs in different environments and on different platforms can communicate with each other.

In the next few blogs I'll show example solutions implementing WIF in a federated environment as well as using WIF to integrate with Windows Live, and Facebook.