The claims-based authentication mode was introduced with SharePoint 2010. It employs the concept of claims identity, representing each user’s identity as tokens made of claims. A claim is a statement, asserted by an issuer, about a subject, which is assumed to be true by the reader, due to a trust relationship between the reader and the issuer. The statement can be about any kind of information. For example, it could be the name, the identity, a role membership, a user preference, or anything else. Claims are issued by a claim provider and packaged into a security token, which is emitted by a security token service, which can also be an identity provider or can use an external identity provider. The identity provider is a service that authenticates the end users, based on a specific set of credentials. For example, an identity provider could be Microsoft Windows Live, Facebook, your Active Directory infrastructure with AD FS on top of it, and so on. The target of the security token is a service provider, which can be a website, a web service, or whatever else. The entity described by the security token is called Subject; in general, this is a user, a server, a service, or anything else that can have an identity of its own.

The power of claims-based authentication arises from the fact that claims-based identities are cross platform and can lead your solutions to provide single-sign-on capabilities on multiple platforms using a standard, secure, and reliable protocol. You can use claims to federate your company with customers, resellers, external service providers, and other third parties. Using claims-based authentication and external security token services and identity providers allows you to federate and trust external systems without duplicating users’ credentials and passwords. Only the identity providers will manage credentials and passwords, while all the various service providers will trust the intermediary identity providers and the security tokens emitted by the security token services.

Each claim consists of a ClaimType property, which in general is a URI that uniquely defines the type of the claim; a ClaimValue property, which is the real content of the claim; and a ClaimValueType property, which defines the data type of the ClaimValue property. Each claim can also be described by some other information, such as the Issuer and the target Subject properties.

The capability to describe an identity as a set of claims (a set of true and trustable information) allows supporting any kind of authentication mechanism. In fact, with the claims-based mode, you can use Windows Authentication, but you can also use FBA or any third-party trusted identity provider.

If you use Windows Authentication in claims-based authentication mode, the Windows identities will be converted to a set of claims representing the current user. You can still take advantage of integrated authentication, because the Windows identity of the current user will be translated into claims at no cost to you. In addition, a Windows user authenticated using classic mode is almost the same as a user authenticated with claims-based mode, because internally in SharePoint the user identity is the same (an instance of type SPUser). On the back end, SharePoint 2013 always uses claims identities—regardless of the mode you selected on the front end—to communicate between the front-end servers and the servers (within the same farm) hosting service applications.

In your code, the current user’s identity and principal will be instances of type ClaimsIdentity and ClaimsPrincipal, available in the assembly Microsoft.IdentityModel released with Windows Identity Foundation (WIF) 1.0.

When you are migrating a SharePoint 2010 web application that uses classic-mode authentication to claims-based mode in SharePoint 2013, you can use the PowerShell cmdlet Convert-SPWebApplication. The syntax is as follows:

Convert-SPWebApplication -Identity <SPWebApplicationPipeBind>
    -To <String> 
    [-Force <SwitchParameter>] 
    [-RetainPermissions <SwitchParameter>]

where the Identity argument identifies the web application to convert. The To argument declares the target authentication mode, which by now can only assume the literal value of Claims. There is also an optional Force argument that is useful to keep permissions (RetainPermissions) while migrating. For example, if you want to migrate the web application published at the URL http://migrated.intranet.local/ to claims-based authentication, you can use the following syntax:

Convert-SPWebApplication -Identity http://migrated.intranet.local
    -To Claims –RetainPermissions -Force

The command converts the web application’s authentication mode to Windows Claims authentication mode, which is the most similar to Windows Classic, and migrates the user accounts in the content database to claims-encoded values, keeping their assigned permissions. To execute the migration, you must be a member of the securityadmin role of the target SQL Server database server, a member of the db_owner role of all the content databases that need to be upgraded, and a member of the Administrators group of the server on which you are running the PowerShell script.

After migration, check in the ULS (Unified Logging System) log for any user accounts that are no longer in the Active Directory database (defined in the converted content databases), because they will not be migrated.

If you want to convert only a subset of users to claims-based authentication, such as only those who use a specific content database, PowerShell can help. Specifically, use the MigrateUsersToClaims method provided by the SPWebApplication class.