
Benjamin KAHANE
- Updated
Notes:
Azure AD has two types of enterprise applications – Gallery applications and Non-Gallery applications. Flex must be configured as a Non-Gallery application.
The following articles on the Microsoft website are useful reference points:
The following settings are used for Basic SAML Configuration:
Name | Value |
Identifier (Entity ID) | urn:dalet:flex:flex-login-app |
Reply URL (Assertion Consumer Service URL) | like https://{account}.{your-flex-deployment.com}/login/saml/SSO |
Sign on URL | like https://{account}.{your-flex-deployment.com}/login/saml/SSO |
Relay State | desired Flex entry point, e.g. https://{account}.{your-flex-deployment.com}/fmp/index/ for the MAM UI |
Logout URL | Optional like https://{account}.{your-flex-deployment.com}/login/saml/SingleLogout |
Service Provider Issuer | Required if Logout URL is specified likeurn:dalet:flex:flex-login-app |
For more information on global logout in Azure AD, see the following article on the Microsoft website:
https://docs.microsoft.com/en-us/azure/active-directory/develop/single-sign-out-saml-protocol.
Please follow the User Attributes And Claims to see what all are required user attributes & claims need
to be configured. The login attribute statement is optional.
Name | Value |
login |
user.userprincipalname
|
user.mail | |
firstName | user.givenname |
lastName | user.surname |
flexAccountUuid |
for this value, input the Flex account UUID you identified earlier
|
The externalUniqueUserId claim can be configured to an user profile and same can be configured along with above attributes to make it available in SAML response.
For more information on customised claims in Azure AD, see the following article on the Microsoft website: https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-saml-claims-customization.
Note: Keep the Namespace URI field blank while configuring user attributes & claims statements.
If users are designed to land on applications from Azure by clicking an icon from Azure dashboard we need to configure a separate Azure entry for each application. If you look at above configuration parameters, there is no context of application i.e. Azure / application will not know where to land after successful authentication, this can be solved by providing a value in Default Relay State, which specifies the redirect destination following successful authentication.
Below is the table for all the Flex applications and their corresponding URLs.
Application | Default Relay State |
Flex Core | https://{account}.{your-flex-deployment.com}/ |
FlexMAM | https://{account}.{your-flex-deployment.com}/fmp/index/ |
FlexREVIEW | https://{account}.{your-flex-deployment.com}/review/ |
FlexTRACK | https://{account}.{your-flex-deployment.com}/dashboard/ |
FlexMOVE | https://{account}.{your-flex-deployment.com}/upload/ |
Metadata Designer | https://{account}.{your-flex-deployment.com}/metadata/ |
Workflow Designer | https://{account}.{your-flex-deployment.com}/workflow/ |
Note:
The Default Relay configuration is only required if you want to initiate authentication from an IdP dashboard. If you were to initiate authentication from the Flex login page, you don't need multiple IdP entries for different applications; one entry will suffice in the Azure AD configuration, e.g.
https://{account}.{your-flex-deployment.com}/fmp/index/.
It's also worth noting that depending on the configuration of the load balancer, the trailing ‘/’ may need to be removed for the defined relay states above to function correctly.
This can be uploaded to Azure AD using the certificate file that you created earlier.
Now that the Azure AD configuration is in place, we need to obtain the IdP metadata XML from our new Azure AD
Non-Gallery application. (We are not interested in the Federation metadata XML.)
Note:
Azure AD does not provide a URL for dynamic IdP metadata retrieval - it can only be obtained as a static XML file.
For more details, see the following article on the Microsoft website:
https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/troubleshoot-saml-based-sso#where-do-i-get-the-application-metadata-or-certificate-from-azure-ad.
The IdP Metadata XML provided by Azure AD 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 Signature needs to be removed.
Towards the top of the XML file, you’ll find the line:
<Signaturexmlns="http://www.w3.org/2000/09/xmldsig#">
This XML element and all its contents must be removed, down to and including:
</Signature>
An example of the section to be removed can be seen below:
Save the modified XML file as it will be needed in the next section.
Notes:
For more information on Azure AD IdP Group attribute mapping (required for IdP to Flex Group membership sync), see the
following articles:
Comments
2 comments
Note after some tests with a customer
This table could also indicate the "method" on each endpoints
like https://{account}.{your-flex-deployment.com}/login/saml/SingleLogout
likeurn:dalet:flex:flex-login-app
Both https://{account}.{your-flex-deployment.com}/login/saml/SSO and https://{account}.{your-flex-deployment.com}/login/saml/SingleLogout expect a POST (not a GET)
Notes regarding Azure AD and the Sign on URL...
Microsoft states 'This URL contains the sign-in page for the application that will perform the service provider-initiated single sign-on. Leave it blank if you want to perform identity provider initiated single sign-on.'
In other words, if you want to access Flex by clicking the FlexMAM App under 'Microsoft Apps' (https://myapps.microsoft.com/), then leave this field blank... Don't set any URL for it. Users can still click the Blue Button on the Flex Login page and authenticate via the Azure IdP with no issues. Basically, it appears there's no reason to populate the 'Sign on URL' these days.

Please sign in to leave a comment.