red hat jboss middleware for openshift 3 red hat jboss sso ... · red hat jboss middleware for...

Red Hat JBoss Middleware for OpenShift DocumentationTeam

Red Hat JBoss Middleware forOpenShift 3Red Hat JBoss SSO for OpenShift

Using Red Hat JBoss SSO for OpenShift

Red Hat JBoss Middleware for OpenShift 3 Red Hat JBoss SSO forOpenShift

Using Red Hat JBoss SSO for OpenShift

Legal Notice

Copyright © 2016 Red Hat, Inc.

The text of and illustrations in this document are licensed by Red Hat under a Creative CommonsAttribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA isavailable athttp://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you mustprovide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinitylogo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and othercountries.

Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.

Java ® is a registered trademark of Oracle and/or its affiliates.

XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United Statesand/or other countries.

MySQL ® is a registered trademark of MySQL AB in the United States, the European Union andother countries.

Node.js ® is an official trademark of Joyent. Red Hat Software Collections is not formally related toor endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marksor trademarks/service marks of the OpenStack Foundation, in the United States and other countriesand are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed orsponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

AbstractGuide to using Red Hat JBoss SSO for OpenShift

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Table of Contents

CHAPTER 1. INTRODUCTION1.1. WHAT IS RED HAT SSO?

CHAPTER 2. BEFORE YOU BEGIN2.1. COMPARISON: RH-SSO FOR OPENSHIFT IMAGE AND RED HAT SSO2.2. VERSION COMPATIBILITY AND SUPPORT2.3. INITIAL SETUP

CHAPTER 3. GET STARTED3.1. USING THE RH-SSO FOR OPENSHIFT IMAGE STREAMS AND APPLICATION TEMPLATES3.2. PREPARING AND DEPLOYING THE RH-SSO FOR OPENSHIFT APPLICATION TEMPLATES

CHAPTER 4. TUTORIALS4.1. EXAMPLE WORKFLOW: PREPARING AND DEPLOYING THE RH-SSO FOR OPENSHIFT IMAGE4.2. EXAMPLE WORKFLOW: CONFIGURING OPENSHIFT TO USE SSO FOR AUTHENTICATION4.3. EXAMPLE WORKFLOW: AUTOMATICALLY REGISTERING EAP APPLICATION IN SSO WITH OPENID-CONNECT CLIENT4.4. EXAMPLE WORKFLOW: MANUALLY REGISTERING EAP APPLICATION IN SSO WITH SAML CLIENT

CHAPTER 5. REFERENCE5.1. ENVIRONMENT VARIABLES

33

4444

555

121215

18

22

2828

Table of Contents

1

Red Hat JBoss Middleware for OpenShift 3 Red Hat JBoss SSO for OpenShift

2

CHAPTER 1. INTRODUCTION

1.1. WHAT IS RED HAT SSO?

Red Hat Single Sign-On (SSO) is an integrated sign-on solution available as a containerized xPaaSimage designed for use with OpenShift. This image provides an authentication server for users tocentrally log in, log out, register, and manage user accounts for web applications, mobileapplications, and RESTful web services.

Red Hat offers five SSO application templates:

sso70-https: SSO backed by a H2 database on the same pod

sso70-mysql: SSO backed by a MySQL database on a separate pod

sso70-mysql-persistent: SSO backed by a persistent MySQL database on a separate pod

sso70-postgresql: SSO backed by a PostgreSQL database on a separate pod

sso70-postgresql-persistent: SSO backed by a persistent PostgreSQL database on aseparate pod

Two templates for Red Hat JBoss Enterprise Application Platform (JBoss EAP) are also offered:

eap64-sso-s2i: SSO-enabled JBoss EAP64

eap70-sso-s2i: SSO-enabled JBoss EAP70

These templates contain environment variables specific to SSO that enable automatic SSO clientregistration when deployed.See Automatic and Manual SSO Client Registration Methods for more information.

CHAPTER 1. INTRODUCTION

3

CHAPTER 2. BEFORE YOU BEGIN

2.1. COMPARISON: RH-SSO FOR OPENSHIFT IMAGE AND RED HATSSO

The RH-SSO for OpenShift image is based on Red Hat Single Sign-On 7.0. There are somedifferences in functionality between the RH-SSO for OpenShift Image and Red Hat Single Sign-On:

The RH-SSO for OpenShift image includes all of the functionality of Red Hat Single Sign-On 7.0.In addition, the SSO-enabled JBoss EAP image automatically handles OpenID Connect orSAML client registration and configuration for .war deployments that contain <auth-method>KEYCLOAK</auth-method> or <auth-method>KEYCLOAK-SAML</auth-method>in their respective web.xml files.

The RH-SSO for OpenShift image currently only supports replicated caching. Using distributedcaching results in errors when the deployment is scaled or updated. See the Server CacheConfiguration chapter in the Red Hat Single Sign-On Server Installation and Configuration Guidefor more information on the caching types.

2.2. VERSION COMPATIBILITY AND SUPPORT

See the xPaaS part of the OpenShift and Atomic Platform Tested Integrations page for details aboutOpenShift image version compatibility.

2.3. INITIAL SETUP

The Tutorials in this guide follow on from and assume an OpenShift instance similar to that createdin the OpenShift Primer.


4

https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/server-installation-and-configuration-guide/#server_cache_configuration

https://access.redhat.com/articles/2176281

https://access.redhat.com/documentation/en/red-hat-application-services/0/openshift-primer

CHAPTER 3. GET STARTED

3.1. USING THE RH-SSO FOR OPENSHIFT IMAGE STREAMS ANDAPPLICATION TEMPLATES

Red Hat JBoss Middleware for OpenShift images are pulled on demand from the Red Hat Registry:registry.access.redhat.com

3.2. PREPARING AND DEPLOYING THE RH-SSO FOR OPENSHIFTAPPLICATION TEMPLATES

3.2.1. Configuring Keystores

The RH-SSO for OpenShift image requires two keystores:- An SSL keystore to provide private and public keys for https traffic encryption.- A JGroups keystore to provide private and public keys for network traffic encryption betweennodes in the cluster.

