Server-to-Server authentication (S2S)
represents an example of application-to-application OAuth. This
approach uses a Microsoft extension of the OAuth protocol to enable
applications or servers to share resources on behalf of users, without
user authentication. This is achieved using a trusted connection
between applications. As you saw in the last example of the preceding
section, this type of configuration can be used when deploying a
developer-hosted app in a private network to avoid any dependencies on
ACS or any other servers running across the Internet. The S2S process
is essentially an access request and access granting process between
two S2S-compliant applications or servers. The criteria to share
resources between two compliant servers include the following:
- The application or server requesting the resources must be trusted.
- The application or server requesting the resources must have the proper permissions.
Do these criteria look familiar? They should, as
they are exactly the same criteria you saw previously for app
authentication. Just as SharePoint 2013 has a native STS for user
authentication, SharePoint 2013 also has another STS dedicated to
provide server-to-server security tokens. A trust established between
the SharePoint 2013 STS and any other S2S-compliant server or services
enables the sharing of resources. For on-premises deployments, the key
step that configures the trust relationship involves establishing the
JavaScript Object Notation (JSON) meta data endpoint of the other
S2S-compliant service. This is accomplished using the New-SPTrustedSecurityTokenIssuer cmdlet.
S2S-compliant servers include SharePoint Server
2013, Exchange Server 2013, Lync Server 2013, Azure Workflow Server, or
any other software that supports the Microsoft server-to-server
protocol. Server-to-server authentication enables a new set of
functionality and scenarios, such as the new eDiscovery capability in
SharePoint 2013 and Exchange 2013. It also enables information from one
SharePoint 2013 farm to be retrieved and displayed from another
SharePoint 2013 farm.
SharePoint to SharePoint S2S
The SharePoint 2013 to SharePoint 2013
configuration is the simplest S2S scenario. It requires configuring a
one-way trust between the server receiving the requests and the server
that will be sending them. Detailed documentation about the
configuration is provided at http://technet.microsoft.com/en-us/library/jj655400.aspx, so here we will only show the key PowerShell command that makes it all possible, New-SPTrustedSecurityTokenIssuer:
New-SPTrustedSecurityTokenIssuer –MetadataEndpoint
"https://<HostName>/_layouts/15/metadata/json/1"
–IsTrustBroker –Name "<FriendlyName>"
The parameter <HostName> is the name and port of the SSL-enabled SharePoint web application of the farm that will be sending S2S requests, and the <FriendlyName>
parameter is a friendly name for the SharePoint 2013 farm that is
sending S2S requests. It is recommended that OAuth communication occur
over SSL, but it can be configured using PowerShell to use HTTP for lab
environments. Administrators responsible for configuring app
authentication and S2S will become very familiar with this PowerShell
cmdlet. Figure 1 shows the inter-server communication process, which is described in the following steps:
1. A user opens a SharePoint 2013 page that requires information from another SharePoint 2013 farm.
2. SharePoint Farm 1 generates a server-to-server token.
3. SharePoint Farm 1 sends the token to Server Farm 2.
4. Server Farm 2 validates the token from Server Farm 1.
5. Server Farm 2 replies to Server Farm 1 to confirm that the token is valid.
6. The components on the SharePoint page that need the information from Server Farm 2 access the data on Server Farm 2.
7. The page is rendered for the user.
SharePoint to Exchange and Lync S2S
The S2S process for sharing information
between SharePoint 2013 and Exchange 2013, and SharePoint 2013 and Lync
2013, is the same but the configuration is more involved. Table 1
contains references to TechNet articles that describe the configuration
process in detail, so we will not repeat that discussion here. The
configuration process details the steps required to establish two,
one-way trusts. These two, one-way trusts are necessary to support
SharePoint consuming information from Exchange and Lync, as well as
Exchange and Lync consuming information from SharePoint.
TABLE 1: Configuring S2S Between SharePoint 2013 and Another Server
SERVER |
REFERENCE |
Exchange 2013 |
http://technet.microsoft.com/en-us/library/jj655399.aspx
|
Lync 2013 |
http://technet.microsoft.com/en-us/library/jj670179.aspx
http://technet.microsoft.com/library/696f2b26-e5d0-42b5-9785-a26c2ce25bb7(Office.15).aspx
|
SharePoint 2013 |
http://technet.microsoft.com/en-us/library/jj655400.aspx
|
AWS is the new workflow capability for SharePoint
2013. Despite the name, AWS can be used on-premises, and it can be
hosted on a server that is part of the SharePoint 2013 farm or
separately. S2S is a great new addition to the claims authentication
capability of SharePoint, and it will provide new authentication
approaches for non-SharePoint applications.