Chapter 3. Performing advanced procedures

In the following oc command, the values of SSO_ADMIN_USERNAME, SSO_ADMIN_PASSWORD, HTTPS_PASSWORD, JGROUPS_ENCRYPT_PASSWORD, and SSO_TRUSTSTORE_PASSWORD variables match the default values from the sso76-ocp4-https Red Hat Single Sign-On application template.

For production environments, Red Hat recommends that you consult the on-site policy for your organization for guidance on generating a strong user name and password for the administrator user account of the Red Hat Single Sign-On server, and passwords for the HTTPS and JGroups keystores, and the truststore of the Red Hat Single Sign-On server.

Also, when you create the template, make the passwords match the passwords provided when you created the keystores. If you used a different username or password, modify the values of the parameters in your template to match your environment.

$ keytool -v -list -keystore keystore.jks | grep Alias
Enter keystore password:  mykeystorepass
Alias name: xpaas.ca
Alias name: jboss

$ keytool -v -list -keystore jgroups.jceks -storetype jceks | grep Alias
Enter keystore password:  password
Alias name: secret-key

$ oc new-app --template=sso76-ocp4-https \
 -p HTTPS_SECRET="sso-app-secret" \
 -p HTTPS_KEYSTORE="keystore.jks" \
 -p HTTPS_NAME="jboss" \
 -p HTTPS_PASSWORD="mykeystorepass" \
 -p JGROUPS_ENCRYPT_SECRET="sso-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="sso-app-secret"
--> Deploying template "openshift/sso76-ocp4-https" to project sso-app-demo

     Red Hat Single Sign-On 7.6.8 (Ephemeral with passthrough TLS)
     ---------
     An example Red Hat Single Sign-On 7 application. For more information about using this template, see https://github.com/jboss-openshift/application-templates.

     A new Red Hat Single Sign-On service has been created in your project. The admin username/password for accessing the master realm via the Red Hat Single Sign-On console is admin/redhat. Please be sure to create the following secrets: "sso-app-secret" containing the keystore.jks file used for serving secure content; "sso-app-secret" containing the jgroups.jceks file used for securing JGroups communications; "sso-app-secret" containing the truststore.jks file used for securing Red Hat Single Sign-On requests.

     * With parameters:
        * Application Name=sso
        * Custom http Route Hostname=
        * Custom https Route Hostname=
        * Server Keystore Secret Name=sso-app-secret
        * Server Keystore Filename=keystore.jks
        * Server Keystore Type=
        * Server Certificate Name=jboss
        * Server Keystore Password=mykeystorepass
        * Datasource Minimum Pool Size=
        * Datasource Maximum Pool Size=
        * Datasource Transaction Isolation=
        * JGroups Secret Name=sso-app-secret
        * JGroups Keystore Filename=jgroups.jceks
        * JGroups Certificate Name=secret-key
        * JGroups Keystore Password=password
        * JGroups Cluster Password=yeSppLfp # generated
        * ImageStream Namespace=openshift
        * Red Hat Single Sign-On Administrator Username=admin
        * Red Hat Single Sign-On Administrator Password=redhat
        * Red Hat Single Sign-On Realm=demorealm
        * Red Hat Single Sign-On Service Username=
        * Red Hat Single Sign-On Service Password=
        * Red Hat Single Sign-On Trust Store=truststore.jks
        * Red Hat Single Sign-On Trust Store Password=mykeystorepass
        * Red Hat Single Sign-On Trust Store Secret=sso-app-secret
        * Container Memory Limit=1Gi

--> Creating resources ...
    service "sso" created
    service "secure-sso" created
    service "sso-ping" created
    route "sso" created
    route "secure-sso" created
    deploymentconfig "sso" created
--> Success
    Run 'oc status' to view your app.

For DNS_PING to work on IPv4 or IPv6 single-stack cluster, the following steps must be taken:

kind: Service
apiVersion: v1
spec:
    clusterIP: None
    ipFamilyPolicy: SingleStack
    ports:
    - name: ping
      port: 8888
    publishNotReadyAddresses: true
    selector:
        deploymentConfig: sso
metadata:
    name: sso-ping
    annotations:
        description: "The JGroups ping port for clustering."

Moreover, for the DNS_PING to work also on dual-network clusters that support both IPv4 and IPv6 address families, the spec.ipFamilyPolicy field of the ping service for the cluster must be set to PreferDualStack or RequireDualStack. This setting ensures the control plane assigns both IPv4 and IPv6 cluster IP addresses for the ping service on clusters that have dual-stack configured, enables reverse DNS lookups for both IPv4 and IPv6 IP addresses to work properly, and creates corresponding DNS SRV records for the ping headless service as illustrated below:

$ host -t SRV "${OPENSHIFT_DNS_PING_SERVICE_NAME}"
sso-ping.dual-stack-demo.svc.cluster.local has SRV record 0 50 8888 10-128-0-239.sso-ping.dual-stack-demo.svc.cluster.local.
sso-ping.dual-stack-demo.svc.cluster.local has SRV record 0 50 8888 fd01-0-0-1--b8.sso-ping.dual-stack-demo.svc.cluster.local.

kind: Service
apiVersion: v1
spec:
    clusterIP: None
    ipFamilyPolicy: PreferDualStack
    ports:
    - name: ping
      port: 8888
    publishNotReadyAddresses: true
    selector:
        deploymentConfig: sso
metadata:
    name: sso-ping
    annotations:
        description: "The JGroups ping port for clustering."

For KUBE_PING to work, the following steps must be taken:

oc policy add-role-to-user view system:serviceaccount:myproject:default -n myproject

oc policy add-role-to-user view system:serviceaccount:myproject:sso-service-account -n myproject

Refer to a dedicated section of JBoss EAP for OpenShift documentation to:

Automatic Red Hat Single Sign-On client registration is determined by Red Hat Single Sign-On environment variables specific to the eap64-sso-s2i, eap71-sso-s2i, and datavirt63-secure-s2i templates. The Red Hat Single Sign-On credentials supplied in the template are then used to register the client to the Red Hat Single Sign-On realm during deployment of the client application.

The Red Hat Single Sign-On environment variables included in the eap64-sso-s2i, eap71-sso-s2i, and datavirt63-secure-s2i templates are:

If the Red Hat Single Sign-On client uses the SAML protocol, the following additional variables need to be configured:

See Example Workflow: Automatically Registering EAP Application in Red Hat Single Sign-On with OpenID-Connect Client for an end-to-end example of the automatic client registration method using an OpenID-Connect client.

Manual Red Hat Single Sign-On client registration is determined by the presence of a deployment file in the client application’s ../configuration/ directory. These files are exported from the client adapter in the Red Hat Single Sign-On web console. The name of this file is different for OpenID-Connect and SAML clients:

These files are copied to the Red Hat Single Sign-On adapter configuration section in the standalone-openshift.xml at when the application is deployed.

There are two methods for passing the Red Hat Single Sign-On adapter configuration to the client application:

See Example Workflow: Manually Configure an Application to Use Red Hat Single Sign-On Authentication, Using SAML Client for an end-to-end example of the manual Red Hat Single Sign-On client registration method using a SAML client.