Tuesday 21 April 2015

Setting Up an oAuth Trust Between Farms in SharePoint 2013



Setting Up an oAuth Trust Between Farms in SharePoint 2013

 

One of the things you’re likely to hear a lot about in SharePoint 2013, and I may end up writing a lot about, is oAuth.  In SharePoint 2013 oAuth is used to establish a trust between two applications for purposes of establishing the identity of a principal (user or application).  In SharePoint you will use oAuth trusts between SharePoint and things like Exchange and Lync, with ACS or individual application developers who are using the new cloud app model, or even between two different SharePoint farms for things like the remote SharePoint index feature in Search. 
What oAuth does NOT do is become an authentication provider for people; you still will use your New-SPTrustedIdentityTokenIssuer to create those trusts to your identity providers.  For oAuth trusts we have a new cmdlet that is very similar in name, and it’s called the New-SPTrustedSecurityTokenIssuer.   When we establish this kind of trust with a security token issuer we call it an S2S trust, which means “server to server”.  Remember this acronym because you will start seeing it a lot in SharePoint 2013.  In this post I’m going to talk through some of the particulars required to create this trust. 
First it’s worth pointing out that many features that require an S2S trust will establish this trust themselves.  They may do that via feature activation, or feature teams may provide you a PowerShell script or cmdlet to run that creates the trust as part of turning on their feature.  There will be times when you need to do it yourself though, and that’s what this post is about.  
One of the things you’ll need to resolve first is whether you are going to be using SSL or not.  The reality is, that in most cases in SharePoint 2013, you should probably use SSL.  The reason I say that is because there are so many scenarios that use oAuth in SharePoint 2013, and when you do you are passing around a cookie with an access token.  That access token is like a key that unlocks the door to data.  The access token is signed by a certificate so it can’t be spoofed by someone that creates their own access token, but you don’t want it flying around in clear text because in theory someone could grab that cookie and replay it for the duration of the cookie lifetime.  SSL protects you from that cookie replay attack, the same way that you would use SSL with a forms based auth site for the same reason.  That being said, there are still reasons why you may want to run your sites over HTTP – you’re in a test environment, you’re building out a dev environment, you’re running entirely on an internal network and don’t feel it’s a risk, etc.  I’m not here to judge – I’m just here to explain.  


 STEP 1:  Configure the STS
There are a couple of settings in the configuration of SharePoint’s security token service (STS) that you may want to tweak if you are not using SSL.  You can get all of the STS configuration settings with this cmdlet:  Get-SPSecurityTokenServiceConfig.   There are two ways to establish a trust – one is with a certificate and one is using a new oAuth metadata endpoint that all SharePoint farms have.  Using the metadata endpoint is the easiest way to go, but if that endpoint is not SSL secured then you need to set the AllowMetadataOverHttp property of the SharePoint STS to true.  If you are not going to be running your web apps over SSL, then you will need to set the AllowOAuthOverHttp property to true as well.  Here’s a little PowerShell that demonstrates how to set these properties: 
$c = Get-SPSecurityTokenServiceConfig
$c.AllowMetadataOverHttp = $true
$c.AllowOAuthOverHttp= $true
$c.Update() 

STEP 2:  Create the Trust

Once the STS is configured as required, we can look at how to establish the trust from one farm to another.  As I mentioned above, all SharePoint farms have a metadata endpoint now that is used to supply information and the access token signing certificate.  That metadata endpoint is at /_layouts/15/metadata/json/1.   If you actually try to navigate to that in a browser you will be prompted to save it, which you can do to examine it.  What you will find if you open it up in notepad is that it is just a JSON payload.  It includes the name identifier for the STS (which it calls “issuer”), along with a serialized version of the token signing certificate (which it describes as the “value” for the key “x509certificate”).  If you look a little further at the data, you’ll see that the issuer is actually servicename + “@” + realm values.  It also matches the NameIdentifier property on the STS; this information is important, for reasons I will explain in a bit. 
In this example let’s say that FARM_B needs to trust calls from FARM_A, because FARM_A is going to use FARM_B as a remote SharePoint index.  Also, let’s say that FARM_A has a web application at http://FARM_A.   To create the trust we would run the New-SPTrustedSecurityTokenIssuer cmdlet on a server in FARM_B like this (I’ll explain why I’m using the “$i = “ stuff later in the post): 
$i = New-SPTrustedSecurityTokenIssuer -Name FARM_A -Description “FARM_A description” -IsTrustBroker:$false -MetadataEndPoint “http://FARM_A/_layouts/15/metadata/json/1″ 
Now, let’s say that you are setting up a trust with a services only farm.  You don’t want to create a web application, site collection and SSL certificate just so you can create a trust from it.  So, we have a second method that you can use to establish the trust using the New-SPTrustedSecurityTokenIssuer cmdlet.  In the second form you can just provide the token signing certificate and the name identifier.  You get the token signing certificate just like you did in SharePoint 2010 – go to a server in the farm, run the MMC, add the Certificates snap-in for the Local Computer, look in the SharePoint…Certificates node, and the first certificate in the list is the one you want – just save it to the local drive without the private key as a .cer file.  You need the certificate and the NameIdentifier attribute of the STS that I was describing above in order to establish the trust.  The cmdlet in that case looks like this (it assumes you have copied the STS certificate to a file called C:\sts.cer on a server in FARM_B):
 $i = New-SPTrustedSecurityTokenIssuer -name FARM_A -Certificate “C:\sts.cer” -RegisteredIssuerName “00000003-0000-0ff1-ce00-000000000000@72da1552-085a-49de-9ecb-73ba7eca8fef ” -Description “FARM_A description” -IsTrustBroker:$false 

