Skip to main content
Redhat Developers  Logo
  • Products

    Featured

    • Red Hat Enterprise Linux
      Red Hat Enterprise Linux Icon
    • Red Hat OpenShift AI
      Red Hat OpenShift AI
    • Red Hat Enterprise Linux AI
      Linux icon inside of a brain
    • Image mode for Red Hat Enterprise Linux
      RHEL image mode
    • Red Hat OpenShift
      Openshift icon
    • Red Hat Ansible Automation Platform
      Ansible icon
    • Red Hat Developer Hub
      Developer Hub
    • View All Red Hat Products
    • Linux

      • Red Hat Enterprise Linux
      • Image mode for Red Hat Enterprise Linux
      • Red Hat Universal Base Images (UBI)
    • Java runtimes & frameworks

      • JBoss Enterprise Application Platform
      • Red Hat build of OpenJDK
    • Kubernetes

      • Red Hat OpenShift
      • Microsoft Azure Red Hat OpenShift
      • Red Hat OpenShift Virtualization
      • Red Hat OpenShift Lightspeed
    • Integration & App Connectivity

      • Red Hat Build of Apache Camel
      • Red Hat Service Interconnect
      • Red Hat Connectivity Link
    • AI/ML

      • Red Hat OpenShift AI
      • Red Hat Enterprise Linux AI
    • Automation

      • Red Hat Ansible Automation Platform
      • Red Hat Ansible Lightspeed
    • Developer tools

      • Red Hat Trusted Software Supply Chain
      • Podman Desktop
      • Red Hat OpenShift Dev Spaces
    • Developer Sandbox

      Developer Sandbox
      Try Red Hat products and technologies without setup or configuration fees for 30 days with this shared Openshift and Kubernetes cluster.
    • Try at no cost
  • Technologies

    Featured

    • AI/ML
      AI/ML Icon
    • Linux
      Linux Icon
    • Kubernetes
      Cloud icon
    • Automation
      Automation Icon showing arrows moving in a circle around a gear
    • View All Technologies
    • Programming Languages & Frameworks

      • Java
      • Python
      • JavaScript
    • System Design & Architecture

      • Red Hat architecture and design patterns
      • Microservices
      • Event-Driven Architecture
      • Databases
    • Developer Productivity

      • Developer productivity
      • Developer Tools
      • GitOps
    • Secure Development & Architectures

      • Security
      • Secure coding
    • Platform Engineering

      • DevOps
      • DevSecOps
      • Ansible automation for applications and services
    • Automated Data Processing

      • AI/ML
      • Data Science
      • Apache Kafka on Kubernetes
      • View All Technologies
    • Start exploring in the Developer Sandbox for free

      sandbox graphic
      Try Red Hat's products and technologies without setup or configuration.
    • Try at no cost
  • Learn

    Featured

    • Kubernetes & Cloud Native
      Openshift icon
    • Linux
      Rhel icon
    • Automation
      Ansible cloud icon
    • Java
      Java icon
    • AI/ML
      AI/ML Icon
    • View All Learning Resources

    E-Books

    • GitOps Cookbook
    • Podman in Action
    • Kubernetes Operators
    • The Path to GitOps
    • View All E-books

    Cheat Sheets

    • Linux Commands
    • Bash Commands
    • Git
    • systemd Commands
    • View All Cheat Sheets

    Documentation

    • API Catalog
    • Product Documentation
    • Legacy Documentation
    • Red Hat Learning

      Learning image
      Boost your technical skills to expert-level with the help of interactive lessons offered by various Red Hat Learning programs.
    • Explore Red Hat Learning
  • Developer Sandbox

    Developer Sandbox

    • Access Red Hat’s products and technologies without setup or configuration, and start developing quicker than ever before with our new, no-cost sandbox environments.
    • Explore Developer Sandbox

    Featured Developer Sandbox activities

    • Get started with your Developer Sandbox
    • OpenShift virtualization and application modernization using the Developer Sandbox
    • Explore all Developer Sandbox activities

    Ready to start developing apps?

    • Try at no cost
  • Blog
  • Events
  • Videos

Quick links: redhat.com, Customer Portal, Red Hat's developer site, Red Hat's partner site.

  • You are here

    Red Hat

    Learn about our open source products, services, and company.

  • You are here

    Red Hat Customer Portal

    Get product support and knowledge from the open source experts.

  • You are here

    Red Hat Developer

    Read developer tutorials and download Red Hat software for cloud application development.

  • You are here

    Red Hat Partner Connect

    Get training, subscriptions, certifications, and more for partners to build, sell, and support customer solutions.