These keystores are expected by the RH-SSO for OpenShift image, even if the application usesonly http on a single-node OpenShift instance. Self-signed certificates do not provide securecommunication and are intended for internal testing purposes.

See the JBoss Enterprise Application Platform Security Guide for more information on how to createa keystore with self-signed or purchased SSL certificates.

3.2.2. Generating the Secret

OpenShift uses objects called Secrets to hold sensitive information, such as passwords orkeystores. See the Secrets chapter in the OpenShift documentation for more information.

The RH-SSO for OpenShift image requires a secret that holds the two keystores described earlier.This provides the necessary authorization to applications in the project.

Use the SSL and JGroups keystore files to create a secret for the project:

$ oc create secret generic <sso-secret-name> --from-file=<ssl.jks> --from-file=<jgroups.jceks>

After the secret has been generated, it can be associated with a service account.

3.2.3. Creating the Service Account

Service accounts are API objects that exist within each project and allow users to associate certain

Warning

For production environments Red Hat recommends that you use your own SSLcertificate purchased from a verified Certificate Authority (CA) for SSL-encryptedconnections (HTTPS).


5

http://registry.access.redhat.com

https://access.redhat.com/documentation/en-US/JBoss_Enterprise_Application_Platform/6.1/html-single/Security_Guide/index.html#Generate_a_SSL_Encryption_Key_and_Certificate

https://access.redhat.com/documentation/en/openshift-enterprise/version-3.2/developer-guide/#dev-guide-secrets

secrets and roles with applications in a project namespace. This provides the application with thenecessary authorization to run with all required privileges.

The service account that you create must be configured with the correct permissions to view pods inKubernetes. This is required in order for clustering with the RH-SSO for OpenShift image to work.You can view the top of the log files to see whether the correct service account permissions havebeen configured.

The SSO templates have a default SERVICE_ACCOUNT_NAME variable of sso-service-account. Ifa different service account name is used, this variable must be configured with the appropriateservice account name.

1. Create a service account to be used for the SSO deployment:

$ oc create serviceaccount <service-account-name>

2. Add the view role to the service account. This enables the service account to view all theresources in the application namespace in OpenShift, which is necessary for managing thecluster.

$ oc policy add-role-to-user view system:serviceaccount:<project-name>:<service-account-name> -n <project-name>

3. Add the secret created for the project to the service account:

$ oc secret add sa/<service-account-name> secret/<sso-secret-name>

3.2.4. Using the OpenShift Web Console

Log in to the OpenShift web console:

1. Click Add to project to list all of the default image streams and templates.

2. Use the Filter by keyword search bar to limit the list to those that match sso. You mayneed to click See all to show the desired application template.

3. Select an application template and configure the deployment parameters as required.

4. Click Create to deploy the application template.

These are some of the more common variables to configure an SSO deployment:

Variable Description

APPLICATION_NAME The name for the SSO application.

HOSTNAME_HTTPS Custom hostname for https service route. Leaveblank for default hostname of <application-name>.<project>.<default-domain-suffix>


6

HOSTNAME_HTTP Custom hostname for http service route. Leaveblank for default hostname of <application-name>.<project>.<default-domain-suffix>

HTTPS_KEYSTORE The name of the keystore file within the secret.

HTTPS_PASSWORD The password for the keystore and certificate.

HTTPS_SECRET The name of the secret containing the keystore file.

JGROUPS_ENCRYPT_KEYSTORE The name of the JGroups keystore file within thesecret.

JGROUPS_ENCRYPT_PASSWORD The password for the JGroups keystore andcertificate.

JGROUPS_ENCRYPT_SECRET The name of the secret containing the JGroupskeystore file.

SERVICE_ACCOUNT_NAME The name of the service account to use for thedeployment. The service account should beconfigured to allow usage of the secret(s) specifiedby HTTPS_SECRET andJGROUPS_ENCRYPT_SECRET. If not provided,the default is sso-service-account.

SSO_ADMIN_USERNAME SSO server administrator user name. If this is notprovided the deployment will create a defaultadmin user.

SSO_ADMIN_PASSWORD SSO server admin password. If not provided thedeployment will generate a default password ofadmin.

SSO_REALM The name of an additional SSO realm to createduring deployment.



7

SSO_SERVICE_USERNAME SSO service user name to manage the realm.

SSO_SERVICE_PASSWORD SSO service user password.


See the Reference chapter for a more comprehensive list of the SSO environment variables. Seethe Example Workflow: Preparing and Deploying the RH-SSO for OpenShift Image for an end-to-end example of SSO deployment.

3.2.5. Deployment Process

Once deployed, the sso70-https image creates a single pod that contains both the database andSSO web servers. The sso70-mysql and sso70-postgres images create two pods, one for thedatabase and one for the SSO web servers.

After the SSO web server pod has started, the web servers can be accessed at their customconfigured hostnames, or at the default hostnames:

http://sso-<project-name>.<hostname>/auth/admin: for the web server, and

https://secure-sso-<project-name>.<hostname>/auth/admin: for the encrypted web server.

Unless specified during deployment with the SSO_ADMIN_USERNAME andSSO_ADMIN_PASSWORD variables, the default login user name/password credentials areadmin/admin.

Note

If the SSO_ADMIN_PASSWORD variable was not used during deployment, the defaultlogin user admin credentials should be changed when you first log in. To do this, click theAdmin drop-down menu in the top right of the web console and selecting ManageAccount.

3.2.6. SSO Clients

Clients are SSO entities that request user authentication. A client could be an application requestingSSO to provide user authentication, or it could be making requests for access tokens in order toinvoke services on behalf of an authenticated user. See the Managing Clients chapter of the RedHat Single Sign-On documentation for more information.

SSO provides OpenID-Connect and SAML client protocols.OpenID-Connect is the preferred protocol and utilizes three different access types:

public: Useful for JavaScript applications that run directly in the browser and require no serverconfiguration.

