Live from SPC12-Deep dive on server-to-server OAuth identity platform

Written by Yves

November 15, 2012

Speaker : Sesha Mani

SharePoint 2013 Server-to-Server (S2S) Out-of-the-box implemented scenarios : SP to Exchange, SP to SP and SP to MTW (Multi-tenant workflow service). OAuth is a standard that enables an application to access user’s resources without prompting for user’s credentials. S2S is a kind of an extension of OAuth 2.0 to allow an application to be high trust between applications. Application Principal is like the user’s principal (user identity), but for applications.

S2S implementation in O365

All S2S applications must exist in MSO-DS (kind of application directory). ACS plays the role of trust broker. When someone connects to SP Online, SP Online makes a call to the ACS to authenticate itself (with a certificate exchange) and asks to talk to Exchange Online and tries to get a token. ACS validates the SP Online token and checks the requested endpoint before issuing a STS token. SP Online augments the user identity information before sending the STS token (composed by the inner token – the basic ACS token, and the outer token – containing the added user’s claims). Exchange Online validates the STS token ensuring it has been issued by the ACS. It also validates that inner-token endpoint is the same as the outer-token endpoint. Then, it ensures that the user has the necessary permissions. Basically, the Application Identity is the inner-token, while the User Identity is the outer-token. Finally, Exchange Online returns the resources to SP Online.

This scenario is also valid for on-premises.

S2S authentication – On-Premise Only

SP hosts the App Management Service, the STS and the User Profile App (UPA) Service. Exchange hosts as well an STS OM. Making a trust between the two STS can simply be done using a PowerShell command (New-SPTrustedSecurityTokenIssuer and New-PartnerApplication). A user connects on SP and wants to do some activity on both SP and Exchange. SP STS issues an STS token containing the outer and inner token. That STS token is sent to Exchange, which checks this token if it accepts delegation. Also, endpoints check is done between the inner and outer tokens information. Exchange checks the user’s permissions before returning the resources to SP. The configuration steps are : STS trust establishment using the PS cmdlets), Permissions for principal and scenario specific settings.

Hybrid Solution

In the Cloud, MSO-DS synchronizes with the ACS and SP Online trusts the ACS which plays the role of the trust broker. On-Prem, same setup as in the previous scenario. In addition, SP STS synchronizes with the SP Online STS. Also, AD synchronizes with MSO-DS. A user makes a query in SP Online through On-Prem SP. SP issues a STS token to connect to SP Online. Request is sent to ACS for validation. Then SP sends the augmented-token to SP Online STS (containing the e-mail address – SMTP – and the UPN). SP Online accepts the token and returns the resources back to On-Prem SP.

S2S not supported topologies

Cross-premise or cross product S2S calls (SP calling Exchange Online), Cross-tenant scenario (Contoso to Fabrikam), S2S call between SP without AD to Exchange or Lync On-Prem, Web apps using Windows-Classic authentication.

You May Also Like…

0 Comments

Submit a Comment

Your email address will not be published. Required fields are marked *