The last piece of the puzzle is telling SharePoint about our claim provider (The Access Control Service), and the format that the users’ claims token will come through as. We can get this in through powershell, and adding a new SPTrustedIdentityTokenIssuer object. Firstly, we need to get the certificate used by the ACS.
The certificate can be retrieved rather simply. In the ACS:
- Go to Application Integration, and copy out the url shown for the WS-Federation Metadata. This typically in the format of ‘https://<ACSNamespace>.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml’. For my instance, that comes out to ‘https://jackross-acs.accesscontrol.windows.net/FederationMetadata/2007-06/FederationMetadata.xml’
- Copy the value into the browser. This will display the federation metadata xml
- In the xml, you’ll see some nested nodes, in this order:
<RoleDescriptor xmlns:fed="http://docs.oasis-open.org/wsfed/federation/200706" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" protocolSupportEnumeration="http://docs.oasis-open.org/wsfed/federation/200706" xsi:type="fed:SecurityTokenServiceType"> <KeyDescriptor use="signing"> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <X509Data> <X509Certificate>MIIDGj...</X509Certificate> ...
- The contents of the X509Certificate node are what we’re after. Copy this out, paste into notepad, and save as a certificate. Such as ‘ACSCert.cer’
- Copy the certificate up to a SharePoint server in your system, and open up a SharePoint powershell session. First up, save the path of the certificate into a variable, such as:
$certPath = "C:\ConfigFiles\ACSCert.cer"
- Using this, we’re ready to create our new token issuer in powershell. Running the following cmdlet adds the certificate to the servers in the SharePoint farm:
#Get the certificate $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certPath) #Create the new trusted root authority using the certificate New-SPTrustedRootAuthority -Name "JackRoss-ACS - SharePoint Token Signing Certificate" -Certificate $cert
- Next, create a claims mapping object. This tells SharePoint the format of the incoming claims types. In my system, using UPN with only a few users and no duplicated tenants, I can just set this as follows:
$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN Claim Mapping" -SameAsIncoming
- Next, set the realm and create the Token Issuer. The value for $realm must be the same as the realm value defined in the ACS’ relying party application.
$realm = "http://sharepoint.azure.codesmegoats.com:80" New-SPTrustedIdentityTokenIssuer -Name "Jack Ross - AzureAD" -Description "Jack Ross AAD Via ACS" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl "https://jackross-acs.accesscontrol.windows.net/v2/wsfederation" -IdentifierClaim " http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
Now when I create a new web application in my SharePoint system, I’ll be able to select ‘Jack Ross – AzureAD’ as an Identity Provider, and use my Azure AD tenant users in SharePoint. There are some niggling issues here – You’ll see that trying to resolve any user in a People Picker field will always succeed for the AAD tenant. For this, you’ll need to implement some extra steps to query AAD and validate users.