Hi,
This post is the third part of the serie of posts about ADFS, in the next few lines, will be covered the following things:
- Start the Security Token Service (STS)
- Import the Token-Signing Certificate
- Define a unique identifier for claims mapping
- Create the new authentication provider
- Start the Security Token Service (STS)
Depending on how you created your SharePoint 2013 farm, you may have to start the Security Token Service. This service is required in order for claims to work properly, and should be running in all SharePoint Servers in the farm.
To start the STS:
- Open the IIS Manager Console
- Expand the Application pools section beneath the server name.
- In the Application pools pane, select SecurityTokenServiceApplicationPool
- In the Actions pane, select the Start link
- Import the Token-Signing Certificate
To import the Token-Signing certificate do the following:
- Start a SharePoint 2013 Management Shell as an Administrator
- (Optional) If you have a root site in the certificate chain, you must import the parent certificate first before importing the singning certificate:
$parentcert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<path to the parent certificate>”)
New-SPTrustedRootAuthority -Name “Token Signing Cert Parent” -Certificate $parentcert
- Import the signing certificate provided to you by the ADFS administrator
$signcert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“<path to the signing certificate>”)
New-SPTrustedRootAuthority -Name “Token Signing Cert” -Certificate $signcert
- You can also check that the certificate has been correctly imported from central administration; within the Security section select the Manage Trust link and you will see the Trusted Root Authorities in which your farm trusts.
- Define a unique identifier for claims mapping
Next you have to define mappings for the e-mail and role claims, as follows:
- For the identity claim mapping (e-mail address), enter the following:
$identityClaimMapping = New-SPClaimTypeMapping -IncomingClaimType “http://schemas. xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” –SameAsIncoming
- For the Role claim mapping, enter the following
$roleClaimMapping = New-SPClaimTypeMapping -IncomingClaimType “http://schemas. microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” –SameAsIncoming
- Create the new authentication provider
Once the claims mappings are complete, we can build the authentication provider
- First we need to define the rusted STS for a SharePoint farm ($realm), specifying a name for your web application. This value must match the value you used as a Relying Party Identifier in your ADFS Server.
$realm = “urn:sharepoint:portalDemos”
- Next, you define a variable ($signInURL) with value the URL of the logon page for ADFS
$signInURL = https://smsp.demos.local/adfs/ls
- Finally, you create the new provider with the following cmdlet, using your own values for the –Name and –Description values.
$ap = New-SPTrustedIdentityTokenIssuer -Name ADFS -Description “Active Directory Federation Services” -realm $realm -ImportTrustCertificate $signcert -ClaimsMappings $identityClaimMapping, $roleClaimMapping -SignInUrl $signInURL -IdentifierClaim $identityClaimMapping.InputClaimType
- To validate the script ran successfully the “Get-SPTrustedTokenIssuer” cmdlet can be executed to verify the results. There are 5 key pieces of information to validate:
- ProviderUri (SharePoint will send authentication requests to this Uri)
- ProviderRealms (SharePoint will send the URN to ADFS which in turn will use the realm value to match it up with the appropriate relying party entry)
- ClaimTypeInfomation (This verifies the two claim mappings that we created during the script execution and should match up with what is configured in the ADFS relying party entry)
- Signing Certificate (Verify the “Token-Signing” certificate is listed here)
- Name (The name entry will be listed in the Web Application as an option under the “Trusted Authentication Providers”)