The Acquia DAM supports the service provider-initiated single sign-on (SSO). When authentication is necessary, the DAM will redirect your browser to your Active Directory Federation Services (ADFS) server. The ADFS server will authorize you and instruct your browser to post the authentication result back to the DAM.

Our implementation is tested against the Microsoft Windows ADFS product. Many other providers, including Novell and IBM, have SAML-compliant products.
 

Part 1: Add Acquia DAM as a relying party

To add the DAM as a relying party:

1. Open the ADFS control panel and start the Add Relying Party Trust wizard.
2. In the text field for Federation metadata address (hostname or URL), enter https://{client}.widencollective.com/saml2/metadata or https://{client}.acquiadam.com/saml2/metadata. Note that {client} should be replaced with your Acquia DAM name.
3. Enter a display name.
4. Choose Permit all users to access this relying party.
5. Finish the wizard, which will open in the Claim Rules window.

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.

How do I configure a SAML SSO for ADFS?

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.

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.