Server-to-server authentication involves:
- Identifying the set of trust relationships that have to be configured on a server running SharePoint 2013.
- Consider user profile application services.
The web applications that do include server-to-server authentication end points must be configured to use SSL. It is only necessary to plan for server-to-server authentication on a server that runs SharePoint 2013 if you are going to configure 1 or more server-to-server scenarios.
A server that runs SharePoint 2013 requires a trust relationship with another server. It has to be able to perform a server-to-server authentication with the following in place:
- It trusts requests from a server that is able to perform server-to-server authentication incoming from the server that runs SharePoint 2013.
- The configuration on the server running SharePoint 2013 allows it to trust the authentication of the requesting server.
- The server is able to perform server-to-server authentication trust requests from a server that runs SharePoint 2013. This pertains to the outgoing server that runs it.
- The configuration on the server is able to perform server-to-server authentication. This results in it trusting the requests from the server.
Each farm that runs SharePoint 2013 needs to have a list of servers that it works with for server-to-server authentication. This will allow it to make the incoming requests based on the server-to-server scenarios that the farm offers.
When the farm runs SharePoint 2013 through Office 365, there is no additional configuring that has to be done for server-to-server authentication to be completed.
With server-to-server authentication, it is possible for another server to perform the access to SharePoint. This is done on the behalf of other users, if they have signed into SharePoint 2013. The server that runs SharePoint 2013 offers services that allow the incoming resource request to be able to resolve the specific request of a specified SharePoint user. The set of claims associated with the user goes through a process known as re-hydrating the identity of the user.
This is accomplished through the server performing server-to-server authentication requests. This allows the claims from the incoming security token to resolve it based on that specific user in SharePoint 2013. The default is a built in user profile service application that will resolve the identity.
There are several elements that have to be in place for this re-hydration process to occur:
- Windows Security Identifier (SID)
- Active Directory Domain Services (AD DS)
- User Principle Name (UPN)
- Simple Mail Transfer Protocol (SMTP)
- Session Initiation Protocol (SIP)
At least 1 of them has to be current in the profile of the user. It is recommended to routinely sync them from identity stores to the user profile service application. With SharePoint 2013, only 1 entry is necessary in the user profile service application for it to look up a query based on such attributes.
Should it return an error, then multiple user profiles were identified. Make sure you delete older information from user profiles on a regular basis to prevent this from happening. Sometimes, a user profile does exist but the necessary group membership isn’t synced. This can also result in access being denied when the user should be granted access to a particular resource.
Make sure that the relevant group memberships are synced to the user profile service application. With Windows claims, the user profile service application will import all of the user attributes. With forms based and SAML based claims authentication you have to do 1 of the following steps:
- Create a synced connection to a data source that the user profile service application will support. Then associate with a specific forms based authentication provider. You also have to map attributes from the user stored to the identity attributes mentioned previously.
- Customize code to be able to perform the syncing manually. This is a good option for forms based authentication. The role it plays is to makes sure the identity of the user is re-hydrated so that their role claims are successful.
Should the requesting server be running any of the standard Windows authentication programs, the incoming security token contains the UPN of the user. It can also contain other attributes including:
When a requesting server is running SharePoint 2013, then the user is able to authenticate with the use of the following claims based authentication methods:
- Windows Claims Authentication SharePoint 2013 will use AD DS to find the user profile that represents a given user. This can include UPN or SID values.
- Forms Based Authentication SharePoint 2013 will use AD DS in a database to find the user profile that represents a given user in SQL or LDAP data. This can include UPN or SID values.
- SAML Based Claims Authentication The user identity claim needs to be mapped to the Account Attribute in user profiles. The UPN claim should be mapped to the UPN attribute and the SMTP claim to the SMTP attribute. If the incoming security token has custom claims, it is necessary to create a custom claim provider. This allows those attributes to be imported and for the user’s identity to be re-hydrated for server-to-server authentication.