From the previous posts around creating claims-based web applications in SharePoint, it looks like creating additional claims-based web applications would be a matter of:
- Adding a new Relying Party (RP) in the Access Control Service (ACS)
- Creating a new SPTrustedIdentityTokenIssuer in powershell
- Adding this to a web application with the url defined in the ACS RP
This is both right – and wrong.
Using the steps outlined in previous posts, namely using the default certificate from the ACS namespace, will not allow this to happen. In SharePoint, each certificate can only be linked to one SPTrustedIdentityTokenIssuer. That’s a security decision, as each Identity Provider (IdP) in the ACS could be a separate tenant, and so each tenant really should be encrypted using separate certificates.
If, however, this is just for a quick test, or if the IdP’s are the same, this simple example will extend your SPTrustedIdentityTokenIssuer to get a second RP web application working in SharePoint:
- Create the new RP in the ACS using the steps from previous examples
- Run the following in the SharePoint farm in powershell:
#$id is the name or guid of the SPTrustedIdentityTokenIssuer being extended $ap = Get-SPTrustedIdentityTokenIssuer -Identity $id $uri = New-Object System.Uri $webAppUrl #Where $webAppUrl is the url for the new RP web application $ap.ProviderRealms.Add($uri, $webAppUrl) $ap.Update()
After setting up the new web application in SharePoint to use the token issuer, you’ll be able to successfully authenticate against the ACS.