The Widen Collective supports the service provider-initiated single sign-on (SSO). When authentication is necessary, the Collective 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 Collective.


Part 1: Adding the Collective as a relying party

To add the Collective 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 (host name or URL), enter https://{client}.widencollective.com/saml2/metadata.


Note: {client} should be replaced with your Widen deployment 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: Configuring claim rules

ADFS claim rules control which user attributes are returned to the Collective. 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: 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.



c:[type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" ]
=> add(
store = "_OpaqueIdStore",
types = ("http://www.widen.com/saml2/claims/persistentId"),
query = "{0};{1};{2}",
param = "ppid",
param = c.Value,
param = c.OriginalIssuer);

 

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 Collective. The GUID is used to associate the Windows user with the Collective account. An example of the GUID is “FphnvXza1nkx//y32E++HZs8Z2HZgxot07i1aJ6KYtI=”. 

 

The image below 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.


LDAP Attribute
Outgoing Claim Type 
Email Address
Email Address
Given Name
Given Name
Surname
Surname
Company
 http://www.widen.com/saml2/claims/company


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 Collective performs the following actions:

  1. ADFS role names are compared to Collective role names. ADFS roles names that match are considered valid and are used for further processing.
  2. If there are zero valid roles, your Collective 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 Collective 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 Widen 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 Widen.