Author: Nishant Rana

Hi,

I was recently reading about claims-based identity, noted down few important points

How Identity works inside the organization –

The user enters his username and password to login to the domain. Now to access any application in the domain, the user gets the Kerberos ticket for the application from the AD. The ticket contains basic user information and is digitally signed by AD. The user provides this detail to the application, which checks the signature and makes sure it is issued by AD. Application, as it trusts the AD, uses the information in the ticket to perform the corresponding action.

The above authentication works well within an organization boundary, how about if a user wants to access an application from the internet, or belongs to a different domain, to address this we have claims-based authentication, which uses token.

A Token or security token is a set of bytes that expresses information about an entity e.g. a user. Token consists of claims and each claim contain some information about the entity. Token also has a digital signature.

The token is created/issued by STS – secure token service, which is commonly provided by an identity provider.

To get a token, the user will request a token from STS, which will usually ask for the user to provide username and password to authenticate and on successful authentication gets information about the user from the Account / Attribute Store like Active Directory to construct the claims in the token and sends the token back to the user after digitally signing it.

The user submits this token to the application he wants to access. The application uses the identity library to verify the signature of the token and also checks for whether the STS is trusted or not and then can use the claims in the token to define subsequent action that users can perform within the application.

Without claim-based identity, an application either has to authenticates users itself or rely on local 3^rd parties to do that and it only gets only simple information directly from the user like the user’s name.

With claims-based identity, application see just see the token, they only need to decide whether they trust this STS, and application gets the exact information it needs, the STS puts it in the token as claims.

A claim can be used to identify the user, convey group membership, grant or deny access to specific methods, put constraints like purchasing limit, etc.

Through claims-based authentication, we can have an application that trusts multiple identity providers e.g. Google, Microsoft, Facebook etc. at the same time.

Windows Server Active Directory Domain Services –

• Provides Identity services for an organization.
• Relies on Kerberos inside an organization.
• The application can use LDAP to access the data it contains.

Active Directory Federation Services –

• Provides an STS for claims-based identity.
• Supports SAML Security Assertion Mark-up Language and other protocols.

Windows Azure Active Directory –

• Identity and federation provider STS in the public cloud.
• Applications can use the Graph API to access the data it contains

Window Identity Foundation is a standard library incorporated in .NET Framework 4.5 and above to work with claims-based authentication. We can build our STS using WIF.

• Accessing an enterprise application – On-premise (Claims-based Identity)
  

• Accessing an enterprise application – Internet (Claims-based Identity)
  

Check out the white paper / Channel 9 session / Pluralsight by David Chappell course to understand it in-depth

http://www.davidchappell.com/writing/white_papers/Claims-Based_Identity_for_Windows_v2.pdf

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2010/SIA201

https://app.pluralsight.com/library/courses/claims-based-identity-big-picture/table-of-contents

Hope it helps..