This article is simply a summary of what I call importing things to know by reading TechNet. An authentication method is a specific exchange of account credentials and other information that assert a user’s identity. An authentication type is a specific way of validating credentials against one or more authentication providers, sometimes using an industry standard protocol. An authentication type can use multiple authentication methods. After a user’s identity is validated, the authorization process determines which sites, content, and other features the user can access. Determine your user authentication types and methods for each web application and zone, the authentication infrastructure needed.
About Claims-based authentication
Claims-based authentication is user authentication that uses claims-based identity technologies and infrastructure where a user obtains a digitally signed security token from a commonly trusted identity provider and the token contains a set of claims. Each claim represents a specific item of data about a user such as his or her name, group memberships, and role on the network. Applications that support claims-based authentication obtain a security token from a user, rather than credentials, and use the information within the claims to determine access to resources. No separate query to a directory service such as AD DS is needed.
Claims-based authentication in Windows is built on Windows Identity Foundation (WIF), which 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 the Security Assertion Markup Language (SAML).
For more information about claims-based authentication, see the following resources:
Recommend claims-based authentication for all web applications and zones of a SharePoint 2013 farm. When you use claims-based authentication, all supported authentication methods are available for your web applications and you can take advantage of new features and scenarios in SharePoint 2013 Preview that use server-to-server authentication and app authentication.
SharePoint 2013 Preview automatically changes all user accounts to claims identities. This results in a security token (also known as 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. SharePoint 2013 Preview can use claims that are included in SAML-based tokens. Plan for SAML token-based authentication.
A SharePoint 2013 Preview farm can include a mix of web applications that use both modes. Some services do not differentiate between user accounts that are traditional Windows accounts and Windows claims accounts. For information about how to create web applications that use classic mode authentication in SharePoint 2013 Preview, see Create web applications that use classic mode authentication in SharePoint 2013 Preview.
SharePoint 2013 supports a variety of authentication methods and authentication providers for the following authentication types:
- Windows authentication,
- SAML token-based authentication
- Forms-based authentication
Windows authentication Type
NTLM is the simplest form of Windows authentication to implement and typically requires no additional configuration of authentication infrastructure. Simply select this option when you create or configure the web application. Both NTLM and the Kerberos protocol are Integrated Windows authentication methods, which let users seamlessly authenticate without prompts for credentials. The Windows authentication type takes advantage of your existing Windows authentication provider (AD DS) and the authentication protocols that a Windows domain environment uses to validate the credentials of connecting clients.
Windows authentication methods, which are used by both claims-based authentication and classic mode, include the following: NTLM, Kerberos, Digest, Basic. For more information, see Plan for Windows authentication in this article.
SAML token-based authentication Type
SharePoint Security Token Service (SPSTS) This service creates the SAML tokens that the farm uses and is automatically created and started on all servers in a server farm. SPSTS is used for inter-farm communication because all inter-farm communication uses claims-based authentication. This service is also used for authentication methods that are implemented for web applications that use claims-based authentication. This includes Windows authentication, forms-based authentication, and SAML token-based authentication.
SAML token-based authentication in SharePoint 2013 Preview uses the SAML 1.1 protocol and the WS-Federation Passive Requestor Profile (WS-F PRP). If you use Active Directory Federation Services (AD FS) 2.0, you have a SAML token-based authentication environment. A SAML token-based authentication environment includes an identity provider security token service (IP-STS). An AD FS 2.0 server is an example of an IP-STS. The IP-STS issues SAML tokens on behalf of users whose accounts are included in the associated authentication provider. Tokens can include any number of claims about a user, such as a user name and the groups to which the user belongs.
SharePoint 2013 Preview takes advantage of claims that are included in tokens that an IP-STS issues to authorized users. In claims environments, an application that accepts SAML tokens is known as a relying party STS (RP-STS). A relying party application receives the SAML token and uses the claims inside to decide whether to grant the client access to the requested resource. In SharePoint 2013 Preview, each web application that is configured to use a SAML provider is added to the IP-STS server as a separate RP-STS entry. A SharePoint farm can represent multiple RP-STS entries in the IP-STS. For more information, see Plan for SAML token-based authentication.
Summary Implementation Steps
- Export the token-signing certificate from the IP-STS. Copy the certificate to a server in the SharePoint 2013 Preview farm.
- Define the claim that will be used as the unique identifier of the user. This is known as the identity claim. The user principal name (UPN) or user e-mail name is frequently used as the user identifier. Coordinate with the administrator of the IP-STS to determine the correct identifier because only the owner of the IP-STS knows the value in the token that will always be unique per user. Identifying the unique identifier for the user is part of the claims-mapping process. You use Windows PowerShell to create claims mappings.
- Define additional claims mappings. Define the additional claims from the incoming token that the SharePoint 2013 Preview farm will use. User roles are an example of a claim that can be used to assign permissions to resources in the SharePoint 2013 Preview farm. All claims from an incoming token that do not have a mapping will be discarded.
- Use Windows PowerShell to create a new authentication provider to import the token-signing certificate. This process creates the SPTrustedIdentityTokenIssuer. During this process, you specify the identity claim and additional claims that you have mapped. You must also create and specify a realm that is associated with the first SharePoint web applications that you are configuring for SAML token-based authentication. After you create the SPTrustedIdentityTokenIssuer, you can create and add more realms for additional SharePoint web applications. This is how you configure multiple web applications to use the same SPTrustedIdentityTokenIssuer.
- For each realm that you add to the SPTrustedIdentityTokenIssuer, you must create an RP-STS entry on the IP-STS. You can do this before the SharePoint web application exists. Regardless, you must plan the URL before you create the web applications.
- For an existing or new SharePoint web application, configure it to use the newly created authentication provider. The authentication provider is displayed as a trusted identity provider in Central Administration when you create a web application.
You can configure multiple SAML token-based authentication providers. However, you can only use a token-signing certificate once in a farm. All configured providers are displayed as options in Central Administration. Claims from different trusted STS environments will not conflict.
For detailed steps to configure SAML token-based authentication using AD FS, see Configure SAML-based claims authentication with ADFS in SharePoint 2013 Preview.
For additional information about SAML token-based authentication, see the following resources:
TechNet blog article: Planning Considerations for Claims Based Authentication in SharePoint 2010
TechNet blog article: Creating both an Identity and Role Claim for a SharePoint 2010 Claims Auth Application
TechNet blog article: How to Create Multiple Claims Auth web Apps in a Single SharePoint 2010 Farm
Forms-based authentication Type
Forms-based authentication is a claims-based identity management system that is based on ASP.NET membership and role provider authentication. Forms-based authentication can be used against credentials that are stored in an authentication provider, such as the following: AD DS, A database, LDAP data store such as Novell eDirectory, Novell Directory Services (NDS), or Sun ONE. Forms-based authentication validates users based on credentials that users type in a logon form (typically a web page). The system issues a cookie for authenticated requests that contains a key for reestablishing the identity for subsequent requests. For more information, see Plan for forms-based authentication.
Users can access SharePoint content without validating their credentials. Anonymous authentication is disabled by default. You typically use anonymous authentication on public Internet website. Note that in addition to enabling anonymous authentication, you must also configure anonymous access (permissions) on sites and site resources.
Digest and Basic
You might have to use these older authentication methods if your environment uses web browsers or services that only support Digest or Basic authentication to websites. With the Digest authentication method, the user account credentials are sent as an MD5 message digest to the Internet Information Services (IIS) service on the web server that hosts the web application or zone. With the Basic authentication method, the user account credentials are sent as plaintext. Therefore, you should not use the Basic authentication method unless you are also using SSL to encrypt the website traffic.
The following steps summarize configuring Kerberos authentication: Configure Kerberos authentication for SQL Server communications by creating SPNs in AD DS for the SQL Server service account. Create SPNs for web applications that will use Kerberos authentication. Configure specific services within the farm to use specific accounts. Create the web applications that will use Kerberos authentication. For more information about how to plan for the Kerberos protocol, see Plan for Kerberos authentication in SharePoint 2013 Preview.
People Picker control Important Note
When a web application is configured to use SAML token-based authentication, the SPTrustedClaimProvider class does not provide search functionality to the People Picker control. Any text entered in the People Picker control will automatically be displayed as if it resolves, regardless of whether it is a valid user, group, or claim. If your SharePoint 2013 Preview solution uses SAML token-based authentication, plan to create a custom claims provider that implements custom search and name resolution. For more information, see Custom claims providers for People Picker (SharePoint Server 2010).