confidential: Useful for server-side clients, such as EAP web applications, that need to performa browser login.

bearer-only: Useful for back-end services that allow bearer token requests.


8

https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/server-administration-guide/chapter-8-managing-clients

https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/server-administration-guide/#oidc_clients

https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/server-administration-guide/#saml_clients

The client type must also be specified by the <auth-method> key in the application web.xml. Thisfile is read by the image at deployment.Use KEYCLOAK for the OpenID Connect client.Use KEYCLOAK-SAML for the SAML client.

The following is an example snippet for the application web.xml to configure an OIDC client:

...<login-config> <auth-method>KEYCLOAK</auth-method></login-config>...

3.2.7. Automatic and Manual SSO Client Registration Methods

A client application can be automatically registered to an SSO realm using credentials passed invariables specific to the eap64-sso-s2i and eap70-sso-s2i templates.

Alternatively, you can manually register the client application by configuring and exporting the SSOclient adapter and including it in the client application configuration.

3.2.8. Automatic SSO Client Registration

Automatic SSO client registration is determined by SSO environment variables specific to theeap64-sso-s2i and eap70-sso-s2i templates. The SSO credentials supplied in the template arethen used to register the client to the SSO realm during deployment of the client application.

The SSO environment variables included in the eap64-sso-s2i and eap70-sso-s2i templates are:


HOSTNAME_HTTP Custom hostname for http service route. Leaveblank for default hostname of <application-name>.<project>.<default-domain-suffix>

HOSTNAME_HTTPS Custom hostname for https service route. Leaveblank for default hostname of <application-name>.<project>.<default-domain-suffix>

SSO_URL The SSO web server authentication address:https://secure-sso-<project-name>.<hostname>/auth

SSO_REALM The SSO realm created for this procedure.


9

SSO_USERNAME The name of the realm management user.

SSO_PASSWORD The password of the user.

SSO_PUBLIC_KEY The public key generated by the realm. It is locatedin the Keys tab of the Realm Settings in the SSOconsole.

SSO_BEARER_ONLY If set to true, the OpenID Connect client isregistered as bearer-only.

SSO_ENABLE_CORS If set to true, the Keycloak adapter enables Cross-Origin Resource Sharing (CORS).


If the SSO realm uses a SAML client, the following additional variables need to be configured:


SSO_SAML_KEYSTORE_SECRET Secret to use for access to SAML keystore. Thedefault is sso-app-secret.

SSO_SAML_KEYSTORE Keystore filename in the SAML keystore secret.The default is keystore.jks.

SSO_SAML_KEYSTORE_PASSWORD Keystore password for SAML. The default ismykeystorepass.

SSO_SAML_CERTIFICATE_NAME Alias for keys/certificate to use for SAML. Thedefault is jboss.

See Example Workflow: Automatically Registering EAP Application in SSO with OpenID-ConnectClient for an end-to-end example of the automatic client registration method using an OpenID-Connect client.

3.2.9. Manual SSO Client Registration

Manual SSO client registration is determined by the presence of a deployment file in the client


10

application’s ../configuration/ folder. These files are exported from the client adapter in the SSO webconsole. The name of this file is different for OpenID-Connect and SAML clients:

OpenID-Connect

../configuration/secure-deployments

SAML ../configuration/secure-saml-deployments

These files are copied to the SSO adapter configuration section in the standalone-openshift.xml atwhen the application is deployed.

There are two methods for passing the SSO adapter configuration to the client application:

Modify the deployment file to contain the SSO adapter configuration so that it is included in the_standalone-openshift.xml) file at deployment, or

Manually include the OpenID-Connect keycloak.json file, or the SAML keycloak-saml.xml file inthe client application’s ../WEB-INF directory.

See Example Workflow: Manually Configure an Application to Use SSO Authentication, UsingSAML Client for an end-to-end example of the manual SSO client registration method using a SAMLclient.

3.2.10. Limitations

OpenShift does not currently accept OpenShift role mapping from external providers. If SSO is usedas an authentication gateway for OpenShift, users created in SSO must have the roles added usingthe OpenShift Administrator oadm policy command.

For example, to allow an SSO-created user to view a project namespace in OpenShift:

oadm policy add-role-to-user view <user-name> -n <project-name>


11

CHAPTER 4. TUTORIALS

4.1. EXAMPLE WORKFLOW: PREPARING AND DEPLOYING THERH-SSO FOR OPENSHIFT IMAGE

4.1.1. Preparing SSO Authentication for OpenShift Deployment

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

1. Create a new project:

$ oc new-project sso-app-demo


$ oc create serviceaccount sso-service-account

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

$ oc policy add-role-to-user view system:serviceaccount:sso-app-demo:sso-service-account

4. The SSO template requires an SSL keystore and a JGroups keystore.OpenShift does not permit login authentication from self-signed certificates. Fordemonstration purposes, this example uses ‘openssl‘ to generate a CA certificate to sign theSSL keystore and create a truststore. This truststore is also included in the creation of thesecret, and specified in the SSO template.This example also uses ‘keytool’, a package included with the Java Development Kit, togenerate self-signed certificates for these keystores. The following commands will promptfor passwords.

a. Generate a CA certificate:

$ openssl req -new -newkey rsa:4096 -x509 -keyout xpaas.key -out xpaas.crt -days 365 -subj "/CN=xpaas-sso-demo.ca"

b. Generate a Certificate for the SSL keystore:

$ keytool -genkeypair -keyalg RSA -keysize 2048 -dname "CN=secure-sso-sso-app-demo.openshift32.example.com" -alias sso-https-key -keystore sso-https.jks

c. Generate a Certificate Sign Request for the SSL keystore:

$ keytool -certreq -keyalg rsa -alias sso-https-key -keystore sso-https.jks -file sso.csr

d. Sign the Certificate Sign Request with the CA certificate:


12

$ openssl x509 -req -CA xpaas.crt -CAkey xpaas.key -in sso.csr -out sso.crt -days 365 -CAcreateserial

e. Import the CA into the SSL keystore:

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

