PAS for OpenEdge Support for JWT and OAuth 2.

- Samples -

Version 1.0
November 21, 2017

Copyright © 2017 Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.
 2

TABLE OF CONTENTS
INTRODUCTION ............................................................................................................................................. 3
REQUIREMENTS TO RUN THE SAMPLES .............................................................................................................. 4
OAUTH 2.0 TESTING BY CONFIGURING HMAC ALGORITHM ................................................................................. 8
OAUTH 2.0 TESTING WITH GOOGLE ............................................................................................................... 15
Google OAuth 2.0 Configuration ........................................................................................................ 15
Google OAuth 2.0 configuration in PAS for OpenEdge....................................................................... 23
OAUTH 2.0 TESTING WITH AWS COGNITO ..................................................................................................... 29

Progress Software Corporation

 3

Introduction
Beginning in Progress OpenEdge 11.7.2, Progress Application Server (PAS) for OpenEdge Spring
Security includes support for validating and using an OAuth 2.0 standard's Resource Server
JSON Web Tokens (JWTs) and custom-generated JWTs. The JWT support provided by the Spring
Security layer validates an OAuth 2.0 self-contained (aka ID Token) claims fields and signature,
which if successful will result in the transformation of the JWT into a sealed Client Principal that
is passed to your ABL business application on each request.

This document and corresponding samples is provided to help you understand how to configure
Spring Security validation of OAuth 2.0 self-contained & JWTs, and how an OpenEdge Client
Principal can be generated that your ABL application can use. These sample cannot present all
possible use cases and their configuration, but focuses instead on typical use cases.
The goals of this document and samples is for you to:

1. Learn the fundamentals of how Spring Security OAuth 2.0 & JWT support provides your
ABL application with a means of integrating with other non-OpenEdge services in a
single security model using shared user login identities.
2. Define which types of OAuth 2.0 and JWT tokens can be used to access an OpenEdge
ABL application, and the required list of claim fields.
3. Understand the primary types of Spring Security OAuth 2.0 & JWT configurations used
for validating token claims and signatures.
4. Learn how to configure the Spring Security OAuth 2.0 & JWT token conversion to a
Client Principal that can be used by your ABL application, other OpenEdge application
servers, and OpenEdge databases.
5. Gain exposure to some free tools that can be used to generate, validate, and test tokens
that can be passed to PAS for OpenEdge for authentication & authorization.
• Generate and validate tokens for Hash-based Message Authentication Code
(HMAC) and RSA Algorithms.
• Social Authentication Providers like Google.
• Commercial Authentication Providers like Amazon Web Services (AWS) Cognito.

Before you begin, it will help if you read the OAuth 2.0 & JWT technology overview in the
OpenEdge documentation. This will familiarize you with terms and basic functionality. This
sample assumes you have a basic understanding before beginning.

The following OAuth 2.0 & JWT features are not supported in PAS for OpenEdge Spring
Security:
• OAuth 2.0 Authorization Server for converting authorization tokens for Access Tokens.
• JWTs, such as an OAuth 2.0 Random Access Token, that do not contain a user-id &
scopes/roles information necessary for creating a Client Principal that allows access to
OpenEdge database and other security features.

Progress Software Corporation

 4

• JWT creation with full JWS HMAC, RSA, and Elliptical Curve signatures.
• JSON Web Key (JWK) sets that contain a digital certificate with an embedded x5c
character (limitation).

Requirements to run the Samples

S.NO Requirements
1. Progress OpenEdge 11.7.2 with Progress Developer Studio for OpenEdge
installed.
2. Node.js (at least 6.10.2 version) - optional

The latest version of node.js can be downloaded from –

https://nodejs.org/en/download/

After successful installation, you should have node.js and Node Package
Manager (NPM) installed. Post installation, verify if node.js is installed
correctly by running the below command from the command prompt.
node -v

3. Chrome Browser

The JavaScript samples provided were tested in Chrome, so we suggest you

download Chrome if not available to test these samples.

4. POSTMAN REST Client

For running raw HTTP requests, we have used POSTMAN as a Client. It comes
with Chrome as a plug-in, but in case you want to download it as application
then you can do that from here:

