Improvements in Claim Infrastructure in SP 2013

SP2013 includes following improvements in claim Infrastructure:

1. Easier migration from classic mode to Windows based claim mode with new Convert-SPWebApplication windows PowerShell. Migration can be run against each content database and each web application. This is in contrast to SP2010 products, in which the migration run against the each web application.

Parameters: Convert-SPWebApplication

 

Parameter	Required	Type	Description
Identity	Required	Microsoft.SharePoint.PowerShell.SPWebApplicationPipeBind	Specifies the URL of the web application that you want to convert, for example: http://mysite/app1
To	Required	System.String	Specifies the string Claims that dictates that the application needs to be converted to claims authentication mode.
AssignmentCollection	Optional	Microsoft.SharePoint.PowerShell.SPAssignmentCollection	Manages objects for the purpose of proper disposal. Use of objects, such as SPWeb or SPSite, can use large amounts of memory and use of these objects in Windows PowerShell scripts requires proper memory management. Using the SPAssignment object, you can assign objects to a variable and dispose of the objects after they are needed to free up memory. When SPWeb, SPSite, or SPSiteAdministration objects are used, the objects are automatically disposed of if an assignment collection or the Global parameter is not used. Note: When the Global parameter is used, all objects are contained in the global store. If objects are not immediately used, or disposed of by using the Stop-SPAssignment command, an out-of-memory scenario can occur.
Force	Optional	System.Management.Automation.SwitchParameter	Forces the conversion of the web application.
RetainPermissions	Optional	System.Management.Automation.SwitchParameter	Specifies the account under which the cmdlet is run and retains the permission in the web application.

Detailed Description

Use the Convert-SPWebApplication cmdlet to convert the authentication mode of a Web application to Windows Claims authentication mode and migrate the user accounts in the content database to claims encoded values.

 

2. Login tokens are now cached in the new Distributed Cache Service (DCS). SP13 uses a new Distributed Cache Service to cache login tokens. In SP2010 the login token is stored in the memory of each WFE server. Each time a user accesses a specific WFE server. It needs to authenticate. If you use network load balancers in front of your WFE's, user needs to authenticate for each WFE server that is accessed behind the load balancer, causing possible multiple re-authentications. To avoid re-authentication and delay, it is recommended to enable and configure load balancer affinity (also known as sticky session). By storing the login tokens in DCS in SP13, the configuration of affinity in your load balancing solution is no longer required. There is also scale-out benefits and less memory utilization in the WFE's because of DCS.
3. Authentication Logging: more logging make troubleshooting easier.
1. Separate categorized-claim related logs for each authentication mode.
2. Information about adding and removing FedAuth cookies from DCS.
3. Information about the reason why a FedAuth cookie could not be used, such as a cookie expiration or a failure to decrypt.
4. Information about where authentication request are redirected.
5. Information about the failures of user migration in a specific site collection.