STEP 3:  Trust the Token Signing Certificate

Just like you do with a SPTrustedIdentityTokenIssuer, you need add the trust used to sign oAuth tokens to the list of trusted root authorities in SharePoint.  Again, you have two options for doing this:  if you create your trust via the metadata endpoint, you can establish the trust like this: 
New-SPTrustedRootAuthority -Name FARM_A -MetadataEndPoint http://FARM_A/_layouts/15/metadata/json/1/rootcertificate 
Otherwise, you can create add it to the trusted root authority list just like you did in SharePoint 2010: 
$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\sts.cer”)
New-SPTrustedRootAuthority -Name “Token Signing Root CA Certificate” -Certificate $root
 From a trust perspective, you’re done at this point – you’re trust is established and you can now create new application principals based on it.  How you’ll use it is based on the application itself; in the case of a remote SharePoint index I’ll go ahead and finish out the scenario now for completeness. 

STEP 4:  Creating an App Principal (example only for remote SharePoint index):

There are two steps in this process – getting an app principal and granting it rights.  Remember from our scenario that FARM_B needs to trust calls from FARM_A because it is going to get queries for the remote SharePoint index.  So for my app principal I need to get a reference to the web app in FARM_B that FARM_A is going to use.  Once I have that reference then I can grant rights for FARM_A to use it.
To get a reference to an app principal you use the cmdlet like this:
$p = Get-SPAppPrincipal -Site http://FARM_B -NameIdentifier $i.NameId
IMPORTANT:  There is one important thing to note here, that I think will be especially common especially during the SharePoint 2013 beta.  You may get strange errors in PowerShell when you try and get the SPAppPrincipal.  What I’ve found is that if your available memory on your server drops below 5% then all WCF calls will fail.  Since this PowerShell cmdlet calls into a service application endpoint, which is hosted as a WCF, the Get-SPAppPrincipal cmdlet fails when you are low on memory.  You can check in the Windows Event Viewer in the Application Log to see whether this is the cause of your problem.  This has happened to me multiple times so far so chances are others will see it as well.
Note that as I described earlier in the post, I finally get to use my $i variable to grab the NameIdentifier of the STS in FARM_A.  Now that I have a reference to the app principal for the FARM_B web app, I can grant it rights like so:
Set-SPAppPrincipalPermission -Site http://FARM_B -AppPrincipal $p -Scope SiteSubscription -Right FullControl
There you have it – those are your options and methodologies for creating an oAuth trust between two SharePoint farms.  I’ll continue to dig into oAuth and the various uses and issues to be aware of over time on this blog.
UPDATE:  There are other steps you need to do to get complete set of results back from all content sources when using Remote SharePoint Index; for more details see http://blogs.technet.com/b/speschka/archive/2013/01/24/getting-a-full-result-set-from-a-remote-sharepoint-index-in-sharepoint-2013.aspx.


Ref:
https://samlman.wordpress.com/2015/03/01/setting-up-an-oauth-trust-between-farms-in-sharepoint-2013/

Configure trust for search between two SharePoint Server 2013 farms

SharePoint 2013
2 out of 2 rated this helpful - Rate this topic
  Applies to: SharePoint Server 2013
Topic Last Modified: 2014-07-16
Summary:Configure a SharePoint Server 2013 content farm that receives search queries to trust the SharePoint Server 2013 farm that sends the queries.
To configure an on-premises SharePoint Server 2013 content farm to return results from its search index to a separate on-premises SharePoint Server 2013 farm, you must perform the following two main procedures:
  1. In the farm that will receive the search queries, configure trust of the farm that will send the queries by doing the following:
    • Configure a server-to-server trust relationship by using the Open Authorization 2.0 (OAuth 2.0) web authorization protocol.
    • Enable the farm that receives the queries to return search results from all of its web applications that host content.
  2. In the farm that will send the search queries, create a result source that does each of the following:
    • Specifies Remote SharePoint as the protocol.
    • Specifies the address of any root site collection in the SharePoint farm that will receive the search queries.
    For more information, see Configure result sources for search in SharePoint Server 2013.
    NoteNote:
    After you create the result source, you expose the search results that it provides by using it in a Web Part or a query-rule action. In this way, users of the farm that is sending search queries can see results from the farm that is receiving the queries. For more information, see Understanding result sources for search in SharePoint Server 2013.
