First things First
If you are looking for an article that show a lot of code and dissects the new WIF 4.5 APIs, then you won’t find what you need here.
My aim in this article is to explain the “why” and the “what” rather than the “how”. Once you understand that, the “how” becomes really simple. This article does not assume pre-knowledge of the topics of federation, claims, and WIF so it’s suited for beginners. However, I think that also mid-level knowledge audience will also benefit from it. If you’re like super-expert, well please contact me to help me in my current projectJ.
What is Exactly the Problem?
Authentication (and authorization) is an ever present challenge for almost all applications. The challenge that these applications face is the same: authentication logic creeps into the application code and becomes coupled with it; any change to the authentication requirements will result in a change in the application itself.
Say for example that your user store is SQL Server and new business mandates adding an existing Oracle-based user store to your list of users, or maybe you want to mix your authentication to support both custom user stores (SQL Server or Oracle) with Active Directory user store. And what about social media? It’s increasingly popular nowadays for applications to allow authentication via services such as Google and Facebook.
Here is another tough case: assume you used to ask you users for username/password combination to log in. Now based on certain needs, you want them also to supply additional information such as a one-time code. This will certainly lead to UI change for your login page as well as code change.
In all these cases, something has to change in your code. Of course, having a good architecture with a proper separation of concerns will ease up the change. However, the idea is that you still have to manage this authentication logic instead of focusing on the business side of your application.
Claims-based authentication is the architecture that solves this problem.
Claims-based Authentication
Claims-Based architecture allows you to delegate authentication logic into another entity. This entity is a “some” layer which abstracts all authentication related coding and gives your application what it needs: is the user authenticated or not, and some information about the user (called claims or assertions) that lets your application take authorization decisions.
The claims-based architecture defines the following actors:
Subject: the entity that needs to be authentication. This can be a user that wants to log in to your application, or a piece of code in your application that wants to access a web service.
Relying Party (RP): the application (in case the Subject is a user) or the web service (in case the Subject is application code) that needs to delegate the authentication logic
Identity Provider (IP): the entity (that “some” layer mentioned before) that actually holds the authentication logic. The IP talks to the user stores as appropriate and performs actual authentication.
Claim: When an IP performs successful authentication, it returns to the RP a set of claims. Claims are statements about the authenticated entity – for example birth date, department, role, etc… – that gives the RP information to take authorization decisions.
Token: Claims travel inside a token. Although a token can be a username/password combination or even a simple string such as bearer token in OAuth 2.0; in this context tokens can be either XML-based such as SAML tokens or binary-based such as X.509 certificates.
In addition to the above definitions, WS-Federation and WS-Trust protocols define another term called Secure Token Service (STS). STS is the web service exposed by the IP that provides the authentication service.
Before the claims-based flow can start, the RP and IP need to publish their policies. In abstract terms, a policy is a contract published by an entity that specifies the terms and conditions that other entities must obey before establishing communication.
In this context, the policy published by the IP specifies the supported protocol(s) and security requirements as well as supported claim types. Similarly, the policy published by the RP specifies its own protocol, security, and claims requirements as well as the list of IPs it trusts to delegate authentication to.
The rest of the article discusses WS-Federation (and related WS-standards) and its implementation in WIF, while I will also briefly discuss SAML 2.0.
Read more: Codeproject