Products & tools

  • Ansible.com

    Learn about and try our IT automation product.
  • Red Hat Ecosystem Catalog

    Find hardware, software, and cloud providers―and download container images―certified to perform with Red Hat technologies.

Try, buy, & sell

  • Red Hat Hybrid Cloud Console

    Access technical how-tos, tutorials, and learning paths focused on Red Hat’s hybrid cloud managed services.
  • Red Hat Store

    Buy select Red Hat products and services online.
  • Red Hat Marketplace

    Try, buy, sell, and manage certified enterprise software for container-based environments.

Events

  • Red Hat Summit and AnsibleFest

    Register for and learn about our annual open source IT industry event.

Deploy Red Hat's single sign-on technology on Red Hat OpenShift using templates

May 19, 2021
Olivier Rivat
Related topics:
DevOpsLinuxKubernetes
Related products:
Red Hat OpenShift

Share:

Share on twitter Share on facebook Share on linkedin Share with email
  • SSO templates for OpenShift deployment
  • TLS termination in SSO templates
  • Using templates to deploy SSO on OpenShift
  • Adding a certificate to the SSO truststore
  • Conclusion

The goal of this article is to help developers understand and use Red Hat OpenShift image streams and application templates to deploy Red Hat's single sign-on (SSO) technology on OpenShift. Also see my earlier article about using SSO and OpenShift: Integrate Red Hat’s single sign-on technology 7.4 with Red Hat OpenShift.

SSO templates for OpenShift deployment

SSO templates for OpenShift deployment

Use the following command to get a list of SSO deployment templates for OpenShift:

$ oc get templates -n openshift -o name | grep -o 'sso74.\+'
sso74-https
sso74-postgresql
sso74-postgresql-persistent
sso74-x509-https
sso74-x509-postgresql-persistent
Copy snippet

Select the template for the behavior you want

You can use templates to define how SSO will be deployed on OpenShift. Each template offers different deployment options:

  • TLS termination:
    • Re-encrypt
    • Pass-through
  • Database back-end type:
    • In-memory H2 database
    • PostgreSQL database
  • Storage:
    • Ephemeral
    • Persistent

You can use the template's name pattern to select a template that offers the behavior that you need. As an example, ocp4-x509 in the template name means the template uses re-encrypt Transport Layer Security (TLS) termination. If the template name includes postgresql, then the database back-end for that template is PostgreSQL. If it includes persistent, then you know that template preserves SSO data across database or SSO pod restarts.

SSO template features

Here is a listing of SSO templates and the features they provide:

SSO template: sso74-https:

  • Pass-through TLS termination
  • H2 in-memory database
  • Ephemeral storage

SSO template: sso74-ocp4-x509-https:

  • Re-encrypt TLS termination
  • H2 in-memory database
  • Ephemeral storage

SSO template: sso74-ocp4-x509-postgresql-persistent:

  • Re-encrypt TLS termination
  • PostgreSQL database
  • Persistent storage

SSO template: sso74-postgresql:

  • Pass-through TLS termination
  • PostgreSQL database
  • Ephemeral storage

SSO template: sso74-postgresql-persistent:

  • Pass-through TLS termination
  • PostgreSQL database
  • Persistent storage
TLS termination in SSO templates

TLS termination in SSO templates

Single sign-on templates with the name pattern ocp4-x509 use re-encrypt TLS termination. All other templates use pass-through TLS termination. Let's consider the main differences between re-encrypt TLS termination and pass-through TLS termination.

Re-encrypt TLS termination

In re-encrypt TLS termination, the SSO keystore and truststore are automatically created when you deploy single sign-on on OpenShift. Deploying TLS is very simple because everything is configured automatically. On the downside, you cannot directly access the SSO keystore and truststore. Adding a new external certificate authority (CA) certificate to the SSO truststore requires rebuilding and redeploying a new SSO image.

Pass-through TLS termination

This style of TLS termination is very flexible, and updating the SSO truststore is easy to do. Adding external certificates is not complex. The downside of this approach is that it has to be configured manually, as described here.

Using templates to deploy SSO on OpenShift

Using templates to deploy SSO on OpenShift

Next, we'll use templates to deploy SSO on OpenShift.

Deploying SSO on OpenShift using a re-encrypt TLS termination template

Here's the command to create a project with one of the re-encrypt templates. In this case, we're choosing a PostgreSQL database and persistent storage:

$ oc new-project sso-74-reencrypt
$ oc new-app --template=sso74-ocp4-x509-postgresql-persistent
Copy snippet