https://www.getpostman.com/

Alternatively, you can use – cURL, ABL HTTP Client etc.

5. Notepad++

Or any text-editor that shows line numbers.

Download OAuth2Samples.zip and unzip it to the %WRKDIR% (C:\OpenEdge\WRK by default).

Progress Software Corporation

 5

The archive has the following artifacts:

1. gentoken.js - nodeJS script.

2. IdmStartup.p, IdmActivate.p & dumpCP.p – event procedures.
3. .properties file – oeablSecurity.properties file for HMAC, RSA, Google and AWS Cognito.
4. oauth – HTML/JavaScript login Application.
5. outh2reg.csv – domain registry file used in PAS for OpenEdge Spring Security.
6. domains.json – domain registry file used by the event procedures.

Generating JWT token using nodeJS libraries

JSON Web Token (JWT) is a self-contained way for securely transmitting information between
the Client Application and the service provider as a JSON object, as they are digitally signed.
JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair
using RSA.

For the samples provided in this document, we are providing HMAC and RSA tokens that never
expire.

In case you want to generate your own token, then please follow the following steps.

To generate the JWT tokens with these two algorithms, we are using open-source tool nodeJS
and few of its libraries.

To install the nodeJS libraries to generate token, run the below npm commands.

➢ npm install fs (file I/O library)

➢ npm install jsonwebtoken (library to generate and validate JWT tokens)

If you would like to read more details about JSONWebToken node library then you can find it
here - https://github.com/auth0/node-jsonwebtoken.

Using these libraries, we have written ‘gentoken.js’ script that generates tokens based on a
selected algorithm, and if required we can also validate the tokens.

Usage:

➢ node gentoken.js <Algorithm>

Algorithm can be – HS256, HS384, HS512, RS256, RS384 and RS512

For example, to generate a token in HS256 format then run the ‘gentoken.js’ as below
➢ node gentoken.js HS256

Progress Software Corporation

 6

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiAiNzk2NWJiYTQtYjY1ZC00MjEyLWFkYzctNmJkMjdlZmYx
ODBlIiwidG9rZW5fdXNlIjogImFjY2VzcyIsInNjb3BlIjogIlBTQ1VzZXIiLCJpc3MiOiAiaHR0cHM6
Ly9ub2RlanNKV1QiLCJjbGllbnRfaWQiOiAiMTIzNDU2Nzg5IiwiaWF0IjogMTUwODE2NDY1
MCwiZXhwIjogMTUwODE2NDgwMCwianRpIjogInM5MHU0N3I5Mm9vbzB3b2s4MHNrb29
ja3N3b3d3ayIsImF1ZCI6ICJwYXNvZS5vcGVuZWRnZS5wcm9ncmVzcy11c2Vycy5jb20iLCJlb
WFpbCI6ICJpc3llZEBwcm9ncmVzcy5jb20iLCJ1c2VybmFtZSI6ICJpc3llZCJ9.nRYeqaQk2BhFzP
5bUxlk2Xl1kgsXfGzE_BS_1m1AWh8

We have added color coding to the token to highlight that the JWT token consists of three
parts separated by (.) dots.

1. Header - definition of hashing algorithm and type of the token

2. Payload - claims that have the information about identity and any additional
information
3. Signature - to create the signature part you must take the encoded header, the
encoded payload, a secret, the algorithm specified in the header, and sign that.

data = base64urlEncode( header ) + “.” + base64urlEncode( payload )

signature = Hash( data, secret );

The secret is the signature stored in the server, this way the server will be able to
verify existing tokens and sign new ones.

Progress Software Corporation

 7