f. Import the signed Certificate Sign Request into the SSL keystore:

$ keytool -import -file sso.crt -alias sso-https-key -keystore sso-https.jks

g. Import the CA into a new truststore keystore:

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

h. Generate a secure key for the JGroups keystore:

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

5. Create the SSO secret with the SSL and JGroups keystore files, as well as the truststore:

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

6. Add the secret to the service account created earlier:

$ oc secret add sa/sso-service-account secret/sso-app-secret

4.1.2. Deploying the SSO Application Template

1. Log in to the OpenShift web console and select the sso-app-demo project space.

2. Click Add to project to list all of the default image streams and templates.


4. Select an SSO application template. This example uses sso70-https. Specify theapplication name, hostnames, and SSL keystore, JGroups keystore, secret and serviceaccount information:

Variable Example Value

APPLICATION_NAME sso


13

HOSTNAME_HTTPS secure-sso-sso-app-demo.openshift32.example.com

HOSTNAME_HTTP sso-sso-app-demo.openshift32.example.com

HTTPS_KEYSTORE sso-https.jks

HTTPS_PASSWORD password

HTTPS_SECRET sso-app-secret

JGROUPS_ENCRYPT_KEYSTORE jgroups.jceks

JGROUPS_ENCRYPT_PASSWORD password

JGROUPS_ENCRYPT_SECRET sso-app-secret

SERVICE_ACCOUNT_NAME sso-service-account


Include the following variables to create a new demorealm realm when SSO is deployedand a user to manage that realm. You can also specify the SSO_ADMIN credentials here. Ifyou do not specify the SSO_ADMIN credentials, a default admin user is created with adefault password of admin.


SSO_REALM demorealm

SSO_SERVICE_USERNAME sso-mgmtuser

SSO_SERVICE_PASSWORD mgmt-password


14

SSO_ADMIN_USERNAME admin

SSO_ADMIN_PASSWORD adm-password


This example uses self-signed certificates and must additionally include information on thetruststore. These variables are not required with SSL certificates purchased from a verifiedCertificate Authority:


SSO_TRUSTSTORE truststore.jks

SSO_TRUSTSTORE_SECRET sso-app-secret

SSO_TRUSTSTORE_PASSWORD password

5. Click Create to deploy the application template and start pod deployment. This may take acouple of minutes.

The SSO web console can be accessed at https://secure-sso-<sso-app-demo>.<openshift32.example.com>/auth/admin using the admin user.

Note

This example workflow uses a self-generated CA to provide an end-to-end workflow fordemonstration purposes. Accessing the SSO web console will prompt an insecureconnection warning.For production environments, Red Hat recommends that you use an SSL certificatepurchased from a verified Certificate Authority.

4.2. EXAMPLE WORKFLOW: CONFIGURING OPENSHIFT TO USESSO FOR AUTHENTICATION

Configure OpenShift to use the SSO deployment as the authorization gateway for OpenShift. Thisfollows on from Example Workflow: Preparing and Deploying the RH-SSO for OpenShift image, inwhich SSO was deployed on OpenShift.

This example adds SSO as an authentication method alongside the HTPasswd method configuredin the OpenShift Primer. Once configured, both methods will be available for user login to yourOpenShift web console.


15

https://access.redhat.com/documentation/en/red-hat-application-services/0/openshift-primer/#understand_roles_and_authentication

4.2.1. Configuring SSO Credentials

Log in to the encrypted SSO web server at https://secure-sso-sso-app-demo.openshift32.example.com/auth/admin using the admin user created during the SSOdeployment.

Create a Realm

1. Hover your cursor over the realm namespace (default is Master) at the top of the sidebarand click Add Realm.

2. Enter a realm name (this example uses OpenShift) and click Create.

Create a User

Create a test user that can be used to demonstrate the SSO-enabled OpenShift login:

1. Click Users in the Manage sidebar to view the user information for the realm.

2. Click Add User.

3. Enter a valid Username (this example uses testuser) and any additional optionalinformation and click Save.

4. Edit the user configuration:

a. Click the Credentials tab in the user space and enter a password for the user.

b. Ensure the Temporary Password option is set to Off so that it does not prompt fora password change later on, and click Reset Password to set the user password. Apop-up window prompts for additional confirmation.

Create and configure an OpenID-Connect Client

See the Manager Clients chapter of the Red Hat Single Sign-On Server Administration Guide] formore information.

1. Click Clients in the Manage sidebar and click Create.

2. Enter the Client ID. This example uses openshift-demo.

3. Select a Client Protocol from the drop-down menu (this example uses openid-connect)and click Save. You will be taken to the configuration Settings page of the openshift-democlient.

4. From the Access Type drop-down menu, select confidential. This is the access type forserver-side applications.

5. In the Valid Redirect URIs dialog, enter the URI for the OpenShift web console, which ishttps://openshift.example.com:8443/* in this example.

The client Secret is needed to configure OpenID-Connect on the OpenShift master in the nextsection. You can copy it now from under the Credentials tab. The secret is <7b0384a2-b832-16c5-9d73-2957842e89h7> for this example.

4.2.2. Configuring OpenShift Master for Single Sign-On Authentication


16

https://access.redhat.com/documentation/en/red-hat-single-sign-on/7.0/server-administration-guide/chapter-8-managing-clients

Log in to the OpenShift master CLI. You must have the required permissions to edit the/etc/origin/master/master-config.yaml file.

1. Edit the /etc/origin/master/master-config.yaml file and find the identityProviders. TheOpenShift master, which was deployed using the OpenShift Primer, is configured withHTPassword and shows the following:

identityProviders:- challenge: true login: true name: htpasswd_auth provider: apiVersion: v1 file: /etc/origin/openshift-passwd kind: HTPasswdPasswordIdentityProvider

Add SSO as a secondary identity provider with content similar to the following snippet:

- name: rh_sso challenge: false login: true mappingInfo: add provider: apiVersion: v1 kind: OpenIDIdentityProvider clientID: openshift-demo clientSecret: 7b0384a2-b832-16c5-9d73-2957842e89h7 ca: xpaas.crt urls: authorize: https://secure-sso-sso-app-demo.openshift32.example.com/auth/realms/OpenShift/protocol/openid-connect/auth token: https://secure-sso-sso-app-demo.openshift32.example.com/auth/realms/OpenShift/protocol/openid-connect/token userInfo: https://secure-sso-sso-app-demo.openshift32.example.com/auth/realms/OpenShift/protocol/openid-connect/userinfo claims: id: - sub preferredUsername: - preferred_username name: - name email: - email

a. The SSO Secret hash for the clientSecret can be found in the SSO web console:Clients → openshift-demo → Credentials

b. The endpoints for the urls can be found by making a request with the SSOapplication. For example:


17

<curl -k https://secure-sso-sso-app-demo.openshift32.example.com/auth/realms/OpenShift/.well-known/openid-configuration | python -m json.tool>

The response includes the authorization_endpoint, token_endpoint, anduserinfo_endpoint.

c. This example workflow uses a self-generated CA to provide an end-to-end workflowfor demonstration purposes. For this reason, the ca is provided as <ca: xpaas.crt>.This CA certificate must also be copied into the /etc/origin/master folder. This isnot necessary if using a certificate purchased from a verified Certificate Authority.

2. Save the configuration and restart the OpenShift master:

$ systemctl restart atomic-openshift-master

4.2.3. Logging in to OpenShift

Navigate to the OpenShift web console, which in this example ishttps://openshift.example.com:8443/console. The OpenShift login page now has the option to useeither htpasswd_auth or rh-sso. The former is still available because it is present in the/etc/origin/master/master-config.yaml.

Select rh-sso and log in to OpenShift with the testuser user created earlier in SSO. No projects arevisible to testuser until they are added in the OpenShift CLI. This is the only way to provide userprivileges in OpenShift because it currently does not accept external role mapping.

To provide testuser view privileges for the sso-app-demo, use the OpenShift CLI:

$ oadm policy add-role-to-user view testuser -n sso-app-demo

4.3. EXAMPLE WORKFLOW: AUTOMATICALLY REGISTERING EAPAPPLICATION IN SSO WITH OPENID-CONNECT CLIENT

This follows on from Example Workflow: Preparing and Deploying the RH-SSO for OpenShift image,in which SSO was deployed on OpenShift. This example prepares SSO realm, role, and usercredentials for an EAP project using an OpenID-Connect client adapter. These credentials are thenprovided in the EAP for OpenShift template for automatic SSO client registration. Once deployed,the SSO user can be used to authenticate and access JBoss EAP.

Note

This example uses a OpenID-Connect client but an SAML client could also be used. SeeSSO Clients and Automatic and Manual SSO Client Registration Methods for moreinformation on the differences between OpenID-Connect and SAML clients.





18

https://openshift.example.com:8443/console

$ oc new-project eap-app-demo


$ oc create serviceaccount eap-service-account


$ oc policy add-role-to-user view system:serviceaccount:eap-app-demo:eap-service-account

4. The EAP template requires an SSL keystore and a JGroups keystore.This example uses the same keystores and truststore that were created for the SSOdeployment in Example Workflow: Preparing and Deploying the RH-SSO for OpenShiftimage. To reiterate, this is to show an end-to-end workflow for demonstration purposes. Forproduction environments, Red Hat recommends that you use an SSL certificate purchasedfrom a verified Certificate Authority.Create the EAP secret with the SSL and JGroups keystore files created for the SSOdeployment, as well as the truststore:

$ oc create secret generic eap-app-secret --from-file=jgroups.jceks --from-file=sso-https.jks --from-file=truststore.jks

5. Add the EAP secret to the EAP service account created earlier:

$ oc secret add sa/eap-service-account secret/eap-app-secret

4.3.2. Preparing the SSO Credentials

Log in to the encrypted SSO web server at https://secure-sso-<project-name>.<hostname>/auth/admin using the admin user created during the SSO deployment.

Create a Realm

1. Hover your cursor over the realm namespace at the top of the sidebar and click*AddRealm*.

2. Enter a realm name (this example uses eap-demo) and click Create.

Copy the Public Key

In the newly created eap-demo realm, click the Keys tab and copy the public key that has beengenerated. This example uses the variable <realm-public-key> for brevity. This is used later todeploy the SSO-enabled JBoss EAP image.

Create a Role

Create a role in SSO with a name that corresponds to the JEE role defined in the web.xml of theexample EAP application. This role is assigned to an SSO application user to authenticate access touser applications.


19

1. Click Roles in the Configure sidebar to list the roles for this realm. This is a new realm, sothere should only be the default offline_access role.

2. Click Add Role.

3. Enter the role name (this example uses the role eap-user-role) and click Save.

Create Users and Assign Roles

Create two users: - Assign the realm management user the realm-management roles to handleautomatic SSO client registration in the SSO server. - Assign the application user the JEE role,created in the previous step, to authenticate access to user applications.

Create the realm management user:


2. Click Add User.

3. Enter a valid Username (this example uses the user eap-mgmt-user) and click Save.

4. Edit the user configuration. Click the Credentials tab in the user space and enter apassword for the user. After the password has been confirmed you can click ResetPassword to set the user password. A pop-up window prompts for additional confirmation.

5. Click Role Mappings to list the realm and client role configuration. In the Client Rolesdrop-down menu, select realm-management and add all of the available roles to the user.This provides the user SSO server rights that can be used by the JBoss EAP image tocreate clients.

Create the application user:


2. Click Add User.

3. Enter a valid Username and any additional optional information for the application user andclick Save.


5. Click Role Mappings to list the realm and client role configuration. In Available Roles, addthe role created earlier.

4.3.3. Deploy the SSO-enabled JBoss EAP Image

1. Return to the OpenShift web console and click Add to project to list all of the default imagestreams and templates.


3. Select the eap70-sso-s2i image to list all of the deployment parameters. Include thefollowing SSO parameters to configure the SSO credentials during the EAP build:


20