This article describes how to perform the first procedure in the list above: how to configure the farm that receives search queries to trust the farm that sends the queries.
For brevity in this article, the following terms are used:

 

SendingFarm
An on-premises SharePoint Server 2013 farm that has a search service that sends search queries to ReceivingFarm.
ReceivingFarm
An on-premises SharePoint Server 2013 content farm that has a search index that receives search queries from SendingFarm. In this article, it is assumed that ReceivingFarm has at least one web application that hosts content.
In order for SendingFarm to be able to get search results from the search index in ReceivingFarm, the farms must have the following characteristics:
NoteNote:
Because SharePoint 2013 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint 2013 supports the accessibility features of supported browsers. For more information, see the following resources:

To configure ReceivingFarm to trust SendingFarm
  1. Verify that the account that performs this procedure is a member of the following groups:
    • Farm Administrators group in ReceivingFarm.
    • Administrators group on the server on which you are running Windows PowerShell cmdlets.
      An administrator of that server can use the Add-SPShellAdmin cmdlet to grant someone permission to use SharePoint 2013 cmdlets. When you run the Add-SPShellAdmin cmdlet, you must have membership in the securityadmin fixed server role on the SQL Server instances, and you must have membership in the db_owner fixed database role on all databases that are to be updated. For more information, see Add-SPShellAdmin. Contact your system administrator or SQL Server administrator to request these memberships if you do not have them.
  2. On a server in ReceivingFarm, start the SharePoint 2013 Management Shell.
    • For Windows Server 2008 R2:
      In the SharePoint 2013 environment, on the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
    • For Windows Server 2012:
      • In the SharePoint 2013 environment, on the Start page, click SharePoint 2013 Management Shell.
      • If SharePoint 2013 Management Shell is not on the Start page, right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.
      For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.
  3. On a server in ReceivingFarm, run the following commands at a Windows PowerShell command prompt. The commands use the OAuth 2.0 web authorization protocol to configure a server-to-server trust, so that ReceivingFarm will trust SendingFarm.
    # Create a trusted security token issuer
$i = New-SPTrustedSecurityTokenIssuer -Name "SendingFarm" -IsTrustBroker:$false -MetadataEndpoint "https://<SendingFarm_web_application>/_layouts/15/metadata/json/1"
# Configure trust of the token-signing certificate'
# by adding the trust used to sign oAuth tokens'
# to the list of trusted root authorities'
# in ReceivingFarm
New-SPTrustedRootAuthority -Name "SendingFarm" -MetadataEndPoint https://<SendingFarm_web_application>/_layouts/15/metadata/json/1/rootcertificate
    Where:
    https://<SendingFarm_web_application> is any SSL-enabled web application in SendingFarm
    ImportantImportant:
    Web applications that include server-to-server authentication endpoints for incoming server-to-server requests, or that make outgoing server-to-server requests, should be configured to use Secure Sockets Layer (SSL). For information about how to configure a web application to use SSL, see Create claims-based web applications in SharePoint 2013. For information about how to configure HTTP support for server-to-server requests, see Configure an STS for HTTP in Configure server-to-server authentication in SharePoint 2013.
  4. On a server in ReceivingFarm, at a Windows PowerShell command prompt, run the following command:
    # Use $realm to store the string'
# that comes after the "@" character'
# in the value of $i.NameId
$realm = $i.NameId.Split("@")
  5. On a server in ReceivingFarm, at a Windows PowerShell command prompt, run the following commands to enable all web applications in ReceivingFarm to return search results to SendingFarm:
    $s1 = Get-SPSite -Identity https://<ReceivingFarm_web_application>
$sc1 = Get-SPServiceContext -Site $s1
# Set up an authentication realm for'
# a web application that hosts content in ReceivingFarm 
Set-SPAuthenticationRealm -ServiceContext $sc1 -Realm $realm[1]
# Get a reference to the application principal'
# for that web application in Farm B
$p = Get-SPAppPrincipal -Site https://<ReceivingFarm_web_application> -NameIdentifier $i.NameId
# Grant rights to the application principal'
# that SendingFarm will use'
# when it sends queries to ReceivingFarm
Set-SPAppPrincipalPermission -Site https://<ReceivingFarm_web_application> -AppPrincipal $p -Scope SiteCollection -Right FullControl
    Where:
    https://<ReceivingFarm_web_application> is an SSL-enabled web application in ReceivingFarm.
  6. Repeat the previous step (step 5) for each web application in ReceivingFarm that hosts content that you want to search.
    ref: https://technet.microsoft.com/en-us/library/dn133749.aspx
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)