Setting up SAML with OKTA (4251916)

This article has been provided for reference and guidance purposes only. Changes in OKTA configuration may occur and are outside of Quest Support scope.

To enable SAML authentication:

• Go to Settings | Control Panel | SAML Settings
• Check the box for “Enable SAML Service Provider”
• Scroll down to "Local Service Provider (SP) Settings" and click on "View Metadata"
• Copy the "SP Entity Identifier (uri)" and "SP Assertion Consumer Service (url)"

- Don't save it yet!

In OKTA:

• Create the Application to be used for SMA SAML authentication.
• At the "SAML Settings" page, copy the information from the SMA Metadata (SAML Authentication) to be mapped as follows:
  • Single sign on URL = SP Assertion Consumer Service (url).
  • Audience URI (SP Entity ID) = SP Entity Identifier (uri).

   

- Rest of the settings:

• Name ID format = persistent
• Application username = Okta username

- Declare the attributes to use login mapping in the SMA (to avoid format mismatch we suggest using "unspecified" as name format).

• Next and finish the Application creation.
• Once the Application is created in OKTA.
  • Go to the Single Sing on tab and click on "Identity Provider metadata".
  • It will open a separate tab, copy the url.

   

Go back to the SMA, SAML settings page

• - Under "Security Assertion Markup Language (SAML)" click on "Get Metadata From IdP".
  • -- Optional but recommended check "IdP Does Not Support Passive Authentication".
  • Enter the copied url from OKTA "Identity Provider metadata" into "IdP Metadata URL".
  • Click on "Import IdP Metadata".
• - A green banner will appear saying "IdP Metadata Import Success" and fields below will be populated.

IdP Attribute Mappings

• Although you will see 3 options, the recommended one is always: Use SAML
• Specify the Primary Key and SAML Claim for the Mapping (OKTA attribute statement value)

*  The Primary Key is a field in a table that prevents you from uploading the same data more than once and creating duplicate information. When it comes to SMA if there are existing users imported from LDAP to avoid duplicate records it is very important to make sure the selected primary matches the existing record otherwise a new record will be created.

The primary key is used during SAML login to recognize an existing user and avoid duplicate records. If the value of the primary key does not match, a new user record is created.

Role Mapping

At this point the users from the SMA should be already imported and assigned to the application.

- The role mapping can be done with a declared attribute or with groups

•  For Attributes: Review the user profile to get the correct value, the format is “user.AttributeName”
•  For Groups: There are some items to keep in mind:
  •  Groups need to be assigned to the Application and the users profile in OKTA
  •  Similar to the Attributes, in the SMA the value to be specified is the one that needs to match with the specific role
  •  -- The Group Attribute Statement need to be properly declared in OKTA, in this case if using more than one the following variable could be used: (.*)  with operator “Matches REGEX” so that way it will pass all groups assigned to the application

Example for Role mapping Below:

• The role mapping:
  • On the below image, SAML has been set to use 2 roles:
    
    • Administrator: Any user part of group CKASAdmin will be granted with “Administrator” role
      
    • Read Only Administrator: Any user which department attribute matches “revision” will be granted with “Read Only Administrator” role
      
    • At user login the SMA will verify the information passed from OKTA and map the role accordingly.