Part 2: Configure claim rules¶

ADFS claim rules control which user attributes are returned to the DAM. Instructions below are for a typical ADFS configuration. Use these instructions as a starting point if your company's ADFS deployment has been customized. Note that spelling and capitalization within many of the fields is significant.

 ¶

Choose Add Rule...¶

1. Choose Send Claims Using a Custom Rule.
2. In the text field for Claim rule name, enter Create Opaque Persistent User Id.
3. In the text field for Custom rule, enter the code block below.
4. Choose Finish.

 

Technical detail: The OpaqueIdStore takes three parameters: mode ("ppid") and two parameters that are used as a seed for generating a pseudo-random identifier. The result is also mixed with ADFS installation-specific secret entropy. This result is an identifier (GUID) unique to the Windows account and the DAM. The GUID is used to associate the Windows user with the DAM account. An example of the GUID is “FphnvXza1nkx//y32E++HZs8Z2HZgxot07i1aJ6KYtI=”.

This image shows the resulting rule.

 

Choose Add Rule...¶

1. Choose Transform an Incoming Claim.
2. In the text field for Claim rule name, enter Create Persistent Name Identifier.
3. In the text field for Incoming claim type, enter http://www.widen.com/saml2/claims/persistentId.
4. In the text field for Outgoing claim type, choose Name ID.
5. In the text field for Outgoing name ID format, choose Persistent Identifier.

 

The image below shows the resulting rule.

 

Choose Add Rule...¶

1. Choose Send LDAP Attributes as Claims.
2. In the text field for Claim rule name, enter LDAP Claims.
3. In the text field for Attribute store, choose Active Directory.
4. In the mapping area, enter the values from the following table.

 

 

The image below shows the resulting rule.

 

 

Send user roles via claims¶

We accept user authorization roles generated by ADFS. Names of roles should be given the outgoing claim type of role and should be a simple list of names. Each time a user is authenticated via ADFS, the DAM performs the following actions:

1. ADFS role names are compared to DAM role names. ADFS roles names that match are considered valid and are used for further processing.
2. If there are zero valid roles, your DAM role assignments are left as is. (A configuration point stops the login process if a minimum number of roles is not matched; it's defaulted to zero.)
3. If there are one or more valid roles, your DAM role assignments are updated to match the ADFS roles. This may involve removing and/or adding roles.

 

Part 3: ADFS URL¶

Supply a fully-qualified endpoint URL to Acquia for your ADFS server. The endpoint URL for ADFS is typically https://{sso.example.com}/adfs/ls/.
 

Part 4: Export token signing public key¶

The ADFS token signing key is used to verify that the SAML result XML originated from your server. Option 1 below is the preferred method.

 

Option 1 - Export federation metadata¶

Supply or grant access to ADFS metadata file located at https://{sso.example.com}/FederationMetadata/2007-06/FederationMetadata.xml.

 

Option 2 - Export from certificate wizard¶

To copy the ADFS signing public key to a file:

1. On the ADFS 2.0 computer, in the ADFS 2.0 console tree, click the Certificates folder.
2. In the center pane, right-click the certificate that is listed under Token-signing.
3. Click View Certificate.
4. In the Certificate window, click the Details tab.
5. Click Copy to File to start the Certificate Export Wizard.
6. On the Export File Format page, choose Base-64 encoded X.509 (.CER).
7. On the File to Export page, click Browse. Navigate to the Windows desktop, then type the filename adfssign (leaving the type as .cer).
8. Click Next.
9. Click Finish.
10. Click OK, then click OK again.
11. Supply the file to Acquia.