Strategize Server To Server Authentication In SharePoint 2013

Server-to-server authentication involves:

  1. Identifying the set of trust relationships that have to be configured on a server running SharePoint 2013.
  2. 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:

  1. It trusts requests from a server that is able to perform server-to-server authentication incoming from the server that runs SharePoint 2013.
  2. The configuration on the server running SharePoint 2013 allows it to trust the authentication of the requesting server.
  3. 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. 
  4. 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.

Should the farm be able to perform server-to-server authentication on premises, it has to be configured to run SharePoint 2013 Preview. You can add JavaScript Object Notation (JSON) metadata to the endpoint on the server to do so. This can be done through the Get-SP Trusted Service Token Issuer Windows PowerShell cmdlet. 

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:

  1. Windows Security Identifier (SID)
  2. Active Directory Domain Services (AD DS)
  3. User Principle Name (UPN)
  4. Simple Mail Transfer Protocol (SMTP)
  5. 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:

  1. 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.
  2. 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:

  1. SMTP
  2. SIP
  3. SID

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:

  1. 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.
  2. 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.
  3. 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.
Share

Server to Server Authentication In SharePoint 2013

The process of server-to-server authentication involves the validation of the request a server gets for resources. It is based on a trust relationship that is between the STS of the server that runs SharePoint 2013 and the STS of another sever that supports the OAuth server to server protocol. This is a trust relationship so a requesting sever can access the resources that are secured on the SharePoint sever. This is done on behalf of a specific user account. It is also subject to the permissions of a given sever and a given user.

For example, this occurs when a server running Exchange Server 2013 is able to request resources of a server that is running SharePoint 2013 for a specific user account. This is in contrast with app authentication which involves the app not having access to the user account credential information. The user can be signed into the server, making the resource request but it isn’t a requirement. It depends on the specific service and the request being made.

When a server is running SharePoint 2013, there is an attempt to access a resource on a server. The incoming access request has to be authenticated in order for the server to accept the incoming access request and data. With server-to-server authentication, there is verification that the server running SharePoint 2013 and the user that is accessing it in the representation are both trusted.

The token that is used for any server-to-server authentication is a server-to-server token rather than a logon token. This server-to-sever token has information about the server that requests access. It also has information about the user account that the server is acting on the behalf of. With on premises servers, this is an example of how that basic process will occur:

  1. A user opens a SharePoint web page that requires information from another server.
  2. SharePoint 2013 generates a server-to-server token.
  3. SharePoint 2013 sends the server-to-server token to the new sever.
  4. The other server has to validate the server-to-server token from SharePoint.
  5. The other server has to send a message to SharePoint 2013. This message indicates that the server-to-server token was valid.
  6. The service on the server running SharePoint 2013 accesses the data on the server.
  7. The service on the server running SharePoint 2013 renders the page for the user.

If both servers are running Office 365, this is an example of how that process will occur:

  1. The user opens a SharePoint web page that requires information from another server.
  2. SharePoint Online requests and obtains a server to server token from ACS.
  3. SharePoint Online sends the server to server token to the server for Office 365.
  4. The server for Office 365 verifies that the identity of the user is correct based on the ACS server to server token.
  5. The server for Office 365 sends a message to SharePoint Online to state that the token sent through server-to-server has been validated.
  6. SharePoint Online accesses the data from the server for Office 365.
  7. SharePoint Online renders the page for the user to access.
Share