Remember that with the re-encrypt TLS termination templates, the deployment is configured for you. Next, we'll deploy SSO with one of the pass-through TLS termination templates. These require manual configuration.

Deploying SSO on OpenShift using a pass-through TLS termination template

We have to create the SSO keystore and truststore manually before deploying SSO with the pass-through TLS termination template. The keystore and truststore are passed to the SSO pod as OpenShift secrets. First, we'll create the HTTPS and JGroups keystores and truststore for the single sign-on server, then we'll deploy the SSO template.

Step 1: Create the keystores and truststore

Start by creating the HTTPS keystore:

Generate a CA certificate. Pick and remember the password. Provide identical password, when signing the certificate sign request with the CA certificate below:

$ openssl req -new -newkey rsa:4096 -x509 -keyout xpaas.key -out xpaas.crt -days 365 -subj "/CN=xpaas-sso-demo.ca"
Generate a CA certificate for the HTTPS keystore. Provide mykeystorepass as the keystore password:

$ keytool -genkeypair -keyalg RSA -keysize 2048 -dnsureame "CN=secure-sso-sso-app-demo.openshift.example.com" -alias jboss -keystore keystore.jks
Generate a certificate sign request for the HTTPS keystore. Provide mykeystorepass as the keystore password:

$ keytool -certreq -keyalg rsa -alias jboss -keystore keystore.jks -file sso.csr
Sign the certificate sign request with the CA certificate. Provide the same password that was used to generate the CA certificate:

$ openssl x509 -req -CA xpaas.crt -CAkey xpaas.key -in sso.csr -out sso.crt -days 365 -CAcreateserial
Import the CA certificate into the HTTPS keystore. Provide mykeystorepass as the keystore password. Reply yes to Trust this certificate? [no]: question:

$ keytool -import -file xpaas.crt -alias xpaas.ca -keystore keystore.jks
Import the signed certificate sign request into the HTTPS keystore. Provide mykeystorepass as the keystore password:

$ keytool -import -file sso.crt -alias jboss -keystore keystore.jks
Copy snippet

The keystore.jks, truststore.jks, and jgroups.jceks are passed to SSO pods as OpenShift secrets. We will link these secrets to the default service account, which is used to run single sign-on pods:

$ oc create secret generic sso-app-secret --from-file=keystore.jks --from-file=jgroups.jceks --from-file=truststore.jks
secret/sso-app-secret created
$ oc secrets link default sso-app-secret
Copy snippet

Step 2: Deploy the SSO template

Now, we can deploy SSO on OpenShift using the pass-through TLS termination template:

$ oc new-project sso-74-passthrough
$ oc new-app --template=sso74-postgresql-persistent
Copy snippet

Note: For more details, see the requirements for deploying pass-through TLS termination SSO templates.

Adding a certificate to the SSO truststore

Adding a certificate to the SSO truststore

We might need to add a certificate to the SSO truststore if SSO is making outbound connections to an external server using HTTPS or LDAP. When we use one of the X509 templates (such as for re-encrypt TLS termination), the SSO keystore and truststore are generated automatically from OpenShift's internal X509 certificate serving service. In order to add a new certificate, we need to build a new SSO image.

Adding a certificate using a re-encrypt TLS termination template

Adding a certificate to the SSO truststore consists of the following steps:

  1. Retrieve the java cacerts file from the SSO pod.
  2. Add the new certificate to the java cacerts file located at /etc/pki/ca-trust/extracted/java/cacerts. (The file is copied automatically into SSO /opt/eap/keystores/truststore.jks during deployment.)
  3. Build a new SSO OpenShift image.
  4. Deploy the new SSO image.

Step 1: Retrieve java cacerts from the SSO pod

The SSO java cacerts file is retrieved from SSO running pod using the rsync command:

$ oc get pods

NAME READY STATUS RESTARTS AGE
<sso-pod-name> 1/1 Running 0 52s

$ oc rsync <sso-pod-name>:/etc/pki/ca-trust/extracted/java/cacerts .
Copy snippet

Step 2: Add the new certificate to java cacerts

Adding a new certificate to the SSO truststore consists of adding this new certificate to the java cacerts file:

$ keytool -import -v -file <my-cert>.crt -alias my-cert -keystore ./cacerts -noprompt -storepass changeit
Copy snippet

Step 3: Build the new SSO OpenShift image

A Dockerfile describes how the java cacerts file is added to build a new SSO OpenShift image:

FROM rh-sso-7/sso74-openshift-rhel8:latest
COPY cacerts /etc/pki/ca-trust/extracted/java/cacerts
Copy snippet

We can use a Podman command to build a new image:

