
Benjamin KAHANE
- Updated
Notes:
This guide has been created with the assumption that users have a certain level of familiarity with SAML. Below are the steps for configuring SAML using AD FS as an IdP (identity provider).
The following steps are performed within the AD FS Management Tool.
Add a Relying Party Trust.
For "Select Data Source", import the Flex SAML Metadata.
Specify a Display Name
Keep clicking the next button, leaving default options selected, until the finish screen (close button) appears.
Right click on Relying Party Trust & select Properties, and navigate to the Identifiers Tab.
urn:ooyala:flex:flex-login-app should be present under relying party identifier list.
Note: Each identifier for a relying party trust must be unique across all relying party trusts in AD FS configuration. It will not allow to create a new relying party trust if the same identifier already exists in any of previously created relying party trusts.
Once the Relying Party Trust has been added successfully, a few configuration parts need to be updated.
Right click on Relying Party Trust & select Properties, and navigate to the Endpoints Tab. The fields
highlighted in the screenshots below (URL, Index, Binding, Default) should all be set appropriately for your environment, according to the guidelines in the table underneath.
Name | URL | Index | Binding | Default |
SAML Assertion Consumer Endpoints - POST | like https://{account}.{your-flex-deployment.com}/login/saml/SSO | 0 | POST | Yes |
SAML Assertion Consumer Endpoints - Redirect | like https://{account}.{your-flex-deployment.com}/login/saml/SSO | 1 | Redirect | No |
SAML Logout Endpoints - POST |
like https://{account}.{your-flex-deployment.com}/login/saml/SingleLogout
|
POST | No | |
SAML Logout Endpoints - Redirect |
like https://{account}.{your-flex-deployment.com}/login/saml/SingleLogout
|
Redirect | No |
Navigate to the Advanced tab. The Secure hash algorithm field should be set to SHA-256.
Note: Please follow the User Attributes And Claims to see what all are required user attributes & claims need to be configured.
Note: It is important to pay very close attention to spelling and capitalization of all of these, and also to create the claims in the order specified below (particularly important for the last three).
Using Add Rule, create a 'Send Claims Using a Custom Rule' claim for flexAccountUuid, configured as per the screenshot below, using the Flex account UUID you identified earlier.
> Syntax => issue(Type = "flexAccountUuid", Value = "<your Flex account UUID>");
Create a 'Send LDAP Attributes as Claims' claim for login, configured as per the screenshot below.
Create a 'Send LDAP Attributes as Claims' claim for firstName, configured as per the screenshot below.
Create a 'Send LDAP Attributes as Claims' claim for lastName, configured as per the screenshot below.
Note: Similarly the externalUniqueUserId claim with unique identifier value can be configured to an user profile.
Create a 'Send LDAP Attributes as Claims' claim for Make Email Address Available For Other Claims, configured as per the screenshot below.
This is so that the two subsequent claims can both make use of the same property.
Create a 'Transform an Incoming Claim' claim for NameID, configured as per the screenshot below.
Create a 'Transform an Incoming Claim' claim for email, configured as per the screenshot below.
This is optional claim as per the User Attributes And Claims.
If you need to define a new user in the AD FS server for testing purposes, make sure all details required for the claims above have been properly entered.
Now that the AD FS configuration is in place, we need to obtain the IdP metadata XML.
The IdP Metadata XML provided by AD FS is unfortunately not fully compliant with SAML standards. Therefore, for it to be used in Flex, some manual customization is needed.
This is an important step; if the XML is not edited correctly, not only will SAML not function, but it could potentially cause the Flex Login App to stop functioning. After editing this file, we recommended you securely validate the XML (do not use a SAML Metadata XML Validator; even the un-edited version will fail).
The XML metadata block for ds:Signature needs to be removed.
Towards the top of the XML file, you’ll find the line: <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
This XML element and all its contents must be removed, down to and including: </ds:Signature>.
Similarly, the XML metadata blocks for RoleDescriptor (of which there may be more than one) and SPSSODescriptor need to be removed.
Save the modified XML file as it will be needed in the next section.
Notes:
Comments
0 comments
Please sign in to leave a comment.