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

  1. 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.).

  2. 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. 

Default contents of the oidc.json File
{
"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:

AttributeValueDescription
enabledbooleanEnables or disables OIDC authentication. Default is false.
issuerUri stringSpecifies 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:

["openid", "profile", "email"], 

claimMappings objectRepresents information about users.

username stringSpecifies the value mapped to the username claimed in OIDC. Default is preferred_username.

firstName stringSpecifies the value mapped to the first name claimed in OIDC. Default is given_name

lastName stringSpecifies the value mapped to the last name claimed in OIDC. Default is family_name

email stringSpecifies the value mapped to the email claimed in OIDC. Default is email. 
adminUsers array of stringsSpecifies 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.

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": 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.

  • No labels