The token authentication architecture in SharePoint 2013 is in place for implementing a SAML token based providers with these components:
- SharePoint Security Token Service This service creates the SAML tokens for the farm to use. The service is created and started on all the servers within that server farm. This service is used for inter-farm communication because such communication always uses claims based authentication. This service is also used to authenticate with methods for implementing web application that use claims based authentication. This includes Windows, forms based, and SAML token based authentication.
- Token Signing Certificate (Import Trust Certificate) This certificate allows you export from an IP-STS and then to copy to a sever in the farm. It can also be added to the Trusted Root Authority list of that farm. This certificate can be used to create an SP Trusted Identity Token Issuer only once. Before you can create another, you have to delete the existing one. Before you can delete it, you have to remove it from all the web applications that use it.
- Identity Claim This is the claim from a SAML token and it is the unique identifier for a user. The owner of the IP-STS is the only one that knows the value in the token that will be unique for each of the users. The identity claim is created the same as a regular mapping process for all of the desired claims. The claim that will be the identity is declared at the time that the SP Trusted Identity Token Issuer is created.
- Other Claims This type of claim consists of additional claims that stem from an SAML ticket which describes the user. This can include user roles, groups, or other types of claims including age. All of the mapping for these claims are created as objects. They are replicated across the servers in a SharePoint 2013 farm.
- Realm The SharePoint claims architecture is the URI or URL associated with a SharePoint web application. It is configured to use an SAML token based provider in order to successfully represent the realm. When the SAML based authentication provider for the farm is created, you have to specify the realms that you want the IP-STS to recognize. You have to do this one at a time. The first realm will be determined when you create the SP Trusted Identity Token Issuer. It is acceptable to add more realms once you create it. Realms will be specified by using syntax. Once you have added the realm to the SP Trusted Identity Token Issuer, you have to create a RP-STS with the realm identifier for the IP-STS sever. This is a process that requires specification of the URL for the web application.
- SP Trusted Identity Token Issuer This is an object created on the SharePoint farm. It includes the values required to communicate with and to receive tokens from the IP-STS. When you create it, you have to specify which token signing certificate to use. You can only associate a token signing certificate from an STS with 1 SP Trusted Token Issuer. You can add more realms for additional web application. Once you add a realm, you also have to add it to the IP-STS as it is a relying party. The SP Trusted Identity Token Issuer is duplicated across the servers in the SharePoint 2013 farm.
- Relying Party Security Token Service (RP-STS) Each web application that is configured to use an SAML provider in SharePoint 2013 has to be added to the IP-STS server. It needs to be added as an RP-STS entry. There can be many RP-STS entries for a given SharePoint 2013 farm.
- Identity Provider Security Token Service (IP-STS) The secure token service in the claims environment. It is responsible for issuing SAML tokens for the users who are included in the associated user directory.
Below is the SharePoint 2013 SAML token claims configuration process:
- Export the token signing certificate from the IP-STS. Copy that certificate to a server in the SharePoint 2013 farm.
- Define the claim that is to be considered the unique identifier of the user. This is the identity claim. The User Principal Name (UPN) or the email name is often used as the user identifier. By coordinating with the administrator of the IP-STS, you can determine the correct identifier. Only the owner of the IP-STS knows the value in the token that will be unique for each user. Identifying that using identifier is an important part of the claims mapping process. This is done in Windows PowerShell.
- Define additional claims mappings from the incoming token that the SharePoint 2013 farm is going to use. The roles of users are an example of a claim that can be used for assigning permissions to resources in the SharePoint 2013 farm. All of the claims from an incoming token that don’t have mapping will be disposed of.
- To create a new authentication provider for importing the token signing certificate, use Windows PowerShell. This is the process that creates the SP Trusted Identity Token Issuer. This process allows you to specify the identity claim and additional claims that you have mapped. It is also necessary to create and specify a realm to be associated with the first SharePoint web application. They have already been configured for SAML token based authentication at this point.
- Each realm that you add to the SP Trust Identity Token Issuer has to be created with an RP-STS entry on the IP-STS. This can be done before you implement the SharePoint web application. It is important to plan the URL before you create any of the web applications.
- With a new or existing SharePoint web application, you can configure it to use the newly created authentication provider. This is displayed as a trusted identity provider in Central Administration. You will see it when you create a new web application.
It is possible to configure many SAML token based authentication providers. Keep in mind that you can only use a token signing certification once per farm though. All of the configured providers will be displayed as options in the Central Administration. The claims from different trusted STS environments won’t conflict with each other.
When you implement SAML token based authentication with a partner company and your own environment with IP-STS, it is a good idea to work with the administrator of your internal claims environment. Establish a one way trust relationship that will be in place for your internal IP-STS and the partner STS. You won’t have to add an authentication provider to your SharePoint 2013 farm to do so. Your claims administrators will be able to manage all of your claims environment. It is very important to understand you won’t have to set network load balancing for a single affinity when you use claims based authentication in SharePoint 2013 Preview. Any time a web application is configured for use with SAML token based authentication, the SP Trusted Claim Provider class won’t provide search functions for the People Picker Control. Therefore, text that is entered in the People Picker Control will be automatically displayed.