SAML 2.0 protocol is one of the ways to enable single sign-on authentication (SSO). To configure SAML 2.0 for your Allure TestOps, follow the steps below.
SAML is based on communication between a service (in this case, Allure TestOps) and IdP (such as Okta or Keycloak) by way of HTTP redirects:
A user attempts to access an Allure TestOps page.
If the user is not authenticated, Allure TestOps prompts to sign in using SAML. To do this, the user clicks the button with the name of the IdP.
When the user clicks the button, Allure TestOps creates a SAML request and redirects the user’s browser with that information to the IdP page.
The user enters their credentials on the IdP page.
The IdP creates a SAML assertion that contains all the information Allure TestOps needs to authenticate the user, and redirects the browser with that information back to Allure TestOps.
Allure TestOps authenticates the user using the information from the SAML assertion.
SAML2 can also be used without SAML2 client (in this case – Allure TestOps) requests. For example, a user can first sign in to Okta, then click a button for Allure TestOps application that will redirect authenticated user to Allure TestOps.
Сonfigure Allure TestOps to work with SAML2
We highly recommend beginning the configuration of SAML2 with Okta only after successful start and initialisation of Allure TestOps and registration of the first administrator.
To complete the integration of Allure TestOps with Okta as identity provider, we need get 3 endpoints:
Two SAML2 specific endpoints on Allure TestOps side:
Entity ID
ACS URL
Metadata URL on Okta side.
It will be available only after the creation of the SAML2 application in Okta.
Getting Allure TestOps endpoints
Open the configuration file of Allure TestOps you used for the initial deployment
The configuration is mostly performed in the auth: section of values.yaml file.
general parameters that need to be set:
network.tls.enabled — must be true;
auth.primary — must be system when we start configuration, and then saml2 when we have completed the configuration.
General SAML2 configs:
auth.saml.enabled — must be true;
auth.saml.id — name of the IdP that will be rendered in the UI. This name will be used in the endpoints as well, so use of whitespace and special characters is forbidden here;
name it okta
Endpoints:
auth.saml.entityId — https://<domain>/api/login/saml2/authenticate/{registrationId}, where <domain> is the domain name of your Allure TestOps instance;
replace <domain> with the URL of your Allure TestOps instance
the value {registrationId} at the end of the auth.saml.entityId parameter is correct for Allure TestOps purposes, but for Okta we need to alter this string as follows:
copy https://<domain>/api/login/saml2/authenticate/{registrationId} and replace {registrationId} with the value from auth.saml.id
the resulting string required in Okta will be https://<domain>/api/login/saml2/authenticate/okta
auth.saml.acsUrl — https://<domain>/api/login/saml2/sso/{registrationId}, where <domain> is the domain name of your Allure TestOps instance;
replace <domain> with the URL of your Allure TestOps instance
the value {registrationId} at the end of the auth.saml.acsUrl parameter is correct for Allure TestOps purposes, but for Okta we need to alter this string as follows:
copy https://<domain>/api/login/saml2/sso/{registrationId} and replace {registrationId} with the value from auth.saml.id
the resulting string required in Okta will be https://<domain>/api/login/saml2/sso/okta
auth.saml.identityProviderMetadataUri — URL to the metadata stored on Okta side.
This parameter is not available yet, we'll get is as soon as SAMLw client is created on Okta side.
Edit the parameters in the .env file:
general parameters that need to be set:
TESTOPS_PROTO — must be https;
TESTOPS_SECURE_COOKIE — must be true;
ALLURE_LOGIN_PRIMARY — must be system when we start and then saml2 when we have completed the configuration.
General SAML2 configs:
LOGIN_SAML2_ENABLED — must be true;
LOGIN_SAML2_ID — name of the IdP. This name will be used in URLs and displayed on the sign-in button. Do not use whitespace and special characters;
use something short and concise, e.g. "okta"
Endpoints:
LOGIN_SAML2_ENTITY_ID — https://<domain>/api/login/saml2/authenticate/{registrationId}, where <domain> is the domain name of your Allure TestOps instance;
the value {registrationId} at the end of the LOGIN_SAML2_ENTITY_ID parameter is correct for Allure TestOps purposes, but for Okta we need to alter this string as follows:
copy https://<domain>/api/login/saml2/authenticate/{registrationId} and replace {registrationId} with the value from LOGIN_SAML2_ID
the resulting string required in Okta will be https://<domain>/api/login/saml2/authenticate/okta
LOGIN_SAML2_ACS_URL — https://<domain>/api/login/saml2/sso/{registrationId}, where <domain> is the domain name of your Allure TestOps instance;
the value {registrationId} at the end of the LOGIN_SAML2_ACS_URL parameter is correct for Allure TestOps purposes, but for Okta we need to alter this string as follows:
copy https://<domain>/api/login/saml2/sso/{registrationId} and replace {registrationId} with the value from LOGIN_SAML2_ID
the resulting string required in Okta will be https://<domain>/api/login/saml2/sso/okta
LOGIN_SAML2_METADATA_URL — URL to the metadata stored on Okta side.
This parameter is not available yet, we'll get is as soon as SAMLw client is created on Okta side.
Edit the parameters in the /opt/testops/conf/testops.conf file:
general parameters:
ALLURE_SECURE — must be true;
ALLURE_LOGIN_PRIMARY — must be system when we start and then saml2 when we have completed the configuration.
General SAML2 configs:
ALLURE_LOGIN_SAML2_ENABLED — must be true;
ALLURE_LOGIN_SAML2_ID — name of the IdP. This name will be used in URLs and displayed on the sign-in button. Do not use whitespace and special characters;
Endpoints:
ALLURE_LOGIN_SAML2_ENTITY_ID — https://<domain>/api/login/saml2/authenticate/{registrationId}, where <domain> is the domain name of your Allure TestOps instance;
the value {registrationId} at the end of the ALLURE_LOGIN_SAML2_ENTITY_ID parameter is correct for Allure TestOps purposes, but for Okta we need to alter this string as follows:
copy https://<domain>/api/login/saml2/authenticate/{registrationId} and replace {registrationId} with the value from ALLURE_LOGIN_SAML2_ID
the resulting string required in Okta will be https://<domain>/api/login/saml2/authenticate/okta
ALLURE_LOGIN_SAML2_ACS_URL — https://<domain>/api/login/saml2/sso/{registrationId}, where <domain> is the domain name of your Allure TestOps instance;
copy https://<domain>/api/login/saml2/sso/{registrationId} and replace {registrationId} with the value from ALLURE_LOGIN_SAML2_ID
the resulting string required in Okta will be https://<domain>/api/login/saml2/sso/okta
ALLURE_LOGIN_SAML2_METADATA_URL — URL to the metadata stored on Okta side.
This parameter is not available yet, we'll get is as soon as SAMLw client is created on Okta side.
Setting up SAML2 client application on Okta side
Sign in to your Okta’s admin panel.
In the sidebar, select Applications → Applications.
Click Create App Integration.
Select SAML 2.0 as the sign-on method and click Next.
Enter the App name (for example, Allure TestOps), then click Next. The app name will only be visible within Okta.
Paste the Assertion Consumer Service (ACS) URL link into the Single sign-on URL field.
from our example, this will be https://<domain>/api/login/saml2/sso/okta
Paste the Entity ID link into the Audience URI (SP Entity ID) field.
Scroll down and click Next to proceed.
Set attribute statements to map attributes between Okta and Allure TestOps:
email.
firstName.
lastName.
10.Optionally, set group mappings to use user's group membership from Okta to assign user role.
In our example end users on Okta side are added into groups ato_admins and ato_users
You can filter the group information that will be passed to Allure TestOps by several criteria. Choose the one that works best for you. If you want to send all group information, pick Matches regex from the dropdown menu and enter .* .
Click Next and in the Feedback section click Finish.
After completing the app integration, a window with your application details will appear. Copy Metadata URL. You will need it to complete configuration of SAML2 authentication settings in Allure TestOps configuration file.
Complete Allure TestOps configuration
We need to update the configuration parameters on Allure TestOps side with the information on the Metadata URL.
IdP Metadata
auth.saml.identityProviderMetadataUri — add the Metadata URL we got after the completion of setting up of the SAML2 application on Okta side.
SAML attribute names:
auth.saml.firstNameAttribute — name of the attribute containing the first name of a user.
from our example, the first name attribute will be firstName
auth.saml.lastNameAttribute — name of the attribute containing the last name of a user.
from our example, the last name attribute will be lastName
auth.saml.emailAttribute — name of the attribute containing the email address of a user.
from our example, the email attribute will be email.
auth.saml.groups.groupRoleAttribute — name of the attribute containing the names of the groups a user is a member of.
from our example, the groups attribute will be groups.
groups mapping:
auth.saml.syncRoles — if true, Allure TestOps will assign user roles according to group information from IdP;
auth.saml.groups.roleUserGroups — comma-separated list of IdP groups that correspond to the “User” role in Allure TestOps;
from our example the team members that should be assigned as ROLE_USER, the group name will be ato_users
auth.saml.groups.roleAdminGroups — comma-separated list of IdP groups that correspond to the “Admin” role in Allure TestOps;
from our example the team members that should be assigned as ROLE_ADMIN, the group name will be ato_admins
Checking SAML authentication before switching to SAML by default
When setting up SAML, we recommend using system authentication by default and switching to SAML2 only if you have successfully logged in using SAML and user got correct access rights.
When you are using system (username + password) authentication, you can access SAML2 login form by accessing the following URL.
https://<domain>/login/saml2
When all the tests of SAML2 login have been completed you can switch to SAML2 as default authentication method.
auth.primary — must be set to saml2.
ALLURE_LOGIN_PRIMARY — must be set to saml2.
ALLURE_LOGIN_PRIMARY — must be set to saml2.
Using SAML together with standard authentication
Typically, when a company configures a SAML authentication for Allure TestOps, the SAML IdP is considered the primary source of user account data, and SAML is set as the primary authentication method. However, there may be cases where you need to use local authentication, such as when signing in as the instance administrator. For these cases, Allure TestOps allows system authentication when SAML is set as the primary authentication method:
The /login page uses the authentication method defined as primary in the settings. In this case, it is SAML.
The /login/system page always uses system authentication.
To sign in as the instance administrator, go to https://<URL>/login/system and use the credentials of a local user.
