Some customers prefer enabling and offloading SSL at load balancer instead of Pega app nodes. With this solution, called "SSL offloading" or "SSL termination", client and LB communicates with SSL, and LB and server communicates without SSL. Encryption or decryption is CPU-intensive and consumes the resources to a large extent. The SSL offloading concept was introduced to relieve a web server of the processing burden and make the backend work faster. Another benefit is you need certificate only for LB and you don't need it for every app node.
Recently, customer reported to me that Single Sign On process using OpenID Connect does not work with LB that enables SSL offloading. To investigate this issue, we've set up a PoC environment as below and figured a solution. In this post, I'll summarize how we got this to work.
1. Install nginx
First of all, we've set up a load balancer using nginx-1.13.7 on CentOS 7. I'll skip the detailed steps here but basically we configured cookie stickiness by installing an additional module (nginx-sticky-module-ng-1.2.6) and specified "sticky" in the nginx.conf as below.
SSL is offloaded by forwarding requests to backend servers by HTTP as below.
We installed Keycloak on Windows PC for OpenID Connect server. I'll skip the detailed step here but basically you need to set up "Realm", "User", and "Client" from Keycloak Admin Console. Pega serves as RP (Relying Party) and Keycloak serves as OP (OpenID Provider) in this scenario.
3. Configure Authentication Service
Create a Data-Admin-AuthService instance for OpenID Connect. Import metadata as below to fulfill all the necessary fields such as Authentication endpoint. This will also generate a Data-Admin-Security-Keystore instance.
Once metadata is imported, fill in Client ID and Client Secret. These can be obtained from Keycloak Admin Console. Then check on "Enable operator provisioning using model operator" and specify an existing model operator.
2. User is successfully created on-the-fly in Pega database and able to log in.
Now, we verified both Approach A and B solves the issue. Are there any differences? This is my personal opinion but I would recommend Approach A, because context is independently added outside of Pega upfront. For example, if you take Approach B, and if you access app node directly (ex. http://192.168.17.101:8080/prweb/PRAuth/KeyCloakAuth), Pega still tries to push the request back to LB. As long as LB is alive it works but if LB is down, you'll see below error.
On the other hand, if you are taking Approach A, and if you access app node directly, the context wouldn't be added. That means it won't push back to LB and Pega still works independently from LB. OpenID Connect authentication can even work as long as you add Redirect URIs for AP #1 and AP #2 at OP (see below for Keycloak configuration).