Use Keycloak SSO and TLS to build secure routes

The first article in this series examining multiple ways of deploying trusted public key infrastructure (PKI) covered establishing secure routes and TLS termination. The follow-up articles described different ways of accomplishing this: the second article used wildcard certificates, the third used service mesh and Mutual Transport Layer Security (mTLS), and this final article uses Keycloak. I'll also summarize the three approaches and how they help ensure the security and accessibility of sensitive data and systems.

What is Keycloak?

Keycloak is an open source software that allows single sign-on (SSO) with identity and access management (IAM) based on popular standards such as SAML 2.0, OpenID Connect, and OAuth 2.0. Red Hat has maintained it for many years, and it is the upstream for Red Hat Single Sign-On (RH-SSO). The RH-SSO server can act as a SAML or OpenID Connect-based identity provider or third-party SSO provider for identity information and applications through standards-based tokens.

[ Related reading: How to architect OAuth 2.0 authorization using Keycloak ]

Administrators can deploy and support RH-SSO on Red Hat OpenShift using the Operator Framework. Administrators can configure it to load the required certificate infrastructure using files in Privacy Enhanced Mail (PEM) format or from a Java Keystore to establish Transport Layer Security (TLS).

PEM is a file format for storing cryptographic keys, certificates, and other cryptographic objects. PEM files (using .pem, .crt, .cer, or .key extensions) are typically encoded in Base64 and often store X.509 digital certificates, which secure HTTPS connections.

A Java Keystore is a repository of authorization or public key certificates plus their associated private keys. The Java Keystore is a standard format used by the Java Development Kit (JDK) to store the keys and certificates. A password protects the Keystore, and it can store multiple keys and certificates. The Keystore's default file format is JKS, but it can also use other formats, including PKCS12, JCEKS, and BKS.

When you configure both alternatives, the PEM files take precedence over the Java Keystore files, as they have been specifically designed to store a digital certificate required for establishing a secure SSL/TLS connection.

RH-SSO application templates

An important benefit of RH-SSO is that it offers multiple OpenShift application templates that define the resources needed to develop server-based deployments. The templates are mainly split into two categories: passthrough templates and reencryption templates. Following the recommended practice, I primarily focus on the templates that secure the TLS communication using passthrough TLS termination.

There are three passthrough templates (listed below), and they require HTTPS, JGroups keystores, and a trust store for the RH-SSO server:

• sso76-https: RH-SSO backed by internal H2 DB on the same pod
• sso76-postgresql: RH-SSO backed by ephemeral PostgreSQL DB on a separate pod
• sso76-postgresql-persistent: RH-SSO backed by persistent PostgreSQL DB on a separate pod

[ Discover ways enterprise architects can map and implement modern IT strategy with a hybrid cloud strategy. ]

Deploy passthrough TLS termination templates

The information below comes from OpenShift's documentation about advanced procedures.

Prerequisites

• HTTPS, JGroups keystores, and the RH-SSO server trust store exist and can be used for instantiation.
• The openssl toolkit is used to generate a certificate authority (CA) certificate to sign the HTTPS keystore and create a trust store for the RH-SSO server.
• The keytool, a package included with the Java Development Kit, is used to generate self-signed certificates for HTTPS keystores.

Procedure

Log in to the OpenShift CLI with a user that holds the cluster:admin role.

Create a new project:

$ oc new-project app-demo

Add the view role to the default service account. This enables the service account to view all the resources in the sso-app-demo namespace, which is necessary for managing the cluster:

$ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default

Create the HTTPS keystore (used for encryption of HTTPS traffic).

Generate a CA certificate. Pick and remember the password. Provide an 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-demo.ca"

Generate a private key for the HTTPS keystore. Provide mykeystorepass as the keystore password:

$ keytool -genkeypair -keyalg RSA -keysize 2048 -dname \ "CN=secure-app-demo.ocp.example.com" -alias jboss -keystore keystore.jks

[ Simplify your security operations center ]

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 you used to generate the CA certificate:

$ openssl x509 -req <(printf "subjectAltName=DNS:secure-app-demo.ocp.example.com") -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 the Trust this certificate? 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

Generate a secure key for the JGroups keystore (used to encrypt JGroups communications between nodes in the cluster).

Provide password as the keystore password:

$ keytool -genseckey -alias secret-key -storetype JCEKS -keystore jgroups.jceks

Import the CA certificate into a new RH-SSO server trust store (used for securing the RH-SSO requests).

Provide mykeystorepass as the trust store password. Reply yes to Trust this certificate? [no]: question:

$ keytool -import -file xpaas.crt -alias xpaas.ca -keystore truststore.jks

Create the secrets for the HTTPS and JGroups keystores and the RH-SSO server trust store:

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

Link these secrets to the default service account, which runs RH-SSO pods:

$ oc secrets link default app-secret

Deploy a passthrough TLS termination template by using the oc command.

Below is a sample command with values of SSO_ADMIN_USERNAME, SSO_ADMIN_PASSWORD, HTTPS_PASSWORD, JGROUPS_ENCRYPT_PASSWORD, and SSO_TRUSTSTORE_PASSWORD variables matching the default values in the sso76-https template:

$ oc new-app --template=sso76-https \
 -p HTTPS_SECRET="app-secret" \
 -p HTTPS_KEYSTORE="keystore.jks" \
 -p HTTPS_NAME="jboss" \
 -p HTTPS_PASSWORD="mykeystorepass" \
 -p JGROUPS_ENCRYPT_SECRET="app-secret" \
 -p JGROUPS_ENCRYPT_KEYSTORE="jgroups.jceks" \
 -p JGROUPS_ENCRYPT_NAME="secret-key" \
 -p JGROUPS_ENCRYPT_PASSWORD="password" \
 -p SSO_ADMIN_USERNAME="admin" \
 -p SSO_ADMIN_PASSWORD="redhat" \
 -p SSO_REALM="demorealm" \
 -p SSO_TRUSTSTORE="truststore.jks" \
 -p SSO_TRUSTSTORE_PASSWORD="mykeystorepass" \
 -p SSO_TRUSTSTORE_SECRET="app-secret"

Wrapping up the series

The four articles in this series discussed various methods for securing connections: route reencryption with route-specific or wildcard certificates; service mesh ingress gateway and mutual TLS authentication; and Keycloak (RH-SSO) and TLS.

These topics are relevant and important as the continual increase in connectivity requires more robust security measures. PKI authentication is essential in ensuring trusted connections and should be seriously explored by any organization focused on providing secure internal and external communications. That said, authentication tools can be combined with an overarching implementation of IAM systems. This design allows an organization to manage and control access to its resources, such as applications, servers, and data, to prevent unauthorized access to sensitive data and systems and ensure that only authorized users can perform specific actions.

IAM and SSO can provide an organization with a comprehensive approach to managing and controlling access to its resources. By implementing IAM and SSO, organizations can improve the security of their data and systems while making it more convenient for users to access the resources they need.