SharePoint Server 2013 uses claims-based authentication as its default authentication model, and it is required to enable its advanced functionality. Using claims-based authentication has the following advantages over using Windows classic-mode authentication:
- External SharePoint apps support. App authentication and server-to-server authentication rely on claims-based authentication. With Windows classic-mode authentication you are unable to use external SharePoint apps. You also cannot use any services that rely on a trust relationship between SharePoint and other server platforms, such as Office Web Apps Server 2013, Exchange Server 2013, and Lync Server 2013.
- Claims delegation without “double-hop” limitation. SharePoint can delegate claims identities to back-end services, regardless of the sign-in method. E.g., suppose your users are authenticated by NTLM authentication. NTLM has a well-known “double-hop” limitation, which means that a service such as SharePoint cannot impersonate the user to access other resources on behalf of the user, such as SQL Server databases or web services. When you use claims-mode authentication, SharePoint can use the claims-based identity token to access resources on behalf of the user.
- Multiple authentication providers per one web application. When you create a web application in claims-based authentication mode, you can associate multiple authentication providers with the web application. It means, that, for example, you can support Windows-based sign in and forms-based sign in without creating additional IIS websites and extending your web application to additional zones.
- Open standards. Claims-based authentication is based on open web standards and is supported by a broad range of platforms and services
There are several supported scenarios for migrating or converting from classic mode to claims mode authentication which performed with use of a number of Windows PowerShell cmdlets: you either switch your web apps on SP2010 before upgrade to SP2013 or you can convert SharePoint Server 2010 classic-mode web applications to SharePoint Server 2013 claims-mode web applications after you have SP2013 installed already.
Steps to switch your SP2010 web apps to claims based authentication:
1. Enable claims authentication for your web app.
$WebAppName = "http://portal.denallix.com"$wa = get-SPWebApplication $WebAppName
$wa.UseClaimsAuthentication = $true
$wa.Update()
2. Configure the policy to provide the user with full access.
$account = "Denallix\Administrator"$account = (New-SPClaimsPrincipal -identity $account -identitytype 1).ToEncodedString()
$wa = get-SPWebApplication $WebAppName
$zp = $wa.ZonePolicies("Default")
$p = $zp.Add($account,"PSPolicy")
$fc=$wa.PolicyRoles.GetSpecialRole("FullControl")
$p.PolicyRoleBindings.Add($fc)
$wa.Update()
3. Perform the migration.
$wa.MigrateUsers($true)
4. Provision claims
$wa.ProvisionGlobally()
Once done you with these changes may verify that you are using Claims Authentication for your web application:
GUI way. In Central Administration navigate to web application management, select your Web Application and click on Authentication Providers button:
It will open a window where you can verify your default authentication mode:
PowerShell way:
$web = Get-SPWebApplication "http://portal.denallix.com"$web.UseClaimsAuthentication
It will return True or False depending on whether you have Claims Authentication enabled or not (screenshot below for enabled state):
In case you have K2 components installed you may need to perform relevant configuration changes on K2 side (see Claims Authentication Configuration section at help.k2.com) which I will cover in separate blog post.
In case if you are in a mood for deep dive into what & why of claims authentication subject you may read through the following articles:
Identity (Management) Crisis (Part 1): The evolution of identity concepts
Identity (Management) Crisis (Part 2): Everything you (think you) know is wrong
Identity (Management) Crisis (Part 3): Solving the Identity Problem
Identity (Management) Crisis (Part 4): Selecting a Comprehensive Identity Management solution
Claims Based Identity: What does it Mean to You? (Part 1)