TestOps logo
Try TestOps

Users authentication with OpenID and Azure AD

The instructions below are only valid for Allure TestOps version 5.8.1 and onwards.

Prerequisites

  1. You need to have administrative access to your Azure AD or an admin near you.
  2. You need the access to Allure TestOps configuration files.
  3. You need to be able to apply the changes in the configuration, which could require some downtime.
  4. Allure TestOps needs to be working behind HTTPS, i.e. there must be something like reverse proxy between Allure TestOps and Azure AD servers. Please consult your network administrator or DevOps to ensure proper configuration on the network side.

Integration of Allure TestOps and Azure AD

Our starting point will be the following.

  1. Allure TestOps is deployed and accessible on https://testops.local your URLs definitely will be different.
  2. Your Azure AD instance settings are available here: https://portal.azure.com

Configuration on Azure AD side

Here is Microsoft's guide on how to make all the needed preparations for the integration: Open the link

Long story short here is what needs to be done on Azure portal side.

  1. Azure Active Directory B2C resource needs to be created.
  2. Azure AD B2C Tenant needs to be created.
    • At this step you will have your new AD created.
  3. New App registration (that would be the OpenID client) must be added.
  4. You need to create a secret, that will be used by the registered for the authentication in AD.

Configuring the Redirect URI on Azure AD side

The Redirect URI is related to the Allure TestOps deployment and consists of three parts:

  • Allure TestOps instance URL, e.g. https://testops.local
  • fixed part /login/oauth2/code/
  • Suffix with the name of the provider
    • for docker compose and Linux packages deployment suffix will be openid
    • for the Helm Chart deployment suffix can be set by the parameter providerName in the values.yaml file. Please remember the provider name mustn't contain neither spaces nor special character, i.e. should be one word.

The final string would look like follows:

https://testops.local/login/oauth2/code/openid

To add a valid redirect URI to the configuration of the created application follow these steps.

  1. From the Home of https://portal.azure.com proceed to Azure AD B2C resource.
  2. Select App registrations → All applications tab.
  3. Select the application created while reading Microsoft's manual.
  4. Select Authentication section.
  5. Add a new record with valid Redirect URI you created on previous step.
  6. Save the settings.

Getting Azure AD OpenID endpoints

As a result of all actions described in the MS article you will have the following parameters ready to be used for the integration of your Allure TestOps instance with your Azure AD tenant.

  • Application (client) ID.
  • Client's secret.
  • OpenID connect metadata (the endpoints, you need to provide to Allure TestOps configuration).
    • Authorization Endpoint (URI).
    • JWKS Endpoint (URI).
    • Token Endpoint (URI).

All endpoints used by OpenID flows, are accessible from AzureAD B2C tenant.

  1. From the Home of https://portal.azure.com proceed to Azure AD B2C resource.
  2. Select App registrations.
  3. Select Endpoints tab.
  4. In the opened panel locate Microsoft Entra ID OpenID Connect metadata document
  5. Copy the content of the section above and paste to your browser address field and follow the link.
  6. In the opened page you will find the metadata related to your AD Tenant.
  7. In the opened page locate and copy following endpoints.
    • authorization_endpoint
      • it will be generated by the template https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
    • jwks_uri
      • it will be generated by the template https://login.microsoftonline.com//discovery/v2.0/keys
    • token_endpoint
      • it will be generated by the template https://login.microsoftonline.com//oauth2/v2.0/token

Getting Azure AD OpenID metadata

To successfully configure Allure TestOps instance as OpenID client we nee to get the following data on the Application (OpenID client) created at Azure AD tenant.

Application ID

  1. From the Home of https://portal.azure.com proceed to Azure AD B2C resource.
  2. Select App registrations → All applications tab.
  3. Select the application created while reading Microsoft's manual.
  4. Copy Application (client) ID value from the Essentials section.

Getting Application ID

Client secret

  1. Starting point is the previous step, where we got the Client ID.
  2. Go to Client credentials in the Essentials section or go directly to Certificates & Secrets in the side menu.
  3. Click New client secret
  4. Set the secret expiration date.
  5. Copy the value of the created secret and save it in a safe place. Then use the client's secret in the configuration of Allure TestOps.

Getting client's secret

Configuring Allure TestOps

For Kubernetes deployment you need to configure the integration with Azure AD in auth.openid section of values.yaml file.

auth
  primary: openid
  openid:
    enabled: false
    providerName: azure
    clientName: testops
    clientId: 111111-abcd-1111-b111-111f111b11ee
    clientSecret: "CLIENT-SECRET-HERE"
    redirectUri: https://testops.local/login/oauth2/code/azure
    scope: openid, email, profile
    authorizationGrantType: authorization_code
    authorizationUri: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
    jwksSetUri: https://login.microsoftonline.com/<tenant-id>/discovery/v2.0/keys
    tokenUri: https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
    usernameAttribute: preferred_username
    defaultRole: ROLE_GUEST
    syncRoles: false
    groupRoleAttribute: groupRoleAttribute
    roleUserGroups: roleUserGroups
    roleAdminGroups: roleAdminGroups
    # userinfoUri: https://graph.microsoft.com/oidc/userinfo
    userinfoUri:
    # issuerUri: https://login.microsoftonline.com/a411f6bf-a08d-4aab-bef9-7f0991b2ec76/v2.0
    issuerUri: 
    firstNameAttribute:
    lastNameAttribute:
  • auth.primary is to be set to openid
  • auth.openid.enabled is to be set to true
  • auth.openid.providerName is the name of the OpenID provider that will appear on the login screen.
    • providerName should be one word without spaces and special characters, e.g. azure.
  • auth.openid.clientName is to be set to the value you set for Allure TestOps while configuring the application
  • auth.openid.clientId is the ID of Allure TestOps as an OpenID client
  • auth.openid.clientSecret is the secret of Allure TestOps as an OpenID client
  • auth.openid.redirectUri is the string consisting of Allure TestOps URL, fixed string /login/oauth2/code/ and providerName
    • for example, https://testops.local/login/oauth2/code/azure
  • auth.openid.scope can be for example openid, email, profile, but must at least contain openid scope.
  • auth.openid.authorizationGrantType used by Allure TestOps is authorization_code
  • auth.openid.authorizationUri is the endpoint string we got at this step
  • auth.openid.jwksSetUri is the endpoint string we got at this step
  • auth.openid.tokenUri is the endpoint string we got at this step
  • auth.openid.usernameAttribute is the claim name to be used by Allure TestOps to create the username of the successfully authenticated user.
    • usernameAttribute can be for example preferred_username, email etc.
  • auth.openid.defaultRole defines the global role of the successfully authenticated user. It can be ROLE_GUEST, ROLE_ADMIN, ROLE_USER
    • we recommend using ROLE_GUEST for better licence consumption control.
  • auth.openid.syncRoles parameter defines whether the assignment of the global roles for the user should be done based on the end user's membership in a certain group on the OpenID provider side.
  • auth.openid.groupRoleAttribute defined the name of the claim to look in for the group names.
    • auth.openid.roleUserGroups contains the list of groups which membership grants ROLE_USER global role
    • auth.openid.roleAdminGroups contains the list of groups which membership grants ROLE_ADMIN global role
  • auth.openid.userinfoUri generally, parameter is not used by Allure TestOps
  • auth.openid.issuerUri generally, parameter is not used by Allure TestOps
  • auth.openid.firstNameAttribute defines the key (name) of the claim, containing the name (first name) of the authenticated user
    • can be left blank for standard OpenID claim name for the name
  • auth.openid.lastNameAttribute defines the key (name) of the claim, containing the surname (last name) of the authenticated user
    • can be left blank for standard OpenID claim name for the surname

This section is WIP.

The settings for the configuration of OpenID are mostly described in .env file, the alteration of docker-compose.yml file is not required.


TESTOPS_OPENID_CLIENTNAME=testops
TESTOPS_OPENID_CLIENTID=<YOUR_CLIENT_ID>
TESTOPS_OPENID_CLIENTSECRET=<YOUR_CLIENT_SECRET_HERE>
TESTOPS_OPENID_REDIRECTURI=http://<your-testops-domain>/login/oauth2/code/openid
TESTOPS_OPENID_SCOPE=openid,email,profile
TESTOPS_OPENID_USERNAMEATTRIBUTE=preferred_username
TESTOPS_OPENID_AUTHORIZATIONGRANTTYPE=authorization_code
TESTOPS_OPENID_AUTHORIZATIONURI=http://<open_id_provider_url>/somepath/openid-connect/auth
TESTOPS_OPENID_JWKSETURI=http://<open_id_provider_url>/somepath/keys
TESTOPS_OPENID_TOKENURI=http://<open_id_provider_url>/somepath/token

# next two are commented in the docker-compose.yml as these aren't used
# uncomment these in docker-compose.yml if you know what you are doing and really need using these for the integration with IdP
# TESTOPS_OPENID_ISSUERURI=http://<open_id_provider_url>/realms/<you_realm>
# TESTOPS_OPENID_USERINFOURI=http://<open_id_provider_url>/realms/<you_realm>/protocol/openid-connect/userinfo

TESTOPS_OPENID_FIRSTNAMEATTRIBUTE: first_name
TESTOPS_OPENID_LASTAMEATTRIBUTE: last_name

TESTOPS_OPENID_DEFAULTROLE=ROLE_GUEST
TESTOPS_OPENID_SYNCROLES=false
# lnked parameters for next 3 need to be commented in docker-compose.yml if TESTOPS_OPENID_SYNCROLES=false
TESTOPS_OPENID_GROUPROLEATTRIBUTE=group
TESTOPS_OPENID_GROUPAUTHORITIES_ROLEUSERGROUPS=roleUserGroups
TESTOPS_OPENID_GROUPAUTHORITIES_ROLEADMINGROUPS=roleAdminGroups

Configuration for the OpenID usage is done in the /opt/testops/conf/testops.conf configuration file.

This section is WIP

# openid settings
# ALLURE_LOGIN_OPENID_DEFAULTROLE=[ROLE_GUEST, ROLE_USER, ROLE_ADMIN]
# the name of testops as openid client in openid provider configuration
# SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OPENID_CLIENTNAME=testops
# generally the ID of testops application in openid provider configuration
# check in the openid provider
# SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OPENID_CLIENTID=aaabbb-aaa-aaabbb12345-1234
# check in the openid provider config
# SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OPENID_CLIENTSECRET=authentication-secret-generated-by-openid-provider
# the part `/login/oauth2/code/openid` is fixed, the part https://allure-testops-instance-url depends on your deployment
# SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OPENID_REDIRECTURI=https://allure-testops-instance-url/login/oauth2/code/openid
# leave as it is
# SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OPENID_SCOPE=openid,email,profile
# leave as it is
# SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OPENID_AUTHORIZATIONGRANTTYPE=authorization_code
# check in the openid provider metadata
# SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OPENID_AUTHORIZATIONURI=http://<open_id_provider_url>/somepath/openid-connect/auth
# can be email, preferred_username
# usually preferred_username
# SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OPENID_USERNAMEATTRIBUTE=preferred_username
# check in the openid provider metadata
# SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OPENID_JWKSETURI=http://<open_id_provider_url>/somepath/keys
# check in the openid provider metadata
# SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OPENID_TOKENURI=http://<open_id_provider_url>/somepath/token
# these are optional parameters you can enable if it's required by your openid provider
# leave these commented by default
# check in the openid provider metadata
# SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OPENID_ISSUERURI=http://<open_id_provider_url>/somepath/issuer
# check in the openid provider metadata
# SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OPENID_USERINFOURI=http://<open_id_provider_url>/somepath/userinfo
# define the name of the claim, containing the name (first name) of the user being authenticated
# ALLURE_LOGIN_OPENID_FIRSTNAMEATTRIBUTE=first_name
# define the name of the claim, containing the surname (last name) of the user being authenticated
# ALLURE_LOGIN_OPENID_LASTAMEATTRIBUTE=last_name
# these parameters are for the usage with OpenID IdP groups to assign the global roles to users
# depending on the membership in OpenID provider groups      
# ALLURE_LOGIN_OPENID_SYNCROLES defines if the assignment of a global role based on openid groups is used
# ALLURE_LOGIN_OPENID_SYNCROLES=false
# next parameters need to be uncommented only if ALLURE_LOGIN_OPENID_SYNCROLES=true
# name of the claim defining the groups membership
# ALLURE_LOGIN_OPENID_GROUPROLEATTRIBUTE=groups
# name of the openid group with TestOps Users
# ALLURE_LOGIN_OPENID_GROUPAUTHORITIES_ROLEUSERGROUPS: ${TESTOPS_OPENID_GROUPAUTHORITIES_ROLEUSERGROUPS}
# name of the openid group with TestOps Admins
# ALLURE_LOGIN_OPENID_GROUPAUTHORITIES_ROLEADMINGROUPS: ${TESTOPS_OPENID_GROUPAUTHORITIES_ROLEADMINGROUPS}

Logging in as a system account

It might be needed to login as a local (aka system account when the default authentication method is set as openid). In this case, you need to use an alternative login path in your browser address field and set the URL as follows: https://testops.local/login/system, Allure TestOps then will log you in as a system account.

© Qameta Software Inc. All rights reserved.