Server-to-Server Trust Architecture in SharePoint 2013
The new S2S authentication architecture, as shown in the image below, enables your organization’s infrastructure to share resources between various servers in your SharePoint farm. The S2S Trust also provides for access services to other servers such as those that support your Exchange Server 2013 or Lync Server 2013 platforms.
The S2S authentication protocol does not just support those servers that run your organization’s other major “Microsoft application stack” technologies; SharePoint 2013 supports resource sharing and accesses any server within your organization that is compliant with the S2S protocol.
An S2S Trust consists of the following:
- Trusted connection between app and SharePoint
- OAuth and Access Control Services for on-premises farms
- Trust between servers configured using SSL certificates
- App code that contains the required access to a private key of an SSL certificate
- Creation of a security token service on SharePoint servers
EPC Group Tip – Azure Access Control Service
Azure Access Control Service, which is also referred to as Access Control Service, or ACS, is a Microsoft Azure service that provides an easy way for you to authenticate users to access your web applications and services without having to add complex authentication logic to your code.
The following features are available in ACS:
- Integration with Windows Identity Foundation (WIF)
- Support for Active Directory Federation Services (ADFS) 2.0
- An OData-based management service that provides programmatic access to ACS settings
- Support for popular web identity providers (IPs) including Microsoft accounts (formerly known as Windows Live ID), Google, Yahoo, and Facebook
- A Management Portal that allows administrative access to the ACS settings
There are nine overall key steps you must take in the configuration of an S2S trust:
- Create an x509 certificate.
- Make the certificate’s public key accessible to SharePoint.
- Utilize Windows PowerShell to create a trusted security token issuer based on public key.
- Develop a provider-hosted app that has access to the private key file.
- Create S2S access tokens with the help of the TokenHelper class.
- Pass access token by calling into SharePoint using the CSOM or REST API.
- Select one of the two available methods to make a certificate available.
- Pass the file path of the certificate to SharePoint.
- Expose the certificate from the app as a metadata endpoint.
Key Points to Remember – EPC Group Tips from the Trenches
The underlying architecture of an S2S trust contains the following elements and configurations:
To utilize this type of service, you need to generate the set of public and private keys and an X.509 certificate that contains the public/private key pair.
- The private key is used to sign certain aspects in the access token.
- A public key is registered with the SharePoint farm.
- The public key creates a trusted security token issuer.
- The app creates an access token to call into SharePoint
- The app creates an access token with a specific client ID and signs it with a private key.
- A trusted security token issuer validates the signature.
- SharePoint establishes the app identity.
- The app identity maps to a specific client ID.
- Multiple client IDs can be associated with a single x.509 certificate.
EPC Group’s Nationally Recognized Practice Areas
EPC Group leading Custom Application Development, SharePoint, Office 365, Infrastructure Design and Business Intelligence Practice areas continue to lead the way in providing our clients with the most up-to-date and relevant information that is tailored to their individual business and functional needs.
Additional “From the Consulting Trenches” strategies and methodologies are covered in EPC Group’s new book, “SharePoint 2013 Field Guide: Advice from the Consulting Trenches” covering not only SharePoint 2013, Office 365 and SharePoint Online but Information Management, ECM\RM and overall compliance strategies in this ever changing world of “Hybrid IT.”