podman build -t docker-registry-default/project/name:tag .

podman build -t docker-registry-default/project/sso74:reencrypt-truststore-updated .
STEP 1: FROM rh-sso-7/sso74-openshift-rhel8:latest
STEP 2: COPY cacerts /etc/pki/ca-trust/extracted/java/cacerts
STEP 3: COMMIT docker-registry-default/project/sso74:reencrypt-truststore-updated
--> 356f138e3fd
356f138e3fdee0b7424eec5fec10f3b57ced6c896b829d55be1d60abc18280a3
Copy snippet

The new image now contains the updated SSO truststore.

Step 4: Deploy the new SSO image

After the build finishes, you will push your new image to the OpenShift registry to deploy it. The new image will be uploaded when the SSO pod is restarted.

Adding a certificate using a pass-through TLS termination template

Adding a new certificate to SSO truststore with this template consists of the following steps:

  1. Retrieve the existing truststore.jks file.
  2. Add new certificate to truststore.jks.
  3. Delete secret corresponding to the SSO truststore.
  4. Create a new secret that contains the truststore.jks file.

Step 1: Retrieve the SSO truststore.jks file

Retrieve the SSO truststore.jks file from OpenShift using the rsync command:

$ oc rsync <sso-pod-name>:/opt/eap/keystores/truststore.jks .
Copy snippet

Step 2: Add new certificate to truststore.jks

Add this new certificate to the Java cacerts file:

$ keytool -import -v -file <my-cert>.crt -alias my-cert -keystore ./truststore.jks -noprompt -storepass changeit
Copy snippet

Step 3: Delete the secret corresponding to the SSO truststore

Updating the SSO truststore consists of updating the secret used by the SSO pod. When the value of a secret is modified, you must delete the original pod and create a new one:

$ oc delete secret  sso-app-secret
Copy snippet

Step 4: Create a new secret that contains the truststore.jks file

After truststore.jks has been updated to contain your new certificate, you must re-create the secret, sso-app-secret. The updated secret encompasses jgroups.jceks, truststore.jks, and keystore.jks:

$  oc create secret generic sso-app-secret --from-file=keystore.jks --from-file=jgroups.jceks --from-file=truststore.jks
secret/sso-app-secret created

$ oc secrets link default sso-app-secret
Copy snippet

You can now safely use SSO with the updated truststore deployed on OpenShift.

Conclusion

Conclusion

Templates offer very interesting features for deploying Red Hat's single sign-on technology on Red Hat OpenShift. As an end user, you can use one of the re-encrypt TLS termination templates, where TLS is configured automatically, or a pass-through termination TLS template, in which case you will do some of the TLS configuration manually. As you've seen in this article, it's much easier to add new certificates to the SSO truststore when using a pass-through TLS termination template. You can do it dynamically by updating the secret for the trustsrore.jks file. If you are using a re-encrypt TLS termination template, you will need to rebuild and redeploy your original SSO image.

Last updated: August 26, 2022

Recent Posts

  • LLM Compressor: Optimize LLMs for low-latency deployments

  • How to set up NVIDIA NIM on Red Hat OpenShift AI

  • Leveraging Ansible Event-Driven Automation for Automatic CPU Scaling in OpenShift Virtualization

  • Python packaging for RHEL 9 & 10 using pyproject RPM macros

  • Kafka Monthly Digest: April 2025

Red Hat Developers logo LinkedIn YouTube Twitter Facebook

Products

  • Red Hat Enterprise Linux
  • Red Hat OpenShift
  • Red Hat Ansible Automation Platform

Build

  • Developer Sandbox
  • Developer Tools
  • Interactive Tutorials
  • API Catalog

Quicklinks

  • Learning Resources
  • E-books
  • Cheat Sheets
  • Blog
  • Events
  • Newsletter

Communicate

  • About us
  • Contact sales
  • Find a partner
  • Report a website issue
  • Site Status Dashboard
  • Report a security problem

RED HAT DEVELOPER

Build here. Go anywhere.

We serve the builders. The problem solvers who create careers with code.

Join us if you’re a developer, software engineer, web designer, front-end designer, UX designer, computer scientist, architect, tester, product manager, project manager or team lead.

Sign me up

Red Hat legal and privacy links

  • About Red Hat
  • Jobs
  • Events
  • Locations
  • Contact Red Hat
  • Red Hat Blog
  • Inclusion at Red Hat
  • Cool Stuff Store
  • Red Hat Summit

Red Hat legal and privacy links

  • Privacy statement
  • Terms of use
  • All policies and guidelines
  • Digital accessibility

Report a website issue