Configuring a Relying Party in ADFS
We have now installed and configured ADFS,
and we are ready to create a Relying Party. We established in the
beginning of this article that a Relying Party is a system or
application that permits authenticated user access, but relies on an
Issuing Authority (via Secure Token Service) to perform the actual
authentication. In this case, SharePoint is our Relying Party, ADFS is
our STS, and Active Directory is our Issuing Authority.
- Open the ADFS 2.0 Management Console and click the link to create trusted relying party.
- A wizard starts and shows a welcome message; after reading the dialog, click the Start button.
- ADFS next asks for our data source, from which we can import
configuration from a network resource or file, or configure manually (Figure 21).
- For our SharePoint Relying Party, choose the manual option and click the Next button.
- Enter a display name for the Relying Party and description (optional) on the next dialog.
- ADFS supports legacy 1.0, 1.1, and the new 2.0 profile formats. We need the 2.0 format, which supports SAML via STS (Figure 22).
- The next dialog gives you the option to encrypt SAML tokens with
selected certificate, which we would normally do, but since SharePoint
requires an SSL address to communicate with the ADFS STS, this is
unnecessary, so click the Next button.
- ADFS requires us to configure a URL for WS-Federation at the Relying Party (Figure 23)—this
is the URL with which ADFS will return SAML tokens. At this point, we
can also configure Web SSO for SAML Single-Sign-On, but this is outside
scope of these instructions.
- In the dialog shown in Figure 23, check the Passive option,
and provide an SSL-based URL for your SharePoint site. SharePoint 2013
includes a special URL end point for acceptance of SAML tokens: https://domain-name/_trust/.
Note Before
configuring SharePoint as a Relying Party, remember to set up SSL for
the site—ADFS requires a secure connection to pass back SAML tokens.
- In the next dialog (Figure 24), add an additional identifier for the realm—the
realm is the identifier that SharePoint will pass to ADFS to identify
itself as the Relying Party. Typically, the realm is in the format urn:domain:server
.
- Click the Next button, and then check the Radio button to permit
all users to access the Relying Party, followed by the Next button.
- Click the Next button on the summary dialog to finish creation of Relying Party configuration.
- The last dialog (Figure 25)
should show a successful message and include a check box to add claims
rules, which we shall do next, after clicking the Close button.
- A dialog should appear to add claims rules.
- Click the Add Rule button.
- In the dialog that appears (Figure 26),
select the option to send LDAP attributes as claims. Our Issuing
Authority—Active Directory—provides user profile attributes via LDAP.
- Give the rule name.
- Select Active Directory as the attribute store.
- Map E-Mail-Addresses to the E-Mail Address claim.
- Map Token Groups (unqualified names) to the Role claim.
- Map the User-Principal-Name to the UPN claim.
Note Ensure that you populate the e-mail address in Active Directory user properties for the user.
- Click the Finish button on the dialog (Figure 27).
- Click the Add Rule button.
- Select the option Pass Through or Filter an Incoming Claim.
- Click the Next button.
- Enter the name “Primary SID” and select the type as Primary SID.
- Click the OK button on the rules dialog.
We have now successfully configured SharePoint
2013 as our Relying Party in ADFS. You may have
configured your SharePoint 2013 web application for HTTPS requests; if
not, you must enable SSL for your application, since ADFS expects all
relying parties to communicate on secure transport channels. Flip back
to the section “Configuring SSL for SharePoint” to find out how to
enable SSL for your SharePoint web application.
The final part of our configuration for ADFS
Authentication Federation involves configuration of SharePoint 2013
with a trusted provider to use ADFS. First, we need to export the
signing certificate from ADFS and add it to SharePoint as a trusted
certificate.
- Open the ADFS Management Console.
- Expand the Service node and click Certificates (Figure 28).
- Right-click the Token-signing certificate and click View Certificate in the pop-up menu.
- You should see a dialog showing the certificate, like that in Figure 29.
- Click the Details tab, then click the Copy to file button.
- Click the Next button.
- Select the option to not export the private key, then click the Next button.
- Choose the export format (I chose the default DER format) and then click the Next button.
- Give the certificate a file name and browse to a location on disk.
- Click the Next button, then the Finish button to export the certificate to the file.
- Open the Microsoft Management Console (MMC.exe) on the SharePoint server.
- Add the Certificates snap-in for the computer account and local machine.
- Import the certificate into the Trusted Root Certificate Authorities node.
- Import the certificate into the SharePoint node.
After exporting the token-signing certificate, we shall now import the certificate into SharePoint, using a PowerShell script:
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("c:\ADFS.cer ")
New-SPTrustedRootAuthority -Name "ADFS Token Signing Cert" -Certificate $cert
Note The above script requires the full path to the certificate file.
The final set of steps consists of running some PowerShell scripts to create a new Trusted Provider entry and allow SharePoint to federate with ADFS for authentication. First, we map the ADFS claims to those in SharePoint.
$map = New-SPClaimTypeMapping -IncomingClaimType "
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$map2 = New-SPClaimTypeMapping -IncomingClaimType "
http://schemas.microsoft.com/ws/2008/06/identity/claims/role
" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming
Finally, the following script creates the
trusted provider. Do not forget to include the same realm as that of
the Relying Party configuration in ADFS.
$realm = "urn:robdev:sp2013"
$signin = " https://sts.robdev.local/adfs/ls "
$ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS SAML Provider" -Description "SharePoint
secured by ADFS SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -
SignInUrl $signin -IdentifierClaim " http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress "
The above commands include the claims mappings;
realm; name and description of the provider; and HTTPS of the ADFS
server, which is typically of the format https://domain/adfs/ls. Notice that SharePoint trusted providers require a designated claim to identify users, in this case the e-mail address claim.
Now that we have configured the trusted provider in SharePoint, it is time to enable it on one of our applications, as follows:
- Open Central Administration.
- Click the Manage web applications link.
- Click the web application to add the trusted provider.
- Scroll down to the Claims Authentication Types section, and you should see the new provider (Figure 30).
- Check the check box to enable Trusted Identity Provider.
- Check the check box for the SAML identity provider we just installed.
- Click the Save button at the bottom of the dialog.
- Open the web application in a new browser window.
- If everything works properly, you see a page like that in Figure 31.
- Select the ADFS SAML provider.
