Compartir a través de

Claims Based Authentication – An Overview

  • Artículo

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.”

clip_image002

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

clip_image003

Comments

  • Anonymous
    January 01, 2003
    PingBack from http://www.tscmpro.com/?p=4647

  • Anonymous
    January 01, 2003
    Kudos, pictures are self explanatory.

  • Anonymous
    June 16, 2010
    Hi Rick,   Very nice and easily understandable information. I have a question. Does this also works when we have a Global LDAP Directory rather than an AD? Thanks Vishwas

  • Anonymous
    June 23, 2011
    nice article

  • Anonymous
    April 04, 2012
    How can one revert back to Classic Mode Authentication?

  • Anonymous
    April 20, 2012
    please give me web site

  • Anonymous
    June 06, 2012
    Once we have switched to Claims Based Authentication, we cannot convert back to Classic Authentication