Authentication with OpenID using Okta

Users authentication with OpenID and Okta

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

Integration of Allure TestOps and Okta

Given

  1. Allure TestOps is deployed and accessible on http://allure.local, your URLs will be different.
  2. Okta’s URL for your organization is deployed and accessible on https://org-admin.okta.com, your URLs will be different.

Creation of the new application in Okta

  1. Open your organization’s URL https://org-admin.okta.com
  2. Jump to Applications > Applications

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

  1. Click Create App Integration and check OpenID connect and Web Application

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

  1. Fill the following fields as in the example below:
    • App integration name: Allure TestOps
    • Sign-in redirect URIs: https://allure-local/login/oauth2/code/okta (you remember, your URLs will differ?)
    • Controlled access: Allow everyone in your organization to access.
  2. Save the changes.

Results

When you have finalized the settings for the application integration, you’ll have the following configuration parameters, you are going to use to configure Allure TestOps:

  1. Client ID
  2. Client secret
  3. Okta domain

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

Configuring Allure TestOps

To integrate Allure TestOps with Okta you need to pass the environment variables to gateway service.

See below for the deployment specific examples.

Deployment in Kubernetes

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

version: 3.185.3 # always check the most recent version in the release notes
<snip>
gateway:
  env:
    open:
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_CLIENTNAME: Okta
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_CLIENTID: <Client ID>
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_REDIRECTURI: https://allure-local/login/oauth2/code/okta
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_SCOPE: openid,email,profile
      SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OKTA_USERNAMEATTRIBUTE: email
      SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OKTA_ISSUERURI: https://<Okta domain>
    secret:
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_CLIENTSECRET: <Client secret>
<snip>

Now you need to update your Allure TestOps configuration as usual for Kubernetes installation using Helm’s commands.

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_OKTA_CLIENTNAME: Okta
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_CLIENTID: <Client ID>
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_CLIENTSECRET: <Client secret>
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_REDIRECTURI: https://<allure>/login/oauth2/code/okta
      SPRING_SECURITY_OAUTH2_CLIENT_REGISTRATION_OKTA_SCOPE: openid,email,profile
      SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OKTA_ISSUERURI: https://<Okta domain>
      SPRING_SECURITY_OAUTH2_CLIENT_PROVIDER_OKTA_USERNAMEATTRIBUTE: email
<snip>

To update Allure TestOps for the usage of Okta 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.okta.clientName=Okta
spring.security.oauth2.client.registration.okta.clientId=<Client ID>
spring.security.oauth2.client.registration.okta.clientSecret=<Client secret>
spring.security.oauth2.client.registration.okta.redirectUri=https://<allure>/login/oauth2/code/okta
spring.security.oauth2.client.registration.okta.scope=openid,email,profile
spring.security.oauth2.client.provider.okta.issuerUri=<https://<Okta domain>
spring.security.oauth2.client.provider.okta.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: OPENID
<snip>

Deployment via docker-compose

  uaa:
  <snip>
    environment:
      ALLURE_LOGIN_PRIMARY: OPENID

Deployment via packages

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

allure.login.primary=openid

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

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, when they register in the system using OpenID/Okta

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