APPLICATION_NAME sso

HOSTNAME_HTTPS secure-sample-jsp.eap-app-demo.openshift32.example.com

HOSTNAME_HTTP sample-jsp.eap-app-demo.openshift32.example.com

SOURCE_REPOSITORY_URL https://repository-example.com/developer/application

SSO_URL https://secure-sso-sso-app-demo.openshift32.example.com/auth

SSO_REALM eap-demo

SSO_USERNAME eap-mgmt-user

SSO_PASSWORD password

SSO_PUBLIC_KEY <realm-public-key>

HTTPS_KEYSTORE sso-https.jks

HTTPS_PASSWORD password

HTTPS_SECRET sso-app-secret

JGROUPS_ENCRYPT_KEYSTORE jgroups.jceks

JGROUPS_ENCRYPT_PASSWORD password


21

JGROUPS_ENCRYPT_SECRET eap-app-secret

SERVICE_ACCOUNT_NAME eap-service-account


This example uses self-signed certificates and must additionally include information on thetruststore. These variables are not required with SSL certificates purchased from a verifiedCertificate Authority:


SSO_TRUSTSTORE truststore.jks

SSO_TRUSTSTORE_SECRET eap-app-secret

SSO_TRUSTSTORE_PASSWORD password

4. Click Create to deploy the JBoss EAP image.

It may take several minutes for the JBoss EAP image to deploy.

4.3.4. Log in to the JBoss EAP Server Using SSO

1. Access the JBoss EAP application server and click Login. You are redirected to the SSOlogin.

2. Log in using the SSO user created in the example. You are authenticated against the SSOserver and returned to the JBoss EAP application server.

4.4. EXAMPLE WORKFLOW: MANUALLY REGISTERING EAPAPPLICATION IN SSO WITH SAML CLIENT

This follows on from Example Workflow: Preparing and Deploying the RH-SSO for OpenShift image,in which SSO was deployed on OpenShift.

This example prepares SSO realm, role, and user credentials for an EAP project and configures anEAP for OpenShift deployment. Once deployed, the SSO user can be used to authenticate andaccess JBoss EAP.


22

Note

This example uses a SAML client but an OpenID-Connect client could also be used. SeeSSO Clients and Automatic and Manual SSO Client Registration Methods for moreinformation on the differences between SAML and OpenID-Connect clients.

4.4.1. Preparing the SSO Credentials

Log in to the encrypted SSO web server at https://secure-sso-<project-name>.<hostname>/auth/admin using the admin user created during the SSO deployment.

Create a Realm

1. Hover your cursor over the realm namespace (default is Master) at the top of the sidebarand click Add Realm.

2. Enter a realm name (this example uses saml-demo) and click Create.

Copy the Public Key

In the newly created saml-demo realm, click the Keys tab and copy the public key that has beengenerated. This example uses the variable realm-public-key for brevity. This is needed later todeploy the SSO-enabled JBoss EAP image.

Create a Role

Create a role in SSO with a name that corresponds to the JEE role defined in the web.xml of theexample EAP application. This role will be assigned to an SSO application user to authenticateaccess to user applications.

1. Click Roles in the Configure sidebar to list the roles for this realm. This is a new realm, sothere should only be the default offline_access role.

2. Click Add Role.

3. Enter the role name (this example uses the role saml-user-role) and click Save.

Create Users and Assign Roles

Create two users: - Assign the realm management user the realm-management roles to handleautomatic SSO client registration in the SSO server. - Assign the application user the JEE role,created in the previous step, to authenticate access to user applications.

Create the realm management user:


2. Click Add User.

3. Enter a valid Username (this example uses the user app-mgmt-user) and click Save.


Create the application user:


23


2. Click Add User.

3. Enter a valid Username and any additional optional information for the application user andclick Save.


5. Click Role Mappings to list the realm and client role configuration. In Available Roles, addthe role created earlier.

Create and Configure a SAML Client:

Clients are SSO entities that request user authentication. This example configures a SAML client tohandle authentication for the EAP application. This section saves two files, keystore.jks andkeycloak-saml-subsystem.xml that are needed later in the procedure.

Create the SAML Client:

1. Click Clients in the Configure sidebar to list the clients in the realm. Click Create.

2. Enter a valid Client ID. This example uses sso-saml-demo.

3. In the Client Protocol drop-down menu, select saml.

4. Enter the Root URL for the application. This example uses https://demoapp-eap-app-demo.openshift32.example.com.

5. Click Save.

Configure the SAML Client:

In the Settings tab, set the Root URL and the Valid Redirect URLs for the new sso-saml-democlient:

1. For the Root URL, enter the same address used when creating the client. This exampleuses https://demoapp-eap-app-demo.openshift32.example.com.

2. For the Valid Redirect URLs, enter an address for users to be redirected to at when theylog in or out. This example uses a redirect address relative to the root https://demoapp-eap-app-demo.openshift32.example.com/*.

Export the SAML Keys:

1. Click the SAML Keys tab in the sso-saml-demo client space and click Export.

2. For this example, leave the Archive Format as JKS. This example uses the default KeyAlias of sso-saml-demo and default Realm Certificate Alias of saml-demo.

3. Enter the Key Password and the Store Password. This example uses password for both.

4. Click Download and save the keystore.jks file for use later.

5. Click the sso-saml-demo client to return to the client space ready for the next step.

Download the Client Adapter:


24

1. Click Installation.

2. Use the Format Option drop-down menu to select a format. This example uses KeycloakSAML Wildfly/JBoss Subsystem.

3. Click Download and save the file keycloak-saml-subsystem.xml.

The keystore.jks will be used with the other SSO keystores in the next section to create anOpenShift secret for the EAP application project. Copy it to an OpenShift node as saml.jks.The keycloak-saml-subsystem.xml will be modified and used in the application deployment. Copyit into the /configuration folder of the application as secure-saml-deployments.




$ oc new-project eap-app-demo


$ oc create serviceaccount app-service-account


$ oc policy add-role-to-user view system:serviceaccount:eap-app-demo:app-service-account