If we decode the token online (https://jwt.io/), then it should show it as below.

In the script ‘gentoken.js’, we are signing HS256 JWT token with secret ‘password’. If we use the
secret value then the signature should be validated correctly.

Progress Software Corporation

 8

Now that we know how the tokens are generated and validated, we will configure PAS for
OpenEdge to validate HMAC-based JWT tokens and generate an OpenEdge Client Principal.

OAuth 2.0 testing by configuring HMAC Algorithm

We shall be using a newly created oepas1 instance of 11.7.2 for configuring and testing OAuth
2.0 on PAS for OpenEdge.

1. As you may know, starting with 11.7, all of the Spring security configuration files are
available in the oeablSecurity.properties file instead of multiple XML files, for better
management. Take a backup of the default oeablSecurity.properties file in the ROOT
oeabl Web Application of the oepas1 PAS for OpenEdge Instance.

proenv> move %WRKDIR%\oepas1\webapps\ROOT\WEB-INF\oeablSecurity.properties

oeablSecurity.properties.backup

2. Copy HMAC.properties to oepas1\webapps\ROOT\WEB-INF\ as

oeablSecurity.properties file.

proenv> copy HMAC.properties oepas1\webapps\ROOT\WEB-INF\oeablSecurity-properties

The HMAC.properties are listed in the following table.

Table 1 - oeablSecurity.properties for OAuth 2.0 HMAC Algorithm

Client.login.model=oauth2 Enables OAuth 2.0 for the ROOT Web Application

OEClientPrincipalFilter.domain=JWTdomain When we pass a username/password or a Client Principal

token that has user@domain then the domain is picked
automatically. But when the username does not contain any
domain or with JWT token which does not have any context of
domain then we can statically define the domain name. This
domain will be set inside the Client Principal and the key to
seal the client-principal is mapped to the domain in the
registry file.

OEClientPrincipalFilter.registryFile=oauth2reg.bin Registry information of domain-access-codes for the domains.

This file is generated using gendomreg.

gendomreg oauth2reg.csv oauth2reg.bin

Where oauth2reg.csv has the list of the domain and domain-

access-codes in the below format:

<domain1>,<domain-access-code>

Progress Software Corporation

 9

jwtToken.signatureAlg=HS256 Signature Algorithm chosen to validate the JWT token.

jwtToken.macKey=oeph0::76E5F6C1622767 Secret key with which the JWT HMAC tokens will be validated.
68465F02E4D2D1DDCD The value can be either ‘clear-text’ or the one generated using
‘stspwdutil’

jwtToken.keystore.type=mac Type of keystore for validating the JWT signature.

oauth2.resSvc.audience=PAS for The (aud) audience claim that is verified by PAS for OpenEdge
OpenEdge.openedge.progress-users.com JWT process. Every JWT token passed should have audience
claim as configured, else it will be rejected.

oauth2.resSvc.tokenServices=jwt If configured to ‘jwt’ then it will only check the token against
the mackey and signature.

If configured to ‘oauth2’ it will also verify if the JWT token has

standard payload claims (like client-id).

3. Generate a domain registry file from oauth2reg.csv file in %WRKDIR%. Copy the
generated ‘oauth2reg.bin’ to oepas1\conf directory which is the relative path for all the
registry files in PAS for OpenEdge Spring Security.

proenv> gendomreg oauth2reg.csv oauth2reg.bin

4. Create a file named openedge.prop which has the properties that we want to merge
into oepas\conf\openedge.properties. These properties will be used for all the samples
that we are going to execute in this document.

[AppServer.Agent]
sessionActivateProc=IdmActivate.p
sessionStartupProc=IdmStartup.p

[oepas1.ROOT.WEB]
handler1=OpenEdge.Web.PingWebHandler: /_oeping

We added a new WebHandler(PingWebHandler) that comes out of the box with the PAS
for OpenEdge installation in OpenEdge 11.7.2. It can be used as a health check service to
see if the PAS for OpenEdge Instance and the MS-Agent are up and running.

5. Merge openedge.prop properties file with the one that is already available in oepas1
using oeprop.bat.

proenv> cd oepas1\bin
proenv> oeprop.bat -f %WRKDIR%\openedge.prop

Progress Software Corporation

 10

6. Copy the startup and activate procedures to the default PROPATH of the oepas1 PAS for
OpenEdge Instance.

proenv> copy activate.p oepas1\openedge\

proenv> copy IdmStartup.p oepas1\openedge\
proenv> copy dumpCP.p oepas1\openedge\

7. The IdmStartup.p startup procedure is responsible for loading and locking the registry
for each session. The domain registry information is stored in the domains.json file that
is stored in %WRKDIR%.

In domains.json, the domain is in clear-text, but the domain-access-code is encrypted

using the ‘genpassword’ utility which is equivalent to AUDIT-POLICY:ENCRYPT-AUDIT-MAC-
KEY().

8. Start the PAS for OpenEdge Server using pasman PAS for OpenEdgeStart

proenv> pasman PAS for OpenEdgestart -I oepas1 -timeout 100

9. After the PAS for OpenEdge instance has been started successfully, use the below HS256
JWT token or generate your own JWT token using ‘gentoken.js’ by running
node gentoken.js HS256

eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiAiNzk2NWJiYTQtYjY1ZC00MjEyLWFkYzctNmJkMjdlZmY
xODBlIiwidG9rZW5fdXNlIjogImFjY2VzcyIsInNjb3BlIjogIlBTQ1VzZXIiLCJpc3MiOiAiaHR0cH
M6Ly9ub2RlanNKV1QiLCJjbGllbnRfaWQiOiAiMTIzNDU2Nzg5IiwiaWF0IjogMTUwOTIxMD
IyOSwiZXhwIjogMjcwOTIxMDI1OSwianRpIjogIjVobDB0ejU1NDBnODRnZ2Nza2tnb3Njbz
AwMGNjcyIsImF1ZCI6ICJvcGVuZWRnZS5zYW1wbGUifQ.wRaeG3942QHq5z6deffTBRm_F
hL2IJMGepvx0TdN8BI

10. Capture the token that was generated earlier, using Postman Client to perform a HTTP
GET Request to the URL http://localhost:8810/web/_oeping with the below headers and
see that it is executed successfully.

Accept: application/json
Authorization: Bearer <HS256 JWT token>

Progress Software Corporation

 11

11. Spring Security in PAS for OpenEdge validates the JWT token with the provided JWT
configuration in the oeablSecurity.properties file, and then converts the JWT token to a
Client Principal token and seals it based on the Client Principal domain and key values
from the same oeablSecurity.properties file.

If the Client Principal is validated successfully in the activate procedure, it will dump the
Client Principal properties as below in the oepas1.agent.log.

Progress Software Corporation

 12

OAuth 2.0 testing by configuring RSA Algorithm

Unlike HMAC, JWT tokens generated using the RSA Algorithm are signed using a Privacy-
enhanced Electronic Mail (PEM) or Java Key Store (JKS) certificate. In this example, we will use a
PEM file to generate and validate the JWT token for RSA Algorithm.

Before generating JWT tokens, let’s configure OpenSSL and generate public/private key pairs in
PEM format.

JWT tokens can be generated for RS256, RS384 and RS512 algorithms. OpenSSL default
certificates are generated with 1024-bit keypairs. To generate all three algorithms for RSA, we
need to install OpenSSL certificates with 2048-bit keypairs.

12. Generate a RSA private key using 2048-bit keypairs. Enter the passphrase as ‘password’
as we are using the same name while generating tokens in the PAS for OpenEdge
configuration.

proenv>OpenSSL genrsa –des3 –out privatecert.pem 2048

13. Extract the public key from the private key. Enter the same passphrase ‘password’ when
prompted.

proenv>OpenSSL rsa –pubout –in privatecert.pem –out publiccert.pem

Make sure that privarecert.pem and publiccert.pem are generated successfully. The
nodeJS script ‘gentoken.js’ uses privatecert.pem to sign the RSA token.

14. Copy RSA.properties to oepas1\webapps\ROOT\WEB-INF\ as oeablSecurity.properties

file

proenv>copy RSA.properties oepas1\webapps\ROOT\WEB-INF\oeablSecurity.properties

Progress Software Corporation

 13

The RSA.properties are shown in the following table.

Table 2 - oeablSecurity.properties for OAuth 2.0 RSA Algorithm

jwtToken.signatureAlg=RS256
RSA Signature Algorithm chosen to validate the JWT
token.

jwtToken.keystore.type=pem Type of keystore for validating the JWT signature

jwtToken.keystore.path=${catalina.base}/conf/jwtkeys The keystore location where the public key PEM

certificates are located.

jwtToken.keystore.alias=publiccert Name of the public key certificate

oauth2.resSvc.tokenServices=oauth2 <Same as in Table1>

client.login.model=oauth2 <Same as in Table1>

OEClientPrincipalFilter.domain=JWTdomain <Same as in Table1>

OEClientPrincipalFilter.registryFile=oauth2reg.bin <Same as in Table1>

oauth2.resSvc.audience=openedge.sample <Same as in Table1>

For RSA, we are choosing OAuth 2.0 as the JWT token generated as it has all the
mandatory claims required for a OAuth 2.0 token.

15. If we specify oauth2.resSvc.tokenService=oauth2, then in addition to validating the JWT

tokens signature it also verifies standard OAuth 2.0 claims like client-id and authorize
clients that contain only those client-id’s.

To register the client-id for this webapp, we have to enter in the client-id in
oepas1\webapps\ROOT\WEB-INF\oauth2ResSvcClients.cfg.

Progress Software Corporation

 14

16. Copy the public key to the JWT keystore location configured in oeablSecurity.properties.

cd oepas1\conf\jwtkeys
copy %WRKDIR%\publiccert.pem

17. Restart the PAS for OpenEdge Server

Proenv> pasman PAS for OpenEdgestart –I oepas1 -restart

18. After the PAS for OpenEdge instance has been started successfully, use the below RSA
256 JWT token or generate your own JWT token using ‘gentoken.js’ by running
node gentoken.js RS256

eyJhbGciOiJSUzI1NiJ9.eyJzdWIiOiAiNzk2NWJiYTQtYjY1ZC00MjEyLWFkYzctNmJkMjdlZmYx
ODBlIiwidG9rZW5fdXNlIjogImFjY2VzcyIsInNjb3BlIjogIlBTQ1VzZXIiLCJpc3MiOiAiaHR0cHM6
Ly9ub2RlanNKV1QiLCJjbGllbnRfaWQiOiAiMTIzNDU2Nzg5IiwiaWF0IjogMTUwOTIxMDU1O
CwiZXhwIjogMjcwOTIxMDU4OCwianRpIjogImJ5bm1oNmh5NGcwOGs4MG9rMDRjb3M0O
HN3c2c0OCIsImF1ZCI6ICJvcGVuZWRnZS5zYW1wbGUifQ.JyozdRv5MACCnSX_NqYFeZy4k0
f2R1FlkRjF_9r77ezNRnijsBrq-UEciePCfemVJs-
Dfug_n7GKxTEz1gfa_NxCO_rHWqME3kPmlIELcuOAqX89BjnEtRIfvd0W9rK4yKWcsjpzoID
M2OvCrbivm5hoY_raAEJJrgLjgu4c5DKBwHGx9R47yLnKBdZ0zIe83uMJJivIU9dBw2q1-
R6KPqOx7__hsShzNz85RKDrjemCEqyqbDsfRqoZ9L57IFuGoufLwjJ0OCQviLak6isRaVqJinv7
3FNILfHKfwMhO54e1QGkbnaeBCAKvYz1IHQBkU5XuDZ2BVdx7wXRTjZ-kA

19. Capture the token that is generated earlier, using Postman Client perform a HTTP GET
Request to the URL http://localhost:8810/web/_oeping with the below headers and see
that it is executed successfully.

Accept: application/json
Authorization: Bearer <RS256 JWT token>

Progress Software Corporation

 15

12. Successful Client Principal validation should generate all the Client Principal properties.

If you would like to see the validation of the client-id, then change the client-id value in
oauth2ResSvcClients.cfg, restart the server and execute the client request. You should receive a
401 Error.

OAuth 2.0 testing with Google

Google provides support to access its APIs using OAuth 2.0. To do that, you create credentials in
the Google developer console. Documentation for that can be found here:

Google documentation - https://developers.google.com/identity/sign-

in/web/devconsole-project

Google OAuth 2.0 Configuration

In case you would like to see how to do that step-by-step then follow the below instructions.

1. Navigate to below URL in your browser and login to your Google account.

https://console.cloud.google.com/apis/credentials

Progress Software Corporation

 16

2. Client on ‘Create Credentials’ and select ‘API Key’.

Progress Software Corporation

 17

3. A new API key is generated. Click on ‘RESTRICT KEY’.

4. Give a name to this API Key and click ‘Save’.

Progress Software Corporation

 18

5. The ‘API key’ should be available: select ‘OAuth Client ID’.

Progress Software Corporation

 19

6. In ‘Create client ID’ page, select ‘Web application’ and click ‘Create’.

7. Give a name to the Client ID and enter the Authorized JavaScript Origins value as
‘http://localhost:8810’ and click ‘Save’. This way, it will only allow requests from this
URL to Google.

Progress Software Corporation

 20

8. Click on ‘Create’ and it should generate the Client ID.

Progress Software Corporation

 21

You will be using the generated Client-ID and API Key in your Client Application to perform
authentication with Google. Once successfully authenticated, it will return JWT tokens, and
those tokens can be passed to the PAS for OpenEdge server as the user’s identity.

Unlike the JWT tokens that were generated locally using ‘gentoken.js’ for RSA and HMAC
algorithm, most of the online OAuth 2.0 Authentication providers provide access to JWKS (JSON
Web Key Set) so that Resource Servers like PAS for OpenEdge can validate the tokens.

Google’s open-id configuration can be found at - https://accounts.google.com/.well-

known/openid-configuration.

Progress Software Corporation

 22

If you click the jwks_uri, it will provide the list of keys used to validate the JWT token. Out of
this array of keys, only 1 key will be used for each request. The identifier for that is the ‘kid’
value, each JWT token generated by Google will have a ‘kid’ value and corresponding key which
has the same ‘kid’ value in JWKS will be used to validate the JWT token.

Instead of us doing this processing of identifying the ‘key’, we can just provide the JWKS URI in
PAS for OpenEdge and it will validate the JWT token with the given JWKS URI in the PAS for
OpenEdge OAuth 2.0 configuration.

Note: For this example, we are using Google’s People API. So, make sure that it is enabled for
the Google Project you have created in Google developer console. If not, you will be seeing
403 errors.

Progress Software Corporation

 23

The token generated by Google does not have scope and client-ID. If we set the
oauth2.resSvc.tokenServices to ‘oauth2’, then it will look for client-ID in the token. So for
Google, we will configure oauth2.resSvc.tokenServices to ‘jwt’ so that it will validate only the
JWT token against JWKS.

Google OAuth 2.0 configuration in PAS for OpenEdge

1. Copy Google.properties to oepas1\webapps\ROOT\WEB-INF as

oeablSecurity.properties.

proenv> copy Google.properties oepas1\webapps\ROOT\WEB-INF\oeablSecurity-properties

The Google.properties are as below

Table 3-oeablSecurity.properties for OAuth 2.0 Google

jwtToken.keystore.type=jwk Type of JWT token validation mechanism supported

for this configuration.

jwtToken.keystore.jwkurl=https://www.goo Url of the JSON Web Key (JWK) against which the JWT
gleapis.com/OAuth 2.0/v3/certs token will be validated

Progress Software Corporation

 24

oauth2.resSvc.tokenServices=jwt <Same as in Table 1>

client.login.model=oauth2 <Same as in Table 1>

OEClientPrincipalFilter.domain=Google <Same as in Table 1>

OEClientPrincipalFilter.registryFile=oauth2re <Same as in Table 1>

g.bin
oauth2.resSvc.audience=164311755852- <Same as in Table 1>. You get this value from the JWT
oc8r233d4424asdf0sj05bhs6okqajvq7l5.app token obtained from Google.
s.googleusercontent.com

In-order to obtain a JWT token for Google, the Resource Owner (End-User) needs to go through
the authentication process performed by the Authorization Server. To go through that process,
we have written the HTML/javascript OpenID Connect example using Google’s JavaScript API’s
which gives us the ability to authenticate the Resource Owner (End-user) with the Authorization
Server (Google), and validate if the Client (HTML/javascript) is authorized to perform this
action.

2. Create a new OEABL Web App and deploy the client application in the static folder.

Proenv> cd oepas1/bin
Proenv> tcman.bat deploy %DLC%\servers\PAS for OpenEdge\extras\oeabl.war
Proenv> copy %WRKDIR%\oauth %WRKDIR%\oepas1\webapps\oeabl\static\

The folder has a HTML/javascript example that performs OAuth 2.0 with Google and
AWS Cognito User Pool Authentication Providers. By default, it is configured to use the
Client-ID and API key that is been used while testing the samples. While doing the
testing, you must provide your own credentials (Client-ID and API key) as they will not
be available for you.

So, you must change the below lines

oepas1/webapps/oeabl/static/oauth/loginPage.html as per the details provided by your

Authentication Provider.

Google - lines 13, 162, 173

AWS Cognito - lines 70, 71

3. Restart the PAS for OpenEdge server

proenv> pasman PAS for OpenEdgestart –I oepas1 –restart

Progress Software Corporation

 25

4. After the PAS for OpenEdge Instance is up and running, access the URL –

http://localhost:8810/oeabl/static/oauth/loginPage.html

Progress Software Corporation

 26

9. Click on ‘Google Sign-in’ and you will be prompted to enter your Google credentials.
Once you have successfully entered the credentials, you will see a 403 error with
response ‘Insufficient scope’.

If you start the Chrome console, you will see that the token is generated successfully but
it is forbidden by PAS for OpenEdge. This is because the default scope for /web/** URL
pattern is set to ‘PSCUser’ and the Google tokens do not provide any scope.

For OAuth 2.0, we have altogether a different .csv file (oeablSecurityJWT.csv) for URL
Authorization. For JWT, scopes are equivalent to roles, hence oeablSecurityJWT.csv has
authorization based on scopes instead of roles.

10. Open oepas1\webapps\ROOT\WEB-INF\oeablSecurityJWT.csv file to modify the

Authorization URL’s.

Modify the URL Authorization pattern from hasAnyScope(‘PSCUser’) to permitAll() for

the URL pattern /web/** and restart the server.

proenv> pasman PAS for OpenEdgestart –I oepas1 –restart

Notice that we are changing the Authorization URL to permitAll() but we still have a
check of audience in oeablSecurity.properties. The incoming request should contain a
JWT token having an ‘aud’ claim matching to what we have configured in

Progress Software Corporation

 27

oeablSecurity.properties, so requests without a valid Google JWT token for the

configured Client-ID can only access PAS for OpenEdge services.

11. Access the loginPage.html again, click on ‘Google Sign-in’ and enter your Google
credentials, and this time it should invoke the _oeping Service successfully and return a
valid response.

Progress Software Corporation

 28

As the Client Principal is validated successfully, it generated all its properties.

Progress Software Corporation

 29

OAuth 2.0 testing with AWS Cognito

AWS Cognito provides the ability for AWS users to create a User Pool and authenticate users
against it. In addition to static User Pool, it also provides options to integrate with Social
Authentication Providers like Google, Facebook etc.

Documentation on how to generate tokens with AWS Cognito User Pool can be found here:
http://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-
using-tokens-with-identity-providers.html

Note: The process followed for AWS Cognito is the same as for Google, so we are not
providing step-by-step instructions.

In the sample provided, we have tested with AWS Cognito User Pool. We have created ‘pasuser’
as a user in the UserPool ‘PAS for OpenEdgeData’.

JWT tokens generated by AWS Cognito provides client-id and scopes. Hence configuring
oauth2.resSvc.tokenServices as oauth2 and defining the client-id in the OAuth
2.0ResSvcClients.cfg file.

Progress Software Corporation

 30

You can add as many client-id’s as you want in oauth2.resSvc.tokenServices for validation.

Similarly, update the scope in oeablSecurityJWT.csv file. For the configuration we have used in
AWS, the scope of the token was ‘aws.cognito.signin.user.admin’. Modify it based on the scope
assigned to your token from AWS Cognito.

Copy AWS.properties to oepas1\webapps\ROOT\WEB-INF as oeablSecurity.properties and

restart the server. Modify the ‘jwkURL’ in oeablSecurity.properties as per your AWS Cognito
UserPool.

Access loginPage.html, enter the AWS Cogntio UserPool credentials and click on ‘AWS Sign-in’.
If the JWT token is generated successfully, the token is sent to Spring and it will validate and
convert it to a Client Principal token.

Progress Software Corporation

 31

Progress Software Corporation