Claims-based identity is a means of authenticating an end user, application or device to another system in a way that abstracts the entity's specific information while providing data that authorizes it for appropriate and relevant interactions.
This authentication method provides user information automatically so applications do not need to request it of the user and the user doesn't have to provide that information separately for different applications.
Benefits of claims-based identity
Claims-based identity offers a number of advantages when implementing authentication, including:
- Outsourcing authentication. Claims-based identity removes the need for applications to perform authentication tasks, making account management easier by centralizing authentication. Applications do not need to be responsible for user authentication, looking up the details of users' identities, storing user accounts and passwords, or integrating with other identity systems. Additionally, centralizing authentication makes it easier to upgrade applications to stronger authentication methods.
- Supporting multiple authentication providers. Claims-based identity enables companies to easily implement different authentication methods using different providers, e.g., Windows Live ID, Windows Active Directory authentication or forms-based authentication for a website. This is done using single sign-on to support users who access web services or web applications in various ways, including over the internet, from within the organization and through affiliated organizations.
- Supporting federation of identities. Claims-based identity enables external users in one organization to access the network applications of another company using their own identities.
- Claims-based identity offers more versatility because organizations can create additional attributes as claims on which to base access control.
How claims-based identity works
Claims-based identity is one type of identity access management system, which is a framework for business processes that facilitates the management of electronic identities. The framework includes the technology needed to support identity management.
Claims are pieces of information about a user that have been packaged, signed into security tokens and sent by an issuer or identity provider to relying party applications through a security token service (STS). The data is then transmitted using a standard method, such as the Security Assertion Markup Language (SAML), so that the claims will have the same format across different authentication sources and applications.
Claims-based identity has been incorporated into the Microsoft .NET Framework as part of the Windows Identity Foundation (WIF). The WIF is a set of .NET Framework classes for implementing claims-based identity that was developed to simplify and unify this identity approach for client-server and Microsoft Azure cloud applications.
A security token service acts as an issuing authority, accepting incoming credentials, validating them and creating a secure token with the list of claims. The tokens are encrypted and sent to an application. It is important that the issuer of the token is a trusted entity, such as Microsoft, Facebook or Google.
Microsoft's Active Directory Federation Services (AD FS) is a type of STS. AD FS is a feature of the Windows Server operating system that extends end users' single sign-on access to applications and systems outside the corporate firewall. AD FS uses a claims-based access control authorization model that involves authenticating users via cookies and SAML.
Claims-based identity process
Claims-based identity depends on trust relationships being established between those making the claims and any relying parties. A relying party is an application or device that relies on claims for user identity and access control. A relying party will only accept claims about a user's identity from a trusted issuer.
Claims are sent to relying parties in the form of security tokens in a number of formats, including XML-based SAML or Simple Web Token (SWT). The STS processes token requests from relying parties.
The STS packages one or more claims into a security token, signs it cryptographically and sends it to a relying party encrypted on the wire. Then, when a relying party receives the token, it verifies the token signature and, if it's valid, it uses the claims for any other necessary decision-making, such as authorization checks or personalization.
The claims-based identity process is as follows:
- A user requests access to an application.
- The application sends a request to the STS for a token for that user.
- The STS authenticates the user, e.g., with a password, biometric scan or smart card.
- The STS creates the token.
- The STS signs the token digitally and the digital signature is then part of the token.
- The STS sends the token back to the application that requested it.
- The application verifies the validity of the digital signature and confirms that it came from an STS that the service or application trusts.
- The application processes the claims data to determine whether to allow the user to access the application, as well as the level of access the user will have.
The process can be more complicated, as there are two kinds of STS: Identity Provider STS authentication relies on an authentication service, such as the one provided by Active Directory; the Relying Party STS authenticates using tokens that have been provided by a trusted Identity Provider STS.