SAML 2.0 with Okta

If your company manages accounts in Okta, you can let users sign in to your Allure TestOps Cloud instance with those accounts instead of separate Allure TestOps passwords. Okta acts as the identity provider (IdP): it authenticates the user and sends Allure TestOps a SAML assertion with the user's email, name, and, optionally, group memberships that decide the user's global role.

This page describes the steps for Okta. For the general process, the way user accounts are handled, and the common sign-in errors, see Configuration of SAML2 SSO in a Cloud instance.

Before you begin

• Allure TestOps account with the Admin role and a local password. You will need it if the SAML configuration has to be fixed after the switch. See Keep a way back in.
• Okta administrator account that can create app integrations.
• Group names you plan to map to Allure TestOps roles, if you want roles to come from Okta.

1. Start the SAML 2.0 configuration in Allure TestOps

1. Sign in to Allure TestOps as an administrator.

2. Go to Administration → Authentication.

3. Next to SAML 2.0, click Configure.

   

4. Under Configuration Name, enter a name for this configuration, for example, Okta. Users will see it on the sign-in button as Login via Okta.

5. Under Service Provider Details, copy the Entity ID and the Assertion Consumer Service (ACS) URL.

Keep this browser tab open. You will come back to it to paste the metadata URL from Okta.

2. Create the app integration in Okta

1. Sign in to the Okta Admin Console.

2. In the sidebar, select Applications → Applications.

3. Click Create App Integration.

4. Select SAML 2.0 as the sign-in method and click Next.

5. Enter the App name, for example, Allure TestOps, and click Next. The name is visible only in Okta.

6. Fill in the fields with the URLs from step 1:

   Okta field	Value from Allure TestOps
   Single sign-on URL	Assertion Consumer Service (ACS) URL
   Audience URI (SP Entity ID)	Entity ID

Copy both URLs exactly as Allure TestOps shows them, including the registration ID at the end.

3. Set the attribute statements

On the same page, under Attribute Statements, add the attributes that Okta sends to Allure TestOps:

These names match the default values under Attribute Mapping in Allure TestOps. If you use other names, enter them in Allure TestOps in step 7.

4. Add the group attribute (optional)

Skip this step if you don't need roles from Okta. In that case, every new user gets the default global role.

To let Allure TestOps assign roles based on group membership, add a statement under Group Attribute Statements:

1. In Name, enter the attribute name, for example, groups. You will enter the same name as Role attribute name in IdP in Allure TestOps.
2. In Filter, select which groups Okta sends. For example, select Starts with and enter ato_ to send only the groups with this prefix. To send all groups, select Matches regex and enter .*.

5. Copy the metadata URL

1. Scroll down and click Next.

2. In the Feedback section, click Finish.

3. On the application page, go to the Sign On tab and copy the Metadata URL.

   

6. Assign users and groups to the application

Only users assigned to the application, directly or through a group, can sign in to Allure TestOps through Okta.

1. On the application page, go to the Assignments tab.
2. Click Assign and select Assign to People or Assign to Groups.
3. Select the users or groups who should have access to Allure TestOps and confirm the assignment.

7. Finish the configuration in Allure TestOps

Return to the dialog from step 1. To change a saved configuration later, go to Administration → Authentication and click Edit configuration next to SAML 2.0.

1. Under Identity Provider Details, select Metadata URL and paste the URL from Okta.

2. Under Attribute Mapping, check that the values match the names from step 3:

   • Email Attribute: email
   • First Name Attribute: firstName
   • Last Name Attribute: lastName

3. Click Save.

Default global role

In the drop-down next to Default global role, select the role for users to whom no role mapping applies. See Default global role for the description of the roles.

Don't use Admin as the default role. Every Okta user who is assigned to the application would get full control over the instance. Use the role with the least permissions your team needs, and grant more through role mapping.

Role mapping (optional)

If you added the group attribute in step 4, click Configure mapping next to Role mapping and fill in the fields:

• Role attribute name in IdP: the Name from Group Attribute Statements in Okta, for example, groups. The names must match exactly.
• User maps to: Okta groups whose members get the User role.
• Admin maps to: Okta groups whose members get the Admin role.
• Sync frequency: when Allure TestOps updates the role from Okta, at First sign-in or at Each sign-in (recommended).

Click Save. See Role mapping for how Allure TestOps determines the role from the groups.

8. Switch the authentication method to SAML 2.0

1. On the Authentication page, in the Authentication method list, select SAML 2.0.
2. Confirm the switch by clicking Yes, switch.

The indicator next to the configuration name turns green. Users will authenticate through Okta the next time they sign in. Check the result as described in Verify the sign-in.

Troubleshooting

If Okta shows an error on its page after the user clicks Login via Okta, check that the user or their group is assigned to the application, see step 6, and that the URLs in step 2 match Allure TestOps.

For the errors that Allure TestOps shows on the sign-in page, see Troubleshooting.