Optional Usage: Combine SAML2 and LDAP

If you have configured LDAP (Active Directory) authentication, then your Chorus server can use this to discover groups and memberships, but still use SAML2 for single sign-on.

Check the box "Combine SAML2 and LDAP". Chorus will then use AD/LDAP to find users, groups and memberships (including nested group memberships), and direct users to your AD FS/SAML2 SSO to log in. When enabled, new user accounts will not be provisioned on demand for all SSO users. Instead, only those that relate to imported LDAP users can log in.

AD FS Configuration

1. Open AD FS Management from Administrative Tools. 

2. Right-click the top-level "AD FS" folder.

   

3. Select "Add Relying Party Trust…"

   

   
   

4. Click "Start".

   

   
   

5. If your AD FS server can directly access Chorus, then follow this step:

   1. Enter the Metadata URL for the IMS SP in the field labelled "Federation metadata address (host name or URL)".
      
      
      
      
   2. If you get a warning (screenshot below), you can ignore this by clicking "OK".
      
      
      
      
   3. If you get an error "AD FS could not create ssl/tls secure channel", this may indicate that your AD FS server does not support TLSv1.2. See the Microsoft documentation to enable this - at the time of writing, this can be found at https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs#enable-and-disable-tls-12

   
   

6. Only If your AD FS server cannot directly access your Chorus server (for example, because it does not have TLS 1.2 support, as explained above), then: Click "Next".

   1. You will need to download the SPMetadata from Chorus into a file and get this onto the AD FS server. For example:
      
      
      1. Open a new Powershell Window
         
         
         
         

      2. Run the following command (change the URL on the first line to the value of the SP Metadata URL on the SAML2 settings page in Chorus, and change the numbers '1382115659' to the Id specific for your installation).

         
         

         $imsMetadataUrl = "https://chorus.example.com/samlconsume.tlx/1382115659/module.php/saml/sp/metadata.php/samlauth" $saveRelativePath = "Desktop/ims-metadata.xml" (new-object System.Net.WebClient).DownloadFile($imsMetadataUrl, (Join-Path $pwd $saveRelativePath))

         
         
         

   2. Click the radio button to the left of "Import data about the relying party from a file".
      
      
      
      
   3. Click "Browse" (highlighted in red, above) and choose the location of Chorus SP Metadata file that you downloaded.

   
   

7. Click Next.

   
   

   
   

8. Enter a "Display name" (e.g. "chorus.example.com"; the name that Relying Party will appear in the AD FS management tool) and, optionally, add some "Notes". Click "Next".

   

   
   

9. Click "Next".

   
   

10. Click "Next".

    

    
    

11. Click "Next".

    
    

    
    

12. Ensure that "Open the Edit Claim Rules dialog for this relying party trust when the wizard closes" is checked. Then, click "Close".
    Note: You can also get to this by right-clicking on the Chorus Relying Party (e.g. chorus.example.com) and selecting "Edit Claim Rules…".

    
    

    
    

13. Click "Add Rule…"
    
    
    
    
14. Leave the "Claim rule template" as "Send LDAP Attributes as Claims" and click "Next".
    
    
    
    In the above screenshot, objectSid has been typed-in manually. The right-hand side of this form contains Microsoft's shorthand names for SAML claim URIs (see below, under point 15, for more details).
    
    
    
15. Complete the form, as follows:
    
    
    1. "Claim rule name": "LDAP"
    2. "Attribute store": select "Active Directory"

    3. "Mapping of LDAP attributes to outgoing claim types", as follows (note: the "Associated Claim Type URI" is configured in AD FS > Service > Claim Descriptions, and these should be provided by a default AD FS install).

       LDAP Attribute	Outgoing Claim Type	Associated Claim Type URI	Purpose in Chorus
       E-Mail-Addresses	E-Mail Address	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress	Email Address - also used to find users where the authentication type has changed to SAML2
       Display-Name	Name	http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name	Name - updated on login
       SAM-Account-Name	Common Name	http://schemas.xmlsoap.org/claims/CommonName	Username - only used at initial creation
       Token-Groups - Unqualified Names	Group	http://schemas.xmlsoap.org/claims/Group	Group mapping - a mapping of a group to a role in a Chorus Space, updated on login
       objectSid (*)	Primary SID	http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid	Generation of Name ID (see next rule) - used to identify bound users
       description (*)	Role	http://schemas.microsoft.com/ws/2008/06/identity/claims/role	Description - updated on login (Available from Chorus v1.5)

       NB: Items marked (*) do not appear in the default AD FS LDAP attribute dropdown, but may be entered manually as shown.
       
       

16. Click "Finish".
    
    
    
    
17. Click "Add Rule…" again.
    
    
18. Select "Transform an Incoming Claim" from the "Claim rule template".
    
    
    
    
19. Click "Next".
    
    
    
    
20. Enter the following details:
    
    
    1. "Claim rule name": "Name ID"
    2. "Incoming claim type": "Primary SID"
    3. "Outgoing claim type": "Name ID"
    4. "Outgoing name ID format": "Persistent Identifier"
       
       
21. Click "Finish".
    
    
    
    
22. Ensure that the order is "LDAP" and then "Name ID".
23. Click OK.

In the above, objectSid is used as the basis for generating a Name ID. You can use other fields - objectGuid being one suitable example. You should normally avoid using sAMAccountName / email / User Principal Name for this as they may change.

Testing the Configuration

Chorus and AD FS should now both be configured for Single-Sign-On. To quickly test:

1. Open up Chorus in your browser (e.g. https://chorus.example.com)

2. If you're logged in, then logout.

3. Click the "Single Sign-on" button.

You should automatically be authenticated via AD FS.

Re-syncing metadata following replacement of token-signing certificate

If you have replaced the token-signing certificate on your Chorus server, the existing metadata on Chorus will need to be refreshed to restore external authentication. Simply re-save your SAML2 configuration inside Chorus to do this.

You are here: