The process of validation of a user’s identity against the set of authentication values that a provider has given is known as user authentication. There is a database or directory that contains the credentials of the user and can be used to confirm that the user has submitted them correctly. Active Directory Domain Services (AD DS) is the most commonly used type of authentication. However, you may also hear it referred to as the user directory and attribute store.
The authentication method offers a specific exchange of account credentials as well as other information to successfully identify the user. The result of such an authentication method is usually in the form of a token that contains a claim. This is the way that the provider is able to verify that the user has been authenticated.
The specific way that an authentication type works has to do with the validation credential that are in place against at least one of the authenticating providers. This is often done using the industry standard protocol. There can be multiple authentication methods in place at once. After the identity of the user is validated, the authorization process is used to determine the sites, the content, and other features that a given user is able to access.
When it comes to strategizing for your user authentication types and methods, there are several things to take into consideration:
- The user authentication types and methods for each of the web applications and each of the zones.
- The authentication infrastructure that is necessary in order to support the determined authentication types and methods.
- The plan to move your current web applications and zones that are using classic mode authentication to using claims based authentication.
The user identity in AD DS is based on a user account that is set up. In order for authentication to be successful, the user must provide the account name and proof of knowledge of the correct password. This is used to determine the access to resources, applications that may need to be queried for AD DS, and a variety of other information such a membership on a network.
This works very well for Windows environments, but it isn’t going to with various 3rd party authentication providers or environments when you have multi-vendors. With claims based identities, the user is able to obtain a digitally signed security token from a commonly trusted identity provider. The token contains the claims within it, and each claim represents a given item of data about a user. This could be their name, their memberships, or the role they have within that network.
With Claims based authentication, the user authentication that offers claims based identity technology and overall infrastructure that relies on a security token from a user instead of credentials. The information that is used comes from the claims to determine access to the various resources. There isn’t a separate query to a directory service including AD DS.
With claims based authentication in Windows, it is built on the Windows Identity Foundation (WIF). This offers a set of .NET framework classes that are used to implement the claims-based identity. The process of claims based authentication is based on standards including WS Federation, WS Trust, and protocols from the Security Assentation Markup Language (SAML).
With the wide use of claims based authentication for user authentication, it is recommended to use claims based authentication for all of the web applications and zones of a SharePoint 2013 farm. When you use claims based authentication, all of the supported authentication methods are offered to you from your web applications. You can use the new features and scenarios that are provided by SharePoint 2013 that also use the server to server authentication and app authentication.
With claims based authentication, SharePoint 2013 automatically will change all of the user accounts to claims identities. This leaves a security token or claims token for each user to benefit from. The claims token contains the claims that pertain to a given user. Windows accounts will be converted to Windows claims. Forms based membership users are transformed into forms based tokens.
SharePoint developers and administrators can use tokens for additional claims. For example, Windows user accounts and forms based accounts can be enhanced with additional claims that are used by SharePoint 2013. You don’t have to be a claims architect either to use claims based authentication in SharePoint 2013. However, when it comes to implementing SAML token based authentication, you have to coordinate with the administrators of your claims based environment.
With SharePoint 2013, like previous versions of SharePoint, you create a web application in Central Administration (WCAM). You will be able to select the authentication types and methods for claims based authentication here. With earlier versions of SharePoint, you also had the ability to configure classic mode authentication for web applications in Central Administration. Classic mode authentication will use both Windows authentication and SharePoint 2013 considers the user accounts as AD DS accounts.
In order to configure a web application for classic mode authentication, you need to use the New-SPWebApplication Windows Powershell cmdlet. With SharePoint 2010 Products web applications, you were able to configure for classic mode authentication through the UI. Allowance for the user to retain their authentication settings when upgrading to SharePoint 2013 is built-in. It is recommended that you move your web applications to claims based authentication however before you upgrade to SharePoint 2013.
Through SharePoint 2013 farms, you can include a mixture of various web applications that use both modes. Most of the services though won’t be different between the user accounts of Windows and Windows claims.