What is SharePoint Claims Authentication?
The claims-based identity is an identity model in Microsoft SharePoint that includes features such as authentication across users of Windows-based systems and systems that are not Windows-based, multiple authentication types, stronger real-time authentication, a wider set of principal types, and delegation of user identity between applications.
Claims-based identity is based on the user obtaining a security token that is digitally signed by a commonly trusted identity provider and contains a set of claims. Each claim represents a specific item of data about the user such as his or her name, group memberships, and role on the network. Claims-based authentication is user authentication that utilizes claims-based identity technologies and infrastructure. Applications that support claims-based authentication obtain the security token from the user and use the information within the claims to determine access to resources. No separate query to a directory service like Active Directory is needed.
In a simple analogy:
You check in at the Airport (Authentication)
– present credentials (Passport)
– credentials are validated by security guard
You receive a boarding pass (Signed Claims)
– Seat, Frequent Flyer, Gate etc.
Think of a claim as a piece of identity information (for example, name, e-mail address, age, or membership in the Sales role). The more claims your application receives, the more you know about your user. These are called “claims” rather than “attributes,” as is commonly used in describing enterprise directories, because of the delivery method. In this model, your application does not look up user attributes in a directory. Instead, the user delivers claims to your application, and your application examines them. Each claim is made by an issuer, and you trust the claim only as much as you trust the issuer. For example, you trust a claim made by your company’s domain controller more than you trust a claim made by the user.
Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which was formerly known as the Security Token Service, or STS. Many areas of SharePoint still refer to the name STS so it’s important to understand that it and WIF are one in the same. The Security Token Service comes pre-baked into the standard SharePoint 2010 install:
The Security Token Service Application in Central Administration:
The Security Token Service Application in IIS:
WIF is a set of .NET Framework classes that is used to implement claims-based identity. Claims-based authentication relies on standards such as WS-Federation, WS-Trust, and protocols such as SAML.
Microsoft recommends Claims-based authentication as the preferred provider to use on fresh SharePoint 2010 installs. You can configure this on a per-Web Application basis in SharePoint via the following dialog in Central Admin > Web Applications > Manage Web Applications > Ribbon Bar – New
If you select Classic-Mode Authentication, you configure the Web application to use Windows authentication and the user accounts are treated by SharePoint Server 2010 as Active Directory Domain Services (AD DS) accounts.
If you select Claims-Based Authentication, SharePoint Server automatically changes all user accounts to claims identities, resulting in a claims token for each user. The claims token contains the claims pertaining to the user. Windows accounts are converted into Windows claims. Forms-based membership users are transformed into forms-based authentication claims. Claims that are included in SAML-based tokens can be used by SharePoint. Additionally, SharePoint developers and administrators can augment user tokens with additional claims. For example, Windows user accounts and forms-based accounts can be augmented with additional claims that are used by SharePoint Server 2010.
|Claims Based Authentication (Tokens)
||Classic Mode Authentication
|-Windows Authentication: NTLM/Kerberos, Basic-Forms-based Authentication (ASP.NET Membership provider and Role Manager)
-Trusted Identity Providers-Custom Sign-in page
|-Windows Authentication (NTLM/Kerberos) only
*Both map authenticated users to the same SPUser object (security principles)
What does Claims look like/feel like?
The core process of Claims is illustrated as follows:
The core currency of Claims is the identity token.
i = Identity Claim all other claims will use “c” as opposed to “i”
: = Colon separator
0 = Reserved to support future Claims
#/? = Claim Type Encoded Value. The out of the box claim types will have a hardcoded encoded value, this will enable parity across farms.
E.g. Key: ? Value: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier
Key: # Value: http://schemas.microsoft.com/sharepoint/2009/08/claims/userlogonname
./0 = Claim Value Type. The out of the box claim value types will have a hardcoded encoded value, this will enable parity across farms.
E.g. Key: . Value: urn:oasis:names:tc:xacml:1.0:data-type:rfc822Name
Key: 0 Value: http://www.w3.org/2001/XMLSchema#string –
w/m/r/t/p/s = Original Issuer Type -> w = windows, m = membership, r = role, t = trusted STS, p = personal card, s= local sts claim
Why do I want to use Claims?
1. Decouples Authentication logic from Authorization and Personalization logic – this means speed and flexibility
2. Provides a common way for applications to acquire the identity information the need about users
3. Cloud-ready – lays the foundation to be able to Authenticate against Azure, Facebook, Google, Windows Live ID etc.
4. Federation – Partner networks, business to business, subsidiaries can all interact in the same sphere of authentication, cross machine and cross-farm
5. Supports existing identity infrastructure (Active Directory, LDAP, SQL, WebSSO etc.)
6. Standards-based and interoperable
7. In SP 2010 we can have a single Web Application configured to use multiple authentication types which allows different auth types to be served from one URL:
General issues for all Claims implementations
– Search crawler requires NTLM in the zone it uses
– Office Client Integration (2007 SP2+, 2010 are minimum requirements in order to maintain Client integration e.g. fluid editing of Word Document)
– SharePoint Designer does not support working with Claims Enabled Endpoints for Web Services
Migration issues when moving from Classic to Claims
– When upgrading from Classic to Claims, you will need to migrate users and Test & re-work customizations (Web parts, workflows etc.)
– After you move to Windows claims, you cannot go back to Windows classic. Ensure that you have good backups before you start and try your migration in a lab first before moving into production.
– Existing alerts may not fire, if this occurs the only workaround may be to delete and recreate the alerts
– Search crawl may not function, double-check the web application policies and ensure that the search crawl account shows the new converted account name. If it does not, you must manually create a new policy for the crawl account.
Configure Forms-based Authentication for a Claims-based Web Application
Configure the Security Token Service
SharePoint and Claims-based Identity
A Guide to Claims-based Identity and Access Control
SharePoint Server 2010 IT Professional Evaluation Guide
Plan Authentication Methods (SharePoint Server 2010) on TechNet
Claims-Based identity with Windows
Claims to Windows Token Service Overview (MSDN)
Claims Based Authentication in SharePoint 2010
Friends don’t Let Friends Use Claims Based Authentication