4. The EAP application template requires three keystores:

An SSL keystore to provide private and public keys to encrypt https traffic. This exampleuses sso-https.jks.

A JGroups keystore for encrypting network traffic between nodes in the cluster. Thisexample uses jgroups.ceks.

The SAML keys for the SSO client, exported in the previous section. This example usessaml.jks.

Note

This example uses two keystores that were created for the SSO deployment.It also requires the truststore.jks created for the SSO deployment becausethe certificates were self-signed for the purpose of this example. To reiterate,this is to show an end-to-end workflow for demonstration purposes. Forproduction environments, Red Hat recommends that you use an SSLcertificate purchased from a verified Certificate Authority, in which case thetruststore would not be specified in the secret.

Create the EAP secret with the SSL and JGroups keystore files and the truststore filecreated for the SSO deployment, and the SAML keystore file exported from the SSOclient and renamed saml.jks:


25

$ oc secrets new eap-app-secret \keystore.jks=sso-https.jks \jgroups.jceks=jgroups.jceks \truststore.jks=truststore.jks \saml.jks=saml.jks

5. Add the EAP application secret to the EAP service account created earlier:

$ oc secret add sa/app-service-account secret/eap-app-secret

4.4.3. Modifying the secure-saml-deployments File

The keycloak-saml-subsystem.xml, exported from the SSO client in a previous section, shouldhave been copied into the /configuration folder of the application and renamed secure-saml-deployments. EAP searches for this file when it starts and copies it to the standalone-openshift.xml file inside the SSO SAML adapter configuration.

1. Open the /configuration/secure-saml-deployments file in a text editor.

2. Replace the YOUR-WAR.war value of the secure-deployment name tag with theapplication .war file. This example uses sso-saml-demo.war.

3. Replace the SPECIFY YOUR LOGOUT PAGE! value of the logout page tag with the url toredirect users when they log out of the application. This example uses /index.jsp.

4. Delete the <PrivateKeyPem> and <CertificatePem> tags and keys and replace it withkeystore information:

...<Keys> <Key signing="true"> <KeyStore file= "/etc/eap-secret-volume/saml.jks" password="password"> <PrivateKey alias="sso-saml-demo" password="password"/> <Certificate alias="sso-saml-demo"/> </KeyStore> </Key></Keys>

The mount path of the saml.jks (in this example /etc/eap-secret-volume/saml.jks) can bespecified in the application template with the parameter EAP_HTTPS_KEYSTORE_DIR.The aliases and passwords for the PrivateKey and the Certificate were configured whenthe SAML Keys were exported from the SSO client.

5. Delete the second <CertificatePem> tag and key and replace it with the the realmcertificate information:

...<Keys> <Key signing="true"> <KeyStore file="/etc/eap-secret-volume/saml.jks" password="password"> <Certificate alias="saml-demo"/> </KeyStore> </Key>


26

</Keys>...

The certificate alias and password were configured when the SAML Keys were exportedfrom the SSO client.

6. Save and close the /configuration/secure-saml-deployments file.

4.4.4. Configuring SAML Client Registration in the Application web.xml

The client type must also be specified by the <auth-method> key in the application web.xml. Thisfile is read by the image at deployment.

Open the application web.xml file and ensure it includes the following:

...<login-config> <auth-method>KEYCLOAK-SAML</auth-method></login-config>...

4.4.5. Deploying the Application

You do not need to include any SSO configuration for the image because that has been configuredin the application itself. Navigating to the application login page redirects you to the SSO login. Login to the application through SSO using the application user user created earlier.


27

CHAPTER 5. REFERENCE

5.1. ENVIRONMENT VARIABLES

5.1.1. Template variables for all SSO images


APPLICATION_NAME The name for the application.

DB_MAX_POOL_SIZE Sets xa-pool/max-pool-size for the configureddatasource.

DB_TX_ISOLATION Sets transaction-isolation for the configureddatasource.

DB_USERNAME Database user name

HOSTNAME_HTTP Custom hostname for http service route. Leaveblank for default hostname, e.g.: <application-name>.<project>.<default-domain-suffix>

HOSTNAME_HTTPS Custom hostname for https service route. Leaveblank for default hostname, e.g.: <application-name>.<project>.<default-domain-suffix>

HTTPS_KEYSTORE The name of the keystore file within the secret. Ifdefined along with HTTPS_PASSWORD andHTTPS_NAME, enable HTTPS and set the SSLcertificate key file to a relative path under$JBOSS_HOME/standalone/configuration

HTTPS_KEYSTORE_TYPE The type of the keystore file (JKS or JCEKS)

HTTPS_NAME The name associated with the server certificate(e.g. jboss). If defined along withHTTPS_PASSWORD and HTTPS_KEYSTORE,enable HTTPS and set the SSL name.


28

HTTPS_PASSWORD The password for the keystore and certificate (e.g.mykeystorepass). If defined along withHTTPS_NAME and HTTPS_KEYSTORE, enableHTTPS and set the SSL key password.

HTTPS_SECRET The name of the secret containing the keystore file

IMAGE_STREAM_NAMESPACE Namespace in which the ImageStreams for RedHat Middleware images are installed. TheseImageStreams are normally installed in theopenshift namespace. You should only need tomodify this if you have installed the ImageStreamsin a different namespace/project.

JGROUPS_CLUSTER_PASSWORD JGroups cluster password

JGROUPS_ENCRYPT_KEYSTORE The name of the keystore file within the secret

JGROUPS_ENCRYPT_NAME The name associated with the server certificate(e.g. secret-key)

JGROUPS_ENCRYPT_PASSWORD The password for the keystore and certificate (e.g.password)

JGROUPS_ENCRYPT_SECRET The name of the secret containing the keystore file

SERVICE_ACCOUNT_NAME The name of the service account to use for thedeployment. The service account should beconfigured to allow usage of the secret(s) specifiedby HTTPS_SECRET andJGROUPS_ENCRYPT_SECRET.

SSO_ADMIN_USERNAME SSO Server admin username

SSO_ADMIN_PASSWORD SSO Server admin password



29

SSO_REALM SSO Realm

SSO_SERVICE_USERNAME SSO service username

SSO_SERVICE_PASSWORD SSO service password

SSO_TRUSTSTORE The name of the truststore file within the secret(e.g. /etc/sso-secret-volume/truststore.jks )

SSO_TRUSTSTORE_SECRET The name of the secret containing the truststorefile (e.g. truststore-secret). Used for volumesecretName

SSO_TRUSTSTORE_PASSWORD The password for the truststore and certificate (e.g.mykeystorepass)


5.1.2. Template variables specific to sso70-mysql and sso70-mysql-persistent



DB_PASSWORD Database user password

DB_JNDI Database JNDI name used by application toresolve the datasource, e.g.java:/jboss/datasources/mysql

MYSQL_AIO Controls the innodb_use_native_aio setting value ifthe native AIO is broken.

MYSQL_FT_MAX_WORD_LEN The maximum length of the word to be included ina FULLTEXT index.


30

MYSQL_FT_MIN_WORD_LEN The minimum length of the word to be included in aFULLTEXT index.

MYSQL_LOWER_CASE_TABLE_NAMES Sets how the table names are stored andcompared.

MYSQL_MAX_CONNECTIONS The maximum permitted number of simultaneousclient connections.


5.1.3. Template variables specific to sso70-postgresql and sso70-postgresql-persistent



DB_PASSWORD Database user password

DB_JNDI Database JNDI name used by application toresolve the datasource, e.g.java:/jboss/datasources/postgresql

POSTGRESQL_MAX_CONNECTIONS The maximum number of client connectionsallowed. This also sets the maximum number ofprepared transactions.

POSTGRESQL_SHARED_BUFFERS Configures how much memory is dedicated toPostgreSQL for caching data.

5.1.4. Template variables specific to sso70-mysql-persistent and sso70-postgresql-persistent


31


VOLUME_CAPACITY Size of persistent storage for database volume.

5.1.5. Template variables for general eap64 and eap70 s2i images


APPLICATION_NAME The name for the application.

ARTIFACT_DIR Artifacts

AUTO_DEPLOY_EXPLODED Controls whether exploded deployment contentshould be automatically deployed

CONTEXT_DIR Path within Git project to build; empty for rootproject directory.

GENERIC_WEBHOOK_SECRET Generic build trigger secret

GITHUB_WEBHOOK_SECRET GitHub trigger secret

HORNETQ_CLUSTER_PASSWORD HornetQ cluster admin password

HORNETQ_QUEUES Queue names

HORNETQ_TOPICS Topic names

HOSTNAME_HTTP Hostname for http service route. Required for SSO-enabled applications

HOSTNAME_HTTPS Hostname for https service route. Required forSSO-enabled applications


32

HTTPS_KEYSTORE_TYPE The type of the keystore file (JKS or JCEKS)

HTTPS_KEYSTORE The name of the keystore file within the secret.

HTTPS_NAME The name associated with the server certificate(e.g. jboss)

HTTPS_PASSWORD The password for the keystore and certificate (e.g.mykeystorepass)

HTTPS_SECRET The name of the secret containing the keystore file

IMAGE_STREAM_NAMESPACE Namespace in which the ImageStreams for RedHat Middleware images are installed. TheseImageStreams are normally installed in theopenshift namespace. You should only need tomodify this if you’ve installed the ImageStreams ina different namespace/project.

JGROUPS_CLUSTER_PASSWORD JGroups cluster password

JGROUPS_ENCRYPT_KEYSTORE The name of the keystore file within the secret

JGROUPS_ENCRYPT_NAME The name associated with the server certificate(e.g. secret-key)

JGROUPS_ENCRYPT_PASSWORD The password for the keystore and certificate (e.g.password)

JGROUPS_ENCRYPT_SECRET The name of the secret containing the keystore file



33

SERVICE_ACCOUNT_NAME The name of the service account to use for thedeployment. The service account should beconfigured to allow usage of the secret(s) specifiedby HTTPS_SECRET andJGROUPS_ENCRYPT_SECRET.

SOURCE_REPOSITORY_REF Git branch/tag reference

SOURCE_REPOSITORY_URL Git source URI for application


5.1.6. Template variables specific to eap64-sso-s2i and eap70-sso-s2i forautomatic client registration


SSO_URL SSO Location

SSO_REALM SSO Realm

SSO_USERNAME SSO Username

SSO_PASSWORD SSO Password

SSO_PUBLIC_KEY SSO Public Key. Public key is recommended to bepassed into the template to avoid man-in-the-middle security vulnerability

SSO_SECRET The SSO Client Secret for Confidential Access

SSO_SERVICE_URL SSO Service Location

SSO_TRUSTSTORE_SECRET The name of the secret containing the truststorefile (e.g. truststore-secret). Used for volumesecretName


34

SSO_TRUSTSTORE The name of the truststore file within the secret(e.g. truststore.jks)

SSO_TRUSTSTORE_PASSWORD The password for the truststore and certificate (e.g.mykeystorepass)

SSO_BEARER_ONLY SSO Client Access Type

SSO_DISABLE_SSL_CERTIFICATE_VALIDATION

If true SSL communication between EAP and theSSO Server will be insecure (i.e. certificatevalidation is disabled with curl)

SSO_ENABLE_CORS Enable CORS for SSO applications


5.1.7. Template variables specific to eap64-sso-s2i and eap70-sso-s2i forautomatic client registration with SAML clients


SSO_SAML_CERTIFICATE_NAME The name associated with the server certificate

SSO_SAML_KEYSTORE_PASSWORD The password for the keystore and certificate

SSO_SAML_KEYSTORE The name of the keystore file within the secret

SSO_SAML_KEYSTORE_SECRET The name of the secret containing the keystore file

SSO_SAML_LOGOUT_PAGE SSO logout page for SAML applications


35

red hat jboss middleware for openshift 3 red hat jboss sso ... · red hat jboss middleware for...

Documents