D9.2.2 AD FS via SAML2 This guide assumes you have an AD FS deployment. This guide is based on Windows Server 2016. Third Light support staff cannot offer assistance with 3rd party tools, so while the following notes are provided for your convenience, they should not be relied upon without a full understanding of the AD FS technology. For details on how to configure AD FS, please see D9.2.1 Deploying AD FS. Step-by-step: Click Admin at the top of your desk and sign in to elevate. 2. Choose Settings > Site from the Admin menu. The Site Admin modal will open. 3. Go to SAML2 settings. 4. Use the Enable SAML2 switch to activate the functionality. Configuration options will appear. 5. Select your method for loading IdP Metadata. This can be loaded directly from the IdP (URL), or manually supplied in XML. Loading via a URL is preferred, as it can be kept up to date automatically. You can get the URL from your AD FS server. The Metadata URL is "https:// adfs.example.com/federationmetadata/2007-06/federationmetadata.xml", where adfs.example. com is the host of your AD FS server. Chorus will check the URL every 24 hours. If Chorus cannot access your AD FS server, Chorus will not automatically update the Metadata if you change your AD FS configuration. If you make any changes, then you may have to re-add the Metadata manually: Select the "Load IdP Metadata from XML" radio option. Paste the Metadata into the text field labelled "IdP Metadata XML" (see the info box at the top of this section). 6. Enter your IdP Metadata URL 7. If you are having problems configuring this URL, such as a message saying the XML is invalid, use the Test This URL button to see what data is being fetched by Chorus. 8. Use the Force Authentication switch to tell the IdP service to force users to re-authenticate when a sign in request is made. 9. View the SP Details to view the relying party details (SP Entity ID and SP Metadata URL). Note, you cannot edit these fields.
10. Click Save. After saving, the SP Entity ID and SP Metadata URL will be visible for the SP (e.g. https://chorus.example.com/samlconsume.tlx /1382115659/module.php/saml/sp/metadata.php/samlauth). Keep note of this as you will need it to configure the Relying Party in AD FS, below. 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. This mode combines the advantages of LDAP and SAML external authentication systems: using LDAP your users and groups can be located, pre-populated, and configured at set up time. Using SAML, your users' passwords are only ever handled by your existing central SSO system, can be signed in transparently, and use existing multi-factor policies. This mode can be enabled on top of an existing LDAP configuration without reconfiguring individual users (unlike transitioning from pure-ldap to pure SAML2). This feature requires that your SAML2 IdP be configured to provide either Object GUID (http://schemas.xmlsoap.org/ws/2005 /05/identity/claims/objectguid) or Primary SID (http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid) claims for users, matching the equivalent LDAP attribute. The equivalent LDAP attribute for Primary SID is objectsid. The equivalent LDAP attribute for Object GUID is objectguid. AD FS Configuration 2. Open AD FS Management from Administrative Tools. 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: 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 TLSv2. 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-disabletls-12 6. Only If your AD FS server cannot directly access your Chorus server (for example, because it does not have TLS 2 support, as explained above), then: Click "Next". You will need to download the SPMetadata from Chorus into a file and get this onto the AD FS server. For example: 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". 1 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: 2. 3. "Claim rule name": "LDAP" "Attribute store": select "Active Directory" "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 Description - 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 16. Click "Finish". 17. 18. Click "Add Rule " again. Select " Transform an Incoming Claim" from the "Claim rule template".
19. Click "Next". 20. Enter the following details: 2. 3. 4. 2 Click "Finish". "Claim rule name": "Name ID" "Incoming claim type": "Primary SID" "Outgoing claim type": "Name ID" "Outgoing name ID format": "Persistent Identifier"
22. 23. Ensure that the order is "LDAP" and then "Name ID". 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: 2. 3. Open up Chorus in your browser (e.g. https://chorus.example.com) If you're logged in, then logout. 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: