Claims Based Authentication – An Overview
I thought I would discuss a little about what Claims Auth (ClaimsAuth) is and why its important for you to know. In an article from Network World, it was stated that Claims Authentication is a new feature in SharePoint 2010 and understanding it will assist administrators in designing and maintaining robust infrastructures and help make implementing other functionality (such as PeoplePicker) a little easier.
The SharePoint Team blog stated that SharePoint will be a Claims aware application where users will present to it a list of “claims” and SharePoint will The gist is that there are claims (or assertions) that are made about an entity.
So code name “Geneva” has been out for a little while and word has it that it plays an integral part in SharePoint 2010. Why is it important?
According to Microsoft: “Geneva” is Microsoft’s next generation identity and access management platform built on Active Directory® directory services. “Geneva” provides claims-based access and single sign-on for on-premises and cloud-based applications in the enterprise, across organizations, and on the Web. “Geneva” leverages claims which describe identity attributes and can be used to drive application and other system behaviors with an open architecture that implements the industry’s shared Identity Metasystem vision.”
There are several components to ClaimsAuth. The STS is the component that issues tokens to entities and these tokens contain claims. A security token service makes claims about entities. It issues security tokens containing claims. A relying party is an application that accepts and consumes tokens. It makes decisions based on these claims. It may also generate and issue managed information cards. (Remember Card Space?)
Another component is called the federation provider, which manages trusts for relying parties and translates claims into a way that the relying party understands. Think of the Federation Provider as the “universal translator”. (For example, a claim of ROOT would get translated to a claim of ADMIN.
Another component is the authorization provider, which makes decisions about how to render access control. So the typical sequence is that the user agent authenticates with the identity provider and obtains tokens containing claims. The user agent presents these claims to the federation provider, which returns a set of claims relevant to the relying party. The client software then sends these claims in application message to the relying party. The relying party uses these to make an access control decision with the help of authorization provider.
Figure 1 - Courtesy of Network World