OpenID with Azure AD

Users authentication with OpenID and Azure AD

If you are going to implement this type of authentication this action implies you clearly understand what you are doing.

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 work behind HTTPS, i.e. there must be something like reverse proxy between Allure TestOps and GSuite servers. Please consult your network administrator or DevOps to ensure proper configuration on the network side.

Integration of Allure TestOps and Azure AD

Given

  1. Allure TestOps is deployed and accessible on http://allure.local your URLs 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

On the previous step we’ve got the following parameters we are going to use for the integration:

  • Application (client) ID.
  • Client’s secret (token).
  • OpenID connect metadata

Application ID

if you see this text, report to support.qameta.io

Client’s secret

if you see this text, report to support.qameta.io

OpenID connect metadata

This parameter is to be used without this part: .well-known/openid-configuration

if you see this text, report to support.qameta.io

Configuring Allure TestOps

On Allure TestOps side you need to update the configuration of gateway service.

See below for the deployment specific examples.

Deployment in Kubernetes

For k8s deployment you need to add the parameters to secret environment of gateway service of values.yaml file used to pass user’s configuration to Helm.

version: <check release notes>
<snip>
gateway:
  env:
    secret:
      # security
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_CLIENTNAME: Azure
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_CLIENTID: <Application (client) ID>
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_CLIENTSECRET: <Client secrets (Token)>
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_REDIRECTURI: https://allure.local/login/oauth2/code/azure
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_SCOPE: [openid, email, profile] #select preferred
      SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_AZURE_ISSUERURI: <OpenID Connect metadata>
      SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_AZURE_USERNAMEATTRIBUTE: email
<snip>

Now, you need to update your Allure TestOps configuration as usual for Kubernetes installation using Helm’s commands. to use Azure AD as Identity provider.

Deployment via docker-compose

For the deployment done via docker-compose you need to update docker-compose.yaml configuration file by adding the parameters to gateway service.

Updating of the configuration requires downtime to properly stop and run the application.

  gateway:
    image: allure/allure-gateway:${VERSION}
    environment:
      # settings
<snip>
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_CLIENTNAME: Azure
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_CLIENTID: <Application (client) ID>
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_CLIENTSECRET: <Client secrets (Token)>
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_REDIRECTURI: https://allure.local/login/oauth2/code/azure
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_AZURE_SCOPE: [openid, email, profile] #select preferred
      SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_AZURE_ISSUERURI: <OpenID Connect metadata>
      SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_AZURE_USERNAMEATTRIBUTE: email
<snip>

To update Allure TestOps for the usage of Azure AD as identity provider you need to perform the same actions you do for updating Allure TestOps using docker-compose commands. , i.e. 1) down, 2) then start the application using up -d

Deployment via packages

Update properties file /opt/allure-ee/gateway/conf/allure-gateway.properties with the following string:

spring.security.oauth2.client.registration.azure.clientName=azure
spring.security.oauth2.client.registration.azure.clientId=<Application (client) ID>
spring.security.oauth2.client.registration.azure.clientSecret=<Client secrets (Token)>
spring.security.oauth2.client.registration.azure.redirectUri=https://<allure>/login/oauth2/code/azure
spring.security.oauth2.client.registration.azure.scope=[openid, email, profile]
spring.security.oauth2.client.provider.azure.issuerUri=<OpenID Connect metadata>
spring.security.oauth2.client.provider.azure.usernameAttribute=email

Setting the default authentication way

When you’ve updated the settings and these were successfully applied, you need to check the authentication by trying to log in using the following URL:

http://allure.local/login/oauth2,

Your URL will differ, you remember, right? Only this part you need to take for test from this guide: /login/oauth2

When you’ve successfully tested the authentication, you can switch to OpenID as main authentication method.

Deployment in Kubernetes

uaa:
<snip>
  env:
    open:
      ALLURE_LOGIN_PRIMARY:oauth2
<snip>

Then application configuration be updated using Helm commands.

Deployment via docker-compose

  uaa:
  <snip>
    environment:
      ALLURE_LOGIN_PRIMARY: oauth2

Then application should be stopped to apply the configuration changes and then started again.

Deployment via packages

Update properties file /opt/allure-ee/uaa/conf/allure-uaa.properties with the following string:

allure.login.primary=oauth2

Setting the default role for new user registering via OpenID/AzureAD

Why

If no additional setting made all new users will have ROLE_USER by default and will consume 1 license.

What

To prevent new users consuming the licenses you need to define the default role for them as ROLE_AUDITOR, when they register in the system using openid/azuread. This will ensure they will have read only access by default and won’t consume any licenses in the system.

How

The following parameter should be set for UAA service: ALLURE_LOGIN_OPENID_DEFAULTROLE

For docker-compose and Kubernetes deployment

ALLURE_LOGIN_OPENID_DEFAULTROLE: ROLE_AUDITOR

For the deployment using packages

allure.login.openid.defaultRole: ROLE_AUDITOR