SAML 2.0 provides authentication between a service provider and an identity provider. is the service provider that will use your identity provider (Azure AD, Okta, OneLogin, PingFederate, Google, etc.) to authenticate the users into the application.

The workflow is typically:

  • Generate the metadata from the identity provider - this should not require any information from
  • Generate a new "application" in the identity provider. The information required from will typically be the "Service Provider Issuer" and the "Service Provider ACS URL".
  • In, create a new SAML IDMS by filling in the identity provider information, metadata, and assertions.
  • Test the integration and make any changes necessary.

We typically see the following challenges during this process:

  •  Identity provider "application" cannot be created first - if the metadata from the identity provider is the same for all applications, the SAML IDMS can be created first.
  • An error message is displayed when testing - you should try setting the Name ID Format to: urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

To assist with the setup of this IDMS, these instructions assume the (service provider) URL is and the identity provider URL is

To create a SAML 2.0 IDMS:

  1. In the left navigation menu, select Users > Identity Management Systems
  2. Click Add New
  3. In the IDMS Type drop-down menu, select SAML 2.0.
  4. In the IDMS Name field, enter a name to describe the IDMS.
  5. In the Identity Provider Issuer field, enter the URL that will issue the SAML 2.0 security token. (Ex. This is typically known as the Entity ID for the identity provider and it can be found in the metadata. If you look at your metadata, there should be an entityID field in one of the top lines. You can copy the entityID out of the metadata and paste it into this field.
  6. In the Identity Provider Metadata field, paste in the metadata from the identity provider. It should be in XML format.
  7. In the Service Provider Issuer field, enter the URL. Typically, this value will end in 1 and doesn't need to be changed. (Ex. This value is the Entity ID for When you download the metadata, you'll see this in one of the top lines as the value for the entityID field.
  8. The Service Provider ACS URL field will automatically populate the callback URL. (Ex. This is the callback/redirect URL the identity provider should use when sending the SAML assertions to If you need to reset this, click the Reset Service Provider ACS URL button, which will change the service provider ACS URL to match the current domain of your environment.
  9. In the Service Provider Binding field, leave the field as-is.
  10. In the optional Audience URI field, enter the SP Entity ID. (Ex. It should probably be set to the same as the Service Provider ACS URL field for some identity providers if there are errors during initial configuration.
  11. In the optional Allowed Auth Context field, enter an allowed value. This is the auth context from the specification that is required to login to (Ex. urn:oasis:names:tc:SAML:2.0:ac:classes:TimeSyncToken)
  12. In the optional Auth Context for Privilege Elevation field, enter an allowed value that will provide the user with the ability to access the cloud console. If this field is blank, console access will not be limited by auth context. (Ex. urn:oasis:names:tc:SAML:2.0:ac:classes:SmartcardPKI)
  13. In the optional Name ID Format field, enter a format that is used. (Ex. urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified). This is the first field you should try changing when testing.
  14. If requests are signed, check the box: Should Sign AuthN Requests.
  15.  Version 2.27.0 and higher: Check the Enable Single Logout box to automatically invalidate and end the SAML session when a user logs out of
  16.  Version 2.28.0 and higher: Check the Enable Custom Login URL to direct users to log in using an external URL. Once you check this box, you can add your custom URL in the Custom Login URL field that displays.
  17. Select the Canonicalizer from the drop-down menu.
  18. In the First Name field, enter the field from the IDP that will be mapped to the user first name field. (Ex. first_name)
  19. In the Last Name field, enter the field from the IDP that will be mapped to the user last name field. (Ex. last_name)
  20. In the Email field, enter the field from the IDP that will be mapped to the user email field. (Ex. email)
  21. In the Phone Number field enter the field from the IDP that will be mapped to the user phone number field. This is an optional field.
  22. In the Username field, enter the field from the IDP that will be mapped to the user username field. (Ex. username)
  23. Fill in the Validation Rules, Access Rules, and User Group Associations as necessary. All of these fields read the SAML assertions by "Name" and then apply the regular expression ("RegEx") to the value of the assertion. The regex simply returns either a true or false based on the expression.
    • Validation Rules - allow you to prevent the ability for users to log into the application via SAML assertions. If any of the expressions returns false, the user cannot log into
    • Access Rules - allow you to set the level of Console Access available to users via SAML assertions. If no access rules are specified, then all users have "Full Access". If any access rules are specified, then all users have "No Access".
      • Full Access - this is the default level of access. It means customers may use Cloud Access Roles to login to access the cloud consoles. It does not mean users have full access to anything, it just means that the use of Cloud Access Roles is allowed for them.
      • Restrict Console Access - this level of access allows you to log in and use the application, but they cannot log into any cloud consoles. This is useful if you have a SAML provider that allows users to login with a SmartCard vs a password. Typically, users with a SmartCard would be granted "Full Access" while users with just a password would be granted "Restrict Console Access".
      • No Access  - this level of access means a user is not allowed to log into This is the equivalent of a "Validation Rule". If any Access Rules are set, then this becomes the default level of access.
    • User Group Associations - allow you to automatically add or remove users to groups in based on SAML assertions. If the expression returns true, the user will be added to the user group at login. If the expression returns false, group membership will not change, unless the Should Update on Login option is checked.
      • Choose the user group Association Type. The default is to Add User Group Associations Manually, but you can also choose LDAP Sync. This allows you to sync users and groups from LDAP while still using a SAML IDMS for login. If you choose LDAP Sync, fields will display to enter your LDAP information (you can see examples for these fields in the Add an Active Directory IDMS article).
      • If the Should Update on Login option is checked, any expressions that return false will remove the user from the designated groups. Ensure you don't have multiple associations for the same group because they will overwrite each other. If you remove an association, it will not affect previous group membership.
  24. Click Upload Icon to upload a custom icon.

  25. Click Create IDMS.


Was this article helpful?
0 out of 0 found this helpful