Configure the OpenEdge Authentication Gateway using the sts.properties file based on the OpenEdge domains and the OAuth2 server token requirements.

Add OpenEdge domains

Every user must belong to a defined OpenEdge domain. Edit the domains.json file to configure new domains.

Configure domain
  1. Edit instance-name/webapps/ROOT/WEB-INF/config/domains.json by replacing the instance-name with the OpenEdge Authentication Gateway server name.
  2. Add the progress.com domain and set the enabled value to true.
  3. Under exchange, set enabled to true.
  4. Set authProvider to anonymous.
        "version": "1.0.0",
    "domains": [
	    	{
        "name" : "progress.com",
        "enabled" : true,
        "description" : "JWT token authentication",
        "actions" : {
            "authenticate" : {
            	"enabled" : false,
            	"options" : ""
            },
            "exchange" : {
            	"enabled" : true,
            	"options" : ""
            },
            "sso" : {
            	"enabled" : false,
            	"options" : ""
            },
            "refresh" : {
            	"enabled" : false,
            	"options" : ""
            }
       },
       "options" : "",
       "authProvider" : "anonymous",
       "policyProvider" : "",
       "events" : {
            "provider" : "",
            "groups" : { }
       }
    }
}
    Note: When exchange is enabled for your domain, the OpenEdge Authentication Gateway identifies the inbound token as an OAuth2 token for your domain.
  5. Save the file.

For more information about domains, see Configure domains.

Configure OpenEdge domain access codes

Each new domain must have a domain name and passwordkey access code. The codes are secured by adding them to a keystore using a plain text file and the gendomreg command.

  1. Edit the instance-name/webapps/ROOT/WEB-INF/config/domainsks.csv file to include all new domains in the domain.json file. 
    ....

,
oests.server,passwordkey,
progress.com,mypassword
    Note: Replace progress.com and mypassword with your domain and secure encrypted password.
  2. Save the file.
  3. Generate the keystore using gendomreg.
    gendomreg domainsks.csv domains.keystore
    Note: Remember to remove the CSV file from the instance directory and store it in a secure location after generating the keystore because the CSV file contains passwords.

    In a keystore, the domain access codes are more secure than in a plain text CSV file.

    For more information about domain access codes, see Configure domain access codes.

Set the keystore properties

Configure the OpenEdge Authentication Gateway to use the encrypted keys used to lock the JWT token.

  1. Identify the keystore type. This example uses the most common keystore, JWK or JSON Web Key. It represents a cryptographic key and requires a URL that points to a JWK set of public keys or digital certificates downloaded from the authorization server.
  2. Edit the keystore type and any related properties in the instance/webapps/ROOT/WEB-INF/config/sts.properties file to use the jwk. Set the related properties. 
    URL for the JWK of the authorization server
jwtToken.keystore.path=${Catalina.base}/conf/tomcat-keystore.p12
    Note: Choosing a different type requires different property changes.
  3. Save the file.

For more information about JWT keystores, see Configure an OAuth2 keystore .

For more information about managing keys and certificates, see Manage OpenEdge Keys and Certificates .

Configure validation of bearer token claims

The OpenEdge Authentication Gateway security service must validate the bearer token claims. Validation can occur locally or remotely. When configuring, you must decide where to validate the token:
  • Local validation—Validate on the OpenEdge Authentication Gateway server.
  • Remote validation—Validate on the OAuth2 authorization server.

This example uses remote validation.

Local validation

The bearer token must pass the payload requirements, data integrity signature, and (optionally) expiration. The client’s request is rejected, if any checks fail.

To validate the token claims:

  1. Identify and then set the tokenServices property value. This example uses JWT, which provides the jwt token.
  2. Edit oeauthserver/webapps/webapp-name/WEB-INF/config/sts.properties to set oauth2.resSvc.tokenServices to jwt.
    oauth2.resSvc.tokenServices=jwt
    Note: This value is either the jwt or oauth2 access token validation process. If you use Configure OAuth2 or JWT Token Validation Servicesoauth2, you must set oauth2.resSvc.clientId to the value provided by your authorization provider.
  3. Save the file.

For more information about oauth2.resSvc.tokenServices, see ../../pas-for-openedge-management/page/Configure-OAuth2-or-JWT-Token-Validation-Services.html.

Remote validation

When using opaque tokens, the OpenEdge Authentication Gateway cannot access the content of the token. Opaque tokens require setting properties to enable remote validation.

  1. Edit oeauthserver-dir/webapps/webapp-name/WEB-INF/config/sts.properties.
  2. Set the oauth2 properties for remote validation. 
    oauth2.opaqueToken.instrospectionUri=http://hostname:port/introspect
oauth2.opaqueToken.clientSecret=stringClientSecret
    Note: Configure OAuth2 or JWT Token ValidationSetting instrospectionUri overrides the local validation properties. Use the genpassword utility to encrypt the stringClientSecret on production systems.
  3. Save the file.

Configure token exchange

During the validation, token information is automatically stored in a client-principal object. The access token fields are automatically added to the client-principal object. For configurations using authorization servers that support OpenID Connect (OIDC), you can configure the OpenEdge Authentication Gateway to collect additional user information and store it in the client-principal.

Add access tokens values to a client-principal object

By default, the OpenEdge Authentication Gateway converts the access token to a client-principal object. The following table provides the mapping of self-contained JWT fields to OpenEdge client-principal attributes:

JWT field Client-principal attribute
sub (by configuration) USER-ID and DOMAIN-NAME
exp LOGIN-EXPIRATION-TIMESTAMP
scope (by configuration) ROLES
misc (by configuration) Converts to user-defined properties.
Note: Any misc name value pairs are converted to additional user-defined properties on the client-principal.

For more information about token conversion, see Configure JWT/OAuth2 self-contained access token conversion to an OpenEdge client-principal.

Add identity token data to the client-principal

If the authorization server supports OpenID Connect (OIDC), then set the OAuth2 properties to collect and add identity token details to the client-principal object.

  1. Set the OIDC related properties.
    OEClientPrincipalFilter.userinfo.servicetype=oidc
OEClientPrincipalFilter.userinfo.url=http://authorizationServer:port/userinfo
    Note: PAS for OpenEdge uses oauth2.resSvc.clientId to request client information from the authorization server.