What are claims?
Claim is piece of information that describes given identity on some aspect. Take claim as name-value pair. Claims are held in authentication token that may have also signature so you can be sure that token is not tampered on its way from remote machine to your system. You can think of token as envelop that contains claims about user.
Token may contain different claims:
- username or user ID in remote system,
- full name of user,
- e-mail address,
- membership in security groups,
- phone number,
- color of eyes.
System can use claims to identify and describe given user from more than one aspect. This is something you don’t achieve easily with regular username-password based authentication mechanisms.
Claims-based authentication is more general authentication mechanism that allows users to authenticate on external systems that provide asking system with claims about user. The next image from TechNet library page Authentication Patterns illustrates authentication flow simply and effectively.
Here is authentication flow:
- User makes request to some application.
- System redirects user to authentication page of external system (it may also happen after system lets user to select external system where he or she wants to log in).
- After successful authentication external system redirects user back with some information.
- Application makes request to external system to validate user.
- If user is valid then user gets access to application.
Claims-based authentication in practice
Claims-based authentication can be found from many applications:
- Microsoft SharePoint 2010 and 2013,
- Windows Azure Access Control Services (ACS),
- Active Directory Federation Services (ADFS),
- Applications using Windows Identity Foundation (WIF).
Enabling or Disabling Claims Based Authentication
Claims Based Authentication is becoming so popular these days and enabling a SharePoint site to authenticate users no matter what authentication system is involved just got easier. I will not digress on Claims Based Authentication, not the point of this article, but I will focus on how to enable or disable CBA using PowerShell since there is no GUI available for this trick.
First, make sure your site (web application) does not have the CBA enabled. Go to Central Administration >> Manage web applications and click on the site you’re planning to enable CBA. Under Web Applications tab click on the Authentication Providers icon and a small window will pop-up. Under Default you should see Windows.
Next, create a PowerShell (.ps1) file using Notepad and paste the following code into it:
|$setcba = Get-SPWebApplication “http://YourSiteURL”
$setcba.UseClaimsAuthentication = 1;
Give it a name, like SetCB.ps1 and save in under C: on your SharePoint 2010 server.
Open SharePoint 2010 Management Shell, make sure you’re under C: (use CD.. to move under C:)and type or Copy and right-click Paste this command./SetCB.ps1
Hit Enter and after few seconds your SharePoint site should have Claims Based Authentication enabled.
Repeat the previous steps to check if your site has CBA enabled, Central Administration >> Manage web applications and click on the site, click on the Authentication Providers icon and under Default you should see now Claims Based Authentication.
To revert back to Classic mode authentication (disabled Claims Based Authentication) just change the 1 to a 0:
|$setcba = Get-SPWebApplication “http://YourSiteURL”
$setcba.UseClaimsAuthentication = 0;
One of the toughest things about discussing claims-based authentication is the vocabulary. A few terms must be understood:
- Claim : A Claim represents an information regarding the identity(generally the user to be authenticated).
- Security Token : A set of claims in the digital context is referred to as a token, or security token.
- Identity Provider(IdP) : The IdP is responsible for issuing (hence, also called “issuer” ) security tokens and acting as the producer of assertions.
- Service Provider(SP) : Any application ( SharePoint for example) which intends to provide service to user .It is also called Relying Party (RP) – in the sense it relies on IdP for authentication.
- Relying Party(RP) : The RP trusts the IdP as the authority for identity. The RP verifies user through a security token that is formatted and signed by the IdP.
- Security Token Service (STS): The system used by the IdP to create and sign the security token is the STS. The RP also have an STS to consume the security token.
- Subject: The user, who uses the SP (authenticating with the IP) is generally called the Subject.
- Security Assertion Markup Language(SAML) is an XML-based open standard data format for exchanging authentication and authorization information (which is nothing but Security Token) between parties, in particular, between an IdP and a SP.
Steps occurring while a Claims based Authentication process in SharePoint:
- The Subject(User) sends a request for a resource inside SharePoint (which act as Service Provider).
- SharePoint returns a request for authentication and redirects the user to the STS of the trusted IdP – which may be a Active Directory Federation Services (ADFS)
- The user gets authenticated within the IP/STS.
- If the credentials are valid, the issued security token by IdP is sent to the SharePoint STS which responds by adding claims to the token.
- SharePoint receives the issued token,which is then used to access the requested resource.
All the future requests to SharePoint simply use the previously issued token. The issued security token is implemented as a persistent and encrypted cookie namedFedAuth.