Configuring OpenID Connect

You can configure DTP to accept authentication from an OpenID Connect identity provider. This enables you to manage user authentication outside of Parasoft. Support for OpenID Connect is disabled by default.

In this section:

Basic Configuration

Complete OIDC Server Configuration, then complete DTP Configuration.

OIDC Server Configuration

1. If you have not already done so, register DTP with your OpenID Connect identity provider.
   • issuerUri
   • clientId
   • clientSecret
2. Register the necessary redirect URIs so that the OIDC server knows where to send the user after authentication. The following URIs should be registered:
   

   Required

   • http(s)://<HOST>:<PORT>/pst/login/oauth2/code/dtp
   • http(s)://<HOST>:<PORT>/pstsec/login/oauth2/code/dtp (User Administration)
   • http(s)://<HOST>:<PORT>/grs/login/oauth2/code/dtp (Required for Report Center/Enterprise Pack)

   Optional (The following redirect URIs are optional and only need to be registered to enable log in directly through individual applications.)

   • http(s)://<HOST>:<PORT>/licenseserver/login/oauth2/code/dtp (License Server)
   • http(s)://<DATA_COLLECTOR_URL>/login/oauth2/code/dtp (Data Collector)

DTP Configuration

Open the oidc.json file located in the <DTP_DATA_DIR>/conf directory to configure the OIDC provider properties used by DTP.

{
"enabled": false,
"issuerUri": "your issuer uri",
"clientId": "your client id",
"clientSecret": "your client secret",
"scopes": ["openid", "profile", "email"],
"claimMappings":
	{ 
		"username": "preferred_username", 
		"firstName": "given_name", 
		"lastName": "family_name", 
		"email": "email" 
	},
"adminUsers": []
}

 The oidc.json file should be configured prior to the admin users logging in for the first time, otherwise the users will be added to the database without the permissions necessary for performing administrative functions. 

All attributes in the file are required when the enabled element is set to true. There are two ways to define the client secret attribute, either encrypted or not. The unencrypted version (clientSecret) is used by default, but you can exchange it for the encrypted version (encryptedClientSecret) if you wish. The following table describes all elements in the file:

Save your changes and restart DTP services after configuring the file.

When you go to the DTP login page, you will be redirected to the OpenID Connect authentication interface. After specifying your credentials, you will be logged in and redirected back to DTP. If there are errors during login or with the configuration, you will be redirected to an error page with more details.

Advanced Configuration

Enabling Basic Authentication for Automation (CLI) Users

There are two ways that automation users can authenticate with DTP via OIDC:

• Device code authentication
• Certification authentication

Your organization may want a simpler way for automation users to authenticate with DTP.

 You can do this by enabling basic authentication for automation users. To do so:

1. Create automation user(s) in User Administration with a username and password.
2. Enable basic authentication by adding "enableBasicAuth": true to the oidc.json file.

Restart DTP to apply your changes.

When basic authentication is enabled:

• DTP UI will still enforce OIDC authentication
• DTP REST API will accept both OIDC and basic authentication
  • Automation users will call DTP REST API using basic authentication

Enabling Client Credentials Flow

To enable client credentials flow, for example for inbound connections from Parasoft CTP, add the following clientCredentials element after adminUsers element to the oidc.json file:

"clientCredentials": {
        "enabled" : true,
        "clientId" : "client id",
        "clientSecret" : "client secret",
        "scopes" : ["openid"],
        "claimMappings" : {
            "username": "preferred_username",
        }
}

The client credentials flow gets a JWT access token from the OAuth server to use for authentication. Specify which claim within the token will be used as the username and, if necessary, add a corresponding user to DTP so that username matches a valid DTP user. Depending on the OAuth server (for example, with Keycloak or EntraId) the claims for the access token are configurable. If you are not sure what claims your token has, it may be possible to request the token using a curl command as shown below and then inspect the token content to find out.

curl --request POST \
  --url 'https://{yourDomain}/oauth/token' \
  --header 'content-type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data client_id=YOUR_CLIENT_ID \
  --data client_secret=YOUR_CLIENT_SECRET \

Example Configurations

The following examples are intended to help you understand how to connect DTP to your identity access management system. Refer to the documentation for your software for implementation details.

Keycloak

The following configurations are prerequisites for configuring OpenID Connect for Keycloak as described in this example:

• Keycloak should be using RS256 as the default signature algorithm.
• The access token from Keycloak should include user information available that can also be retrieved from the Keycloak userinfo API endpoint.

In this example, demo is the name of the realm, and two administrator users (admin1 and admin2) will be created.

"enabled": true,
"issuerUri": "https://host:8095/auth/realms/demo/",
"clientId": "pstsec",
"clientSecret": "4d35ef23-aec5-44d7-9c59-18092bd619e8",
"scopes": ["openid","profile","email"],
"claimMappings":
	{ 
		"username": "preferred_name", 
		"firstName": "given_name", 
		"lastName": "family_name", 
		"email": "email" 
	}
"adminUsers": ["admin1","admin2"]

Refer to the Keycloak documentation for additional information.

Azure (Microsoft Entra ID)

The following example demonstrates how to configure OpenID Connect for Azure. In this example, two administrator users ([email protected] and [email protected]) will be created.

{
    "enabled": true,
    "issuerUri": "https://login.microsoftonline.com/<tenantId>/v2.0",
    "clientId": "<clientId-from-Azure>",
    "clientSecret": "<clientSecret-from-Azure>",
    "scopes": ["openid", "profile", "email"],
    "claimMappings": {
        "username": "email",
        "firstName": "given_name",
        "lastName": "family_name",
        "email": "email"
    },
    "adminUsers": [
        "[email protected]",
        "[email protected]"
    ]
} 

The claimMappings uses fields from the response to https://graph.microsoft.com/oidc/userinfo, which contains a limited set of fields.  The following contains an example response for the user with the email address [email protected].

{
  "sub": "<unique value for user>",
  "name": "Jane Jones",
  "given_name": "Jane",
  "family_name": "Jones",
  "picture": "https://graph.microsoft.com/v1.0/me/photo/$value",
  "email": "[email protected]"
} 

Refer to Microsoft's documentation for additional information.

Connect2id

The following example demonstrates how to configure OpenID Connect for connect2id. Users must access DTP over HTTPS when using connect2id as the OpenID Connect provider.In this example, c2id is the name of the realm. Two administrator users (admin1 and admin2) will be created. 

"enabled": true,
"issuerUri": "https://host:port/c2id",
"clientId": "<clientId-from-c2id>",
"clientSecret": "<clientSecret-from-c2id>",
"scopes": ["openid","profile","email"],
"claimMappings":
	{ 
		"username": "sub", 
		"firstName": "given_name", 
		"lastName": "family_name", 
		"email": "email" 
	}
"adminUsers": ["admin1","admin2"] 

Refer to the connect2id documentation for additional information.

Known Limitations

The first time you log into DTP through connect2id, you may receive an "Invalid Request" error. To resolve the error, use a different browser or clear the cache of your current browser. 

Google

The following example demonstrates how to configure OpenID Connect for Google. In this example, two administrator users (admin1 and admin2) will be created.

"enabled": true,
"issuerUri": "https://accounts.google.com",
"clientId": "<clientId-from-google>",
"clientSecret": "<clientSecret-from-google>",
"scopes": ["openid","profile","email"],
"claimMappings":
	{ 
		"username": "given_name", 
		"firstName": "given_name", 
		"lastName": "family_name", 
		"email": "email" 
	}
"adminUsers": ["admin1","admin2"] 

Refer to Google's documentation for additional information. 

Logout Configuration

DTP uses end_session_endpoint from the OIDC issuer to log out the user from the OIDC server. This property must be defined in the <OIDC_ISSUER_URL>/.well-known/openid-configuration payload.The OIDC Backchannel Logout URI for DTP is <DTP_INSTALL>/pstsec/logout/connect/back-channel/dtp. The logout token submitted to this URI must include a session ID (SID) claim.

Using APIs in OpenID Connect Mode

When DTP is in OpenID Connect mode, you cannot access either DTP or Enterprise Pack APIs using basic authentication.Instead, you must pass an access token to the API endpoint in the request header using the Authorization property. The token is passed using the following format:

Authorization: Bearer <access token>

Refer to your identity access management software for information on how to obtain an access token.

You must pass the token for every API call, regardless of the method. In the following example, a token with the value 1234567890 is passed to the DTP build API endpoint.

curl -X GET -H "Authorization: Bearer 1234567890" http://dtp.host.com/grs/api/v1.7/builds?limit=1000&offset=0