You can configure CTP 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
Configuration is required in User Administration, as well as in the OIDC server.
OIDC Server Configuration
If you have not already done so, register User Administration with your OpenID Connect identity provider. You can get the values for the attributes used in the oidc.json file from the authorization server (Keycloak, connect2id, etc.).
Register the necessary redirect URIs so that the OIDC server knows where to send the user after authentication. The
<ctp>/em/login/oauth2/code/ctp
URI should be registered.
CTP Configuration
Open the oidc.json file located in the tomcat/webapps/em/config
directory to configure the OIDC provider properties used by CTP.
{ "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
. The following table describes all attributes in the file:
Attribute | Value | Description | |
---|---|---|---|
enabled | boolean | Enables or disables OIDC authentication. Default is false . | |
issuerUri | string | Specifies the value of the issureUri parameter is the URI of the Authorization Server. The URI will be appended with /.well-known/openid-configuration to build the complete discovery endpoint when file is processed. | |
clientId | string | Specifies the public identifier registered for CTP with your OIDC provider. | |
clientSecret | string | Specifies the client secret for CTP. | |
scopes | array of strings | Defines the set of user information that the OIDC server will provide to the client. CTP primarily uses values specified in the array to gain access to the user claims. The following array is defined by default:
| |
claimMappings | object | Represents information about users. | |
username | string | Specifies the value mapped to the username claimed in OIDC. Default is preferred_username . | |
firstName | string | Specifies the value mapped to the first name claimed in OIDC. Default is given_name . | |
lastName | string | Specifies the value mapped to the last name claimed in OIDC. Default is family_name . | |
email | string | Specifies the value mapped to the email claimed in OIDC. Default is email. | |
adminUsers | array of strings | Specifies existing users in your organization that should be granted administrator privileges upon logging in. |
Save your changes and restart CTP after configuring the file.
When you go to the CTP 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 CTP.
CTP Security XML File Configuration
CTP's applicationContext-security.xml file contains the necessary elements to enable OAuth 2.0 authentication, though they are disabled by default in favor of form login authentication. You will need to uncomment the oauth2-login elements and comment out the form-login elements.
Uncomment the oauth2-login element
Uncomment the lines shown below to enable OAuth 2.0 authentication:
<!-- <oauth2-login client-registration-repository-ref="clientRegistrationRepository" authentication-success-handler-ref="oidcSuccessHandler" oidc-user-service-ref="oidcUserService" login-page="/oauth2" ></oauth2-login>-->
Comment out the form-login element
Comment out the lines shown below to disable form login authentication:
<form-login login-processing-url="/resources/j_spring_security_check" login-page="/welcome" authentication-failure-handler-ref="failureHandler" authentication-success-handler-ref="userAuthenticationSuccessHandler" username-parameter="j_username" password-parameter="j_password" />
Uncomment the oauth2-resource-server elements to enable OAuth2 for API
Uncomment out the lines shown below if you want to enable OAuth2 for API usage:
<!-- <http pattern="/api/**"> <oauth2-resource-server entry-point-ref="apiEntryPoint"><opaque-token introspector-ref="opaqueTokenIntrospector"/></oauth2-resource-server> <http-basic entry-point-ref="apiEntryPoint"/> <csrf request-matcher-ref="csrfSecurityRequestMatcher"/> </http> <http pattern="/services/**"> <oauth2-resource-server entry-point-ref="apiEntryPoint"><opaque-token introspector-ref="opaqueTokenIntrospector"/></oauth2-resource-server> <http-basic entry-point-ref="apiEntryPoint"/> <csrf request-matcher-ref="csrfSecurityRequestMatcher"/> </http> <http pattern="/tdm/api/v*/**"> <oauth2-resource-server entry-point-ref="apiEntryPoint"><opaque-token introspector-ref="opaqueTokenIntrospector"/></oauth2-resource-server> <http-basic entry-point-ref="apiEntryPoint"/> <csrf request-matcher-ref="csrfSecurityRequestMatcher"/> </http> -->
Web Archive (WAR) and CLI Configuration
If you are using the soavirt.war or soatestcli, configure the settings in your .properties
file as described below according to the authentication type you are using. The default is device code.
For device code authentication:
oidc.enabled=true
oidc.cli.mode=devicecode
oidc.issuer.uri=[URI of the OpenID Connect server]
oidc.client.id=[ID provided by the OpenID Connect server]
oidc.devicecode.token.file=[path to the custom token file containing user authentication information]
When "devicecode" mode is enabled, users are given a URL and device code to use to authenticate when soavirt.war or soatestcli is started. If the authentication is successful, the information is saved to a token file (the path to the file is stored in the oidc.devicecode.token.file
setting) to be reused. If the information saved in the file becomes invalid, the user will need to authenticate again.
For certificate authentication:
oidc.enabled=true
oidc.cli.mode=certificate
oidc.issuer.uri=[URI of the OpenID Connect server]
oidc.client.id=[ID provided by the OpenID Connect server]
oidc.client.secret=[password provided by OpenID Connect server]
oidc.keystore=[path to the keystore file that stores the certificate to authenticate the user on the OpenID Connect server]
oidc.keystore.password=[password to the keystore file; see note below.]
We highly recommend that you use an encoded password for oidc.keystore.password
. You can encode your password by running a command line instance of SOAtest with the -encodepass
flag. The command line tool will generate an encoded string that you can use in the configuration file.
Example Configurations
The following examples are intended to help you understand how to connect CTP 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. - The following redirect URIs should be registered:
host:port/*
In this example, demo
is the name of the realm and two administrator users (admin1
and admin2
) will be created.
"enabled": false, "issuerUri": "https://host:8095/auth/realms/demo/", "clientId": "pstsec", "clientSecret": "4d35ef23-aec5-44d7-9c59-18092bd619e8", "scopes": ["opened","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.
The following example demonstrates how to configure OpenID Connect for Google. In this example, two administrator users (admin1
and admin2
) will be created.
"enabled": false, "issuerUri": "https://accounts.google.com", "clientId": "<clientId-from-google>", "clientSecret": "<clientSecret-from-google>", "scopes": ["opened","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.
Connect2id
The following example demonstrates how to configure OpenID Connect for connect2id. Users must access User Administration 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": false, "issuerUri": "https://host:port/c2id", "clientId": "<clientId-from-c2id>", "clientSecret": "<clientSecret-from-c2id>", "scopes": ["opened","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 CTP 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.
Azure Active Directory
The following configurations are prerequisites for configuring OpenID Connect for Azure Active Directory:
- The access token from Azure should include user information available that can also be retrieved from the Azure userinfo API endpoint.
- The following redirect URIs should be registered:
https://host:port/em/oauth2/login/code/ctp
.
In this example two administrator users (admin1
and admin2
) will be created.
"enabled": false, "issuerUri": "https://login.microsoftonline.com/<tenantId-from-azure>/2.0", "clientId": "<clientId-from-azure>", "clientSecret": "<clientSecret-from-azure>", "scopes": ["opened","profile","email"], "claimMappings": { "username": "name", "firstName": "given_name", "lastName": "family_name", "email": "email" } "adminUsers": ["admin1","admin2"]
Refer to the Azure Active Directory documentation for additional information.