Chapter 3. Get Started

3.1. Using the Red Hat Single Sign-On for OpenShift Image Streams and Application Templates

Important

Red Hat JBoss Middleware for OpenShift images are pulled on demand from the secured Red Hat Registry: registry.redhat.io, which requires authentication. To retrieve content, you will need to log into the registry using the Red Hat account.

To consume container images from registry.redhat.io in shared environments such as OpenShift, it is recommended for an administrator to use a Registry Service Account, also referred to as authentication tokens, in place of an individual person’s Red Hat Customer Portal credentials.

To create a Registry Service Account, navigate to the Registry Service Account Management Application, and log in if necessary.

  1. From the Registry Service Accounts page, click Create Service Account.
  2. Provide a name for the Service Account, for example registry.redhat.io-sa. It will be prepended with a fixed, random string.

    1. Enter a description for the Service Account, for example Service account to consume container images from registry.redhat.io..
    2. Click Create.
  3. After the Service Account was created, click the registry.redhat.io-sa link in the Account name column of the table presented on the Registry Service Accounts page.
  4. Finally, click the OpenShift Secret tab, and perform all steps listed on that page.

See the Red Hat Container Registry Authentication article for more information.

To update to the latest Red Hat Single Sign-On for OpenShift images, run the following commands:

  1. On your master host(s), ensure that you are logged in as a cluster administrator or a user with project administrator access to the global openshift project.

    $ oc login -u system:admin
  2. Run the following commands to update the core set of Red Hat Single Sign-On 7.3.0.GA resources for OpenShift in the openshift project:

    $ for resource in sso73-image-stream.json \
      sso73-https.json \
      sso73-mysql.json \
      sso73-mysql-persistent.json \
      sso73-postgresql.json \
      sso73-postgresql-persistent.json \
      sso73-x509-https.json \
      sso73-x509-mysql-persistent.json \
      sso73-x509-postgresql-persistent.json
    do
      oc replace -n openshift --force -f \
      https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/sso73-dev/templates/${resource}
    done
  3. Run the following command to install the Red Hat Single Sign-On 7.3.0.GA OpenShift image streams in the openshift project:

    $ oc -n openshift import-image redhat-sso73-openshift:1.0

3.2. Preparing and Deploying the Red Hat Single Sign-On for OpenShift Application Templates

3.2.1. Configuring Keystores

The Red Hat Single Sign-On 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 between nodes in the cluster.

These keystores are expected by the Red Hat Single Sign-On for OpenShift image, even if the application uses only http on a single-node OpenShift instance. Self-signed certificates do not provide secure communication and are intended for internal testing purposes.

Warning

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

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

3.2.2. Generating Secrets

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

The Red Hat Single Sign-On for OpenShift image requires one or more secrets that hold the two keystores described earlier. This provides the necessary authorization to applications in the project.

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

$ oc secret new <sso-ssl-secret> <ssl.jks>
$ oc secret new <sso-jgroups-secret> <jgroups.jceks>

3.2.3. Using the OpenShift Web Console

Log in to the OpenShift web console:

  1. Click Add to project to list the default image streams and templates.
  2. Use the Filter by keyword search bar to limit the list to those that match sso. You may need 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 Red Hat Single Sign-On deployment:

VariableDescription

APPLICATION_NAME

The name for the Red Hat Single Sign-On application.

HOSTNAME_HTTPS

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

HOSTNAME_HTTP

Custom hostname for http service route. Leave blank 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 the secret.

JGROUPS_ENCRYPT_PASSWORD

The password for the JGroups keystore and certificate.

JGROUPS_ENCRYPT_SECRET

The name of the secret containing the JGroups keystore file.

SSO_ADMIN_USERNAME

Username of the administrator account for the master realm of the Red Hat Single Sign-On server. Required. If no value is specified, it is auto generated and displayed as an OpenShift instructional message when the template is instantiated.

SSO_ADMIN_PASSWORD

Password of the administrator account for the master realm of the Red Hat Single Sign-On server. Required. If no value is specified, it is auto generated and displayed as an OpenShift instructional message when the template is instantiated.

SSO_REALM

The name of an additional Red Hat Single Sign-On realm to create during deployment.

SSO_SERVICE_USERNAME

Red Hat Single Sign-On service user name to manage the realm.

SSO_SERVICE_PASSWORD

Red Hat Single Sign-On service user password.

See the Reference chapter for a more comprehensive list of the Red Hat Single Sign-On environment variables. See the Example Workflow: Preparing and Deploying the Red Hat Single Sign-On for OpenShift Image for an end-to-end example of Red Hat Single Sign-On deployment.

3.2.4. Routes

The Red Hat Single Sign-On for OpenShift templates use TLS passthrough termination for routes by default. This means that the destination route receives encrypted traffic without the OpenShift router providing TLS termination. Users do not need the relevant SSL certificate to connect to the Red Hat Single Sign-On login page.

For more information on OpenShift route types, see the Networking chapter of the OpenShift Architecture Guide.

3.3. Binary Builds

To deploy existing applications on OpenShift, you can use the binary source capability.

3.3.1. Deploy Binary Build of EAP 6.4 / 7.1 JSP Service Invocation Application that Authenticates Using Red Hat Single Sign-On

The following example uses both app-jee-jsp and service-jee-jaxrs quickstarts to deploy EAP 6.4 / 7.1 JSP service application that authenticates using the Red Hat Single Sign-On.

Prerequisite:

Important

This guide assumes the Red Hat Single Sign-On for OpenShift image has been previously deployed using one of the following templates:

  • sso73-mysql
  • sso73-postgresql
  • sso73-mysql-persistent
  • sso73-x509-mysql-persistent
  • sso73-postgresql-persistent
  • sso73-x509-postgresql-persistent

3.3.1.1. Create Red Hat Single Sign-On Realm, Roles, and User for the EAP 6.4 / 7.1 JSP Application

The EAP 6.4 / 7.1 JSP service application requires dedicated Red Hat Single Sign-On realm, username, and password to be able to authenticate using Red Hat Single Sign-On. Perform the following steps after the Red Hat Single Sign-On for OpenShift image has been deployed:

Create the Red Hat Single Sign-On Realm

  1. Login to the administration console of the Red Hat Single Sign-On server.

    https://secure-sso-sso-app-demo.openshift.example.com/auth/admin

    Use the credentials of the Red Hat Single Sign-On administrator user.

  2. Hover your cursor over the realm namespace (default is Master) at the top of the sidebar and click Add Realm.
  3. Enter a realm name (this example uses demo) and click Create.

Copy the Public Key

In the newly created demo realm, click the Keys tab, then select Active tab, and copy the public key of type RSA that has been generated.

Note

The Red Hat Single Sign-On for OpenShift image version 7.3.0.GA generates multiple keys by default, for example HS256, RS256, or AES. To copy the public key information for the Red Hat Single Sign-On for OpenShift 7.3.0.GA image, click the Keys tab, then select Active tab, and click the Public key button of that row in the keys table, where type of the key matches RSA. Then select and copy the content of the pop-up window that appears.

The information about the public key is necessary later to deploy the Red Hat Single Sign-On-enabled EAP 6.4 / 7.1 JSP application.

Create Red Hat Single Sign-On Roles

Note

The service-jee-jaxrs quickstart exposes three endpoints by the service:

  • public - Requires no authentication.
  • secured - Can be invoked by users with the user role.
  • admin - Can be invoked by users with the admin role.

Create user and admin roles in Red Hat Single Sign-On. These roles will be assigned to an Red Hat Single Sign-On application user to authenticate access to user applications.

  1. Click Roles in the Configure sidebar to list the roles for this realm.

    Note

    This is a new realm, so there should only be the default (offline_access and uma_authorization) roles.

  2. Click Add Role.
  3. Enter the role name (user) and click Save.

Repeat these steps for the admin role.

Create the Red Hat Single Sign-On Realm Management User

  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 the user appuser) and click Save.
  4. Edit the user configuration:

    1. Click the Credentials tab in the user space and enter a password for the user (this example uses the password apppassword).
    2. Ensure the Temporary Password option is set to Off so that it does not prompt for a password change later on, and click Reset Password to set the user password. A pop-up window prompts for additional confirmation.

3.3.1.2. Assign user Red Hat Single Sign-On Role to the Realm Management User

Perform the following steps to tie the previously created appuser with the user Red Hat Single Sign-On role:

  1. Click Role Mappings to list the realm and client role configuration. In Available Roles, select the user role created earlier, and click Add selected>.
  2. Click Client Roles, select realm-management entry from the list, select each record in the Available Roles list.

    Note

    You can select multiple items at once by holding the Ctrl key and simultaneously clicking the first impersonation entry. While keeping the Ctrl key and the left mouse button pressed, move to the end of the list to the view-clients entry and ensure each record is selected.

  3. Click Add selected> to assign the roles to the client.

3.3.1.3. Prepare Red Hat Single Sign-On Authentication for OpenShift Deployment of the EAP 6.4 / 7.1 JSP Application

  1. Create a new project for the EAP 6.4 / 7.1 JSP application.

    $ oc new-project eap-app-demo
  2. Add the view role to the default service account. This enables the service account to view all the resources in the eap-app-demo namespace, which is necessary for managing the cluster.

    $ oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default
  3. The EAP template requires an SSL keystore and a JGroups keystore. This example uses keytool, a package included with the Java Development Kit, to generate self-signed certificates for these keystores.

    1. Generate a secure key for the SSL keystore (this example uses password as password for the keystore).

      $ keytool -genkeypair \
      -dname "CN=secure-eap-app-eap-app-demo.openshift.example.com" \
      -alias https \
      -storetype JKS \
      -keystore eapkeystore.jks
    2. Generate a secure key for the JGroups keystore (this example uses password as password for the keystore).

      $ keytool -genseckey \
      -alias jgroups \
      -storetype JCEKS \
      -keystore eapjgroups.jceks
    3. Generate the EAP 6.4 / 7.1 for OpenShift secrets with the SSL and JGroup keystore files.

      $ oc secret new eap-ssl-secret eapkeystore.jks
      $ oc secret new eap-jgroup-secret eapjgroups.jceks
    4. Add the EAP application secret to the default service account.

      $ oc secrets link default eap-ssl-secret eap-jgroup-secret

3.3.1.4. Deploy Binary Build of the EAP 6.4 / 7.1 JSP Application

  1. Clone the source code.

    $ git clone https://github.com/keycloak/keycloak-quickstarts.git
  2. Configure the Red Hat JBoss Middleware Maven repository.
  3. Build both the service-jee-jaxrs and app-jee-jsp applications.

    1. Build the service-jee-jaxrs application.

      $ cd keycloak-quickstarts/service-jee-jaxrs/
      $ mvn clean package -DskipTests
      [INFO] Scanning for projects...
      [INFO]
      [INFO] ------------------------------------------------------------------------
      [INFO] Building Keycloak Quickstart: service-jee-jaxrs 3.1.0.Final
      [INFO] ------------------------------------------------------------------------
      ...
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESS
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 2.153 s
      [INFO] Finished at: 2017-06-26T12:06:12+02:00
      [INFO] Final Memory: 25M/241M
      [INFO] ------------------------------------------------------------------------
    2. Comment out the app-jee-jsp/config/keycloak.json requirement of the maven-enforcer-plugin plugin and build the app-jee-jsp application.

      service-jee-jaxrs]$ cd ../app-jee-jsp/
      app-jee-jsp]$ sed -i /\<executions\>/s/^/\<\!--/ pom.xml
      app-jee-jsp]$ sed -i '/\(<\/executions>\)/a\-->' pom.xml
      app-jee-jsp]$ mvn clean package -DskipTests
      [INFO] Scanning for projects...
      [INFO]
      [INFO] ------------------------------------------------------------------------
      [INFO] Building Keycloak Quickstart: app-jee-jsp 3.1.0.Final
      [INFO] ------------------------------------------------------------------------
      ...
      [INFO] Building war: /tmp/github/keycloak-quickstarts/app-jee-jsp/target/app-jsp.war
      [INFO] ------------------------------------------------------------------------
      [INFO] BUILD SUCCESS
      [INFO] ------------------------------------------------------------------------
      [INFO] Total time: 3.018 s
      [INFO] Finished at: 2017-06-26T12:22:25+02:00
      [INFO] Final Memory: 35M/310M
      [INFO] ------------------------------------------------------------------------
      Important

      The app-jee-jsp quickstart requires to configure the adapter, and adapter configuration file (keycloak.json) to be present at the config/ directory in the root of the quickstart to successfully build the quickstart. But since this example configures the adapter later via selected environment variables available for the EAP 6.4 / 7.1 for OpenShift image, it is not necessary to specify the form of keycloak.json adapter configuration file at this moment.

  1. Prepare the directory structure on the local file system.

    Application archives in the deployments/ subdirectory of the main binary build directory are copied directly to the standard deployments directory of the image being built on OpenShift. For the application to deploy, the directory hierarchy containing the web application data must be correctly structured.

    Create main directory for the binary build on the local file system and deployments/ subdirectory within it. Copy the previously built WAR archives of both the service-jee-jaxrs and app-jee-jsp quickstarts to the deployments/ subdirectory:

    app-jee-jsp]$ ls
    config  pom.xml  README.md  src  target
    app-jee-jsp]$ mkdir -p sso-eap7-bin-demo/deployments
    app-jee-jsp]$ cp target/app-jsp.war sso-eap7-bin-demo/deployments/
    app-jee-jsp]$ cp ../service-jee-jaxrs/target/service.war sso-eap7-bin-demo/deployments/
    app-jee-jsp]$ tree sso-eap7-bin-demo/
    sso-eap7-bin-demo/
    |__ deployments
        |__ app-jsp.war
        |__ service.war
    
    1 directory, 2 files
    Note

    Location of the standard deployments directory depends on the underlying base image, that was used to deploy the application. See the following table:

    Table 3.1. Standard Location of the Deployments Directory

    Name of the Underlying Base Image(s)Standard Location of the Deployments Directory

    EAP for OpenShift 6.4 and 7.1

    $JBOSS_HOME/standalone/deployments

    Java S2I for OpenShift

    /deployments

    JWS for OpenShift

    $JWS_HOME/webapps

  2. Identify the image stream for EAP 6.4 / 7.1 image.

    $ oc get is -n openshift | grep eap | cut -d ' ' -f 1
    jboss-eap64-openshift
    jboss-eap71-openshift
  1. Create new binary build, specifying image stream and application name.

    Note

    Replace --image-stream=jboss-eap71-openshift parameter with the --image-stream=jboss-eap64-openshift one in the following oc command to deploy the JSP application on top of JBoss EAP 6.4 for OpenShift image.

    $ oc new-build --binary=true \
    --image-stream=jboss-eap71-openshift \
    --name=eap-app
    --> Found image 31895a4 (3 months old) in image stream "openshift/jboss-eap71-openshift" under tag "latest" for "jboss-eap71-openshift"
    
        JBoss EAP 7.1
        -------------
        Platform for building and running JavaEE applications on JBoss EAP 7.1
    
        Tags: builder, javaee, eap, eap7
    
        * A source build using binary input will be created
          * The resulting image will be pushed to image stream "eap-app:latest"
          * A binary build was created, use 'start-build --from-dir' to trigger a new build
    
    --> Creating resources with label build=eap-app ...
        imagestream "eap-app" created
        buildconfig "eap-app" created
    --> Success
  2. Start the binary build. Instruct oc executable to use main directory of the binary build we created in previous step as the directory containing binary input for the OpenShift build. In the working directory of app-jee-jsp issue the following command.

    app-jee-jsp]$ oc start-build eap-app \
    --from-dir=./sso-eap7-bin-demo/ \
    --follow
    Uploading directory "sso-eap7-bin-demo" as binary input for the build ...
    build "eap-app-1" started
    Receiving source from STDIN as archive ...
    Copying all war artifacts from /home/jboss/source/. directory into /opt/eap/standalone/deployments for later deployment...
    Copying all ear artifacts from /home/jboss/source/. directory into /opt/eap/standalone/deployments for later deployment...
    Copying all rar artifacts from /home/jboss/source/. directory into /opt/eap/standalone/deployments for later deployment...
    Copying all jar artifacts from /home/jboss/source/. directory into /opt/eap/standalone/deployments for later deployment...
    Copying all war artifacts from /home/jboss/source/deployments directory into /opt/eap/standalone/deployments for later deployment...
    '/home/jboss/source/deployments/app-jsp.war' -> '/opt/eap/standalone/deployments/app-jsp.war'
    '/home/jboss/source/deployments/service.war' -> '/opt/eap/standalone/deployments/service.war'
    Copying all ear artifacts from /home/jboss/source/deployments directory into /opt/eap/standalone/deployments for later deployment...
    Copying all rar artifacts from /home/jboss/source/deployments directory into /opt/eap/standalone/deployments for later deployment...
    Copying all jar artifacts from /home/jboss/source/deployments directory into /opt/eap/standalone/deployments for later deployment...
    Pushing image 172.30.82.129:5000/eap-app-demo/eap-app:latest ...
    Pushed 6/7 layers, 86% complete
    Pushed 7/7 layers, 100% complete
    Push successful
  3. Create a new OpenShift application based on the build.

    $ oc new-app eap-app
    --> Found image 6b13d36 (2 minutes old) in image stream "eap-app-demo/eap-app" under tag "latest" for "eap-app"
    
        eap-app-demo/eap-app-1:aa2574d9
        -------------------------------
        Platform for building and running JavaEE applications on JBoss EAP 7.1
    
        Tags: builder, javaee, eap, eap7
    
        * This image will be deployed in deployment config "eap-app"
        * Ports 8080/tcp, 8443/tcp, 8778/tcp will be load balanced by service "eap-app"
          * Other containers can access this service through the hostname "eap-app"
    
    --> Creating resources ...
        deploymentconfig "eap-app" created
        service "eap-app" created
    --> Success
        Run 'oc status' to view your app.
  4. Stop all running containers of the EAP 6.4 / 7.1 JSP application in the current namespace.

    $ oc get dc -o name
    deploymentconfig/eap-app
    $ oc scale dc/eap-app --replicas=0
    deploymentconfig "eap-app" scaled
  5. Further configure the EAP 6.4 / 7.1 JSP application prior the deployment.

    1. Configure the application with proper details about the Red Hat Single Sign-On server instance.

      Warning

      Ensure to replace the value of SSO_PUBLIC_KEY variable below with the actual content of the RSA public key for the demo realm, that has been copied.

      $ oc set env dc/eap-app \
      -e HOSTNAME_HTTP="eap-app-eap-app-demo.openshift.example.com" \
      -e HOSTNAME_HTTPS="secure-eap-app-eap-app-demo.openshift.example.com" \
      -e SSO_DISABLE_SSL_CERTIFICATE_VALIDATION="true" \
      -e SSO_USERNAME="appuser" \
      -e SSO_PASSWORD="apppassword" \
      -e SSO_REALM="demo" \
      -e SSO_URL="https://secure-sso-sso-app-demo.openshift.example.com/auth" \
      -e SSO_PUBLIC_KEY="MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkdhXyKx97oIoO6HwnV/MiX2EHO55Sn+ydsPzbjJevI5F31UvUco9uA8dGl6oM8HrnaWWv+i8PvmlaRMhhl6Xs68vJTEc6d0soP+6A+aExw0coNRp2PDwvzsXVWPvPQg3+iytStxu3Icndx+gC0ZYnxoRqL7rY7zKcQBScGEr78Nw6vZDwfe6d/PQ6W4xVErNytX9KyLFVAE1VvhXALyqEM/EqYGLmpjw5bMGVKRXnhmVo9E88CkFDH8E+aPiApb/gFul1GJOv+G8ySLoR1c8Y3L29F7C81odkVBp2yMm3RVFIGSPTjHqjO/nOtqYIfY4Wyw9mRIoY5SyW7044dZXRwIDAQAB" \
      -e SSO_SECRET="0bb8c399-2501-4fcd-a183-68ac5132868d"
      deploymentconfig "eap-app" updated
    2. Configure the application with details about both the SSL and JGroups keystore.

      $ oc set env dc/eap-app \
      -e HTTPS_KEYSTORE_DIR="/etc/eap-secret-volume" \
      -e HTTPS_KEYSTORE="eapkeystore.jks" \
      -e HTTPS_PASSWORD="password" \
      -e JGROUPS_ENCRYPT_SECRET="eap-jgroup-secret" \
      -e JGROUPS_ENCRYPT_KEYSTORE_DIR="/etc/jgroups-encrypt-secret-volume" \
      -e JGROUPS_ENCRYPT_KEYSTORE="eapjgroups.jceks" \
      -e JGROUPS_ENCRYPT_PASSWORD="password"
      deploymentconfig "eap-app" updated
    3. Define OpenShift volumes for both the SSL and JGroups secrets created earlier.

      $ oc volume dc/eap-app --add \
      --name="eap-keystore-volume" \
      --type=secret \
      --secret-name="eap-ssl-secret" \
      --mount-path="/etc/eap-secret-volume"
      deploymentconfig "eap-app" updated
      $ oc volume dc/eap-app --add \
      --name="eap-jgroups-keystore-volume" \
      --type=secret \
      --secret-name="eap-jgroup-secret" \
      --mount-path="/etc/jgroups-encrypt-secret-volume"
      deploymentconfig "eap-app" updated
    4. Configure the deployment config of the application to run application pods under the default OpenShift service account (default setting).

      $ oc patch dc/eap-app --type=json \
      -p '[{"op": "add", "path": "/spec/template/spec/serviceAccountName", "value": "default"}]'
      "eap-app" patched
  6. Deploy container of the EAP 6.4 / 7.1 JSP application using the modified deployment config.

    $ oc scale dc/eap-app --replicas=1
    deploymentconfig "eap-app" scaled
  7. Expose the service as route.

    $ oc get svc -o name
    service/eap-app
    $ oc get route
    No resources found.
    $ oc expose svc/eap-app
    route "eap-app" exposed
    $ oc get route
    NAME      HOST/PORT                                    PATH      SERVICES   PORT       TERMINATION   WILDCARD
    eap-app   eap-app-eap-app-demo.openshift.example.com             eap-app    8080-tcp                 None

3.3.1.5. Access the Application

Access the application in your browser using the URL http://eap-app-eap-app-demo.openshift.example.com/app-jsp. You should see output like on the following image:

Red Hat Single Sign-On Example JSP Application

Perform the following to test the application:

  • Click the INVOKE PUBLIC button to access the public endpoint that doesn’t require authentication.

    You should see the Message: public output.

  • Click the LOGIN button to be redirected for user authentication to the Red Hat Single Sign-On server instance against the demo realm.

    Specify username and password of the Red Hat Single Sign-On user configured earlier (appuser / apppassword). Click Log in. The look of the application changes as detailed in the following image:

    sso app jee jsp logged in

  • Click the INVOKE SECURED button to access the secured endpoint.

    You should see the Message: secured output.

  • Click the INVOKE ADMIN button to access the admin endpoint.

    You should see 403 Forbidden output.

    Note

    The admin endpoint requires users with admin Red Hat Single Sign-On role to invoke properly. Access for the appuser is forbidden because they only have user role privilege, which allows them to access the secured endpoint.

    Perform the following steps to add the appuser to the admin Red Hat Single Sign-On role:

    1. Access the administration console of the Red Hat Single Sign-On server’s instance.

      https://secure-sso-sso-app-demo.openshift.example.com/auth/admin.

      Use the credentials of the Red Hat Single Sign-On administrator user.

    2. Click Users in the Manage sidebar to view the user information for the demo realm.
    3. Click View all users button.
    4. Click the ID link for the appuser or alternatively click the Edit button in the Actions column.
    5. Click the Role Mappings tab.
    6. Select admin entry from the Available Roles list in the Realm Roles row.
    7. Click Add selected> button to add the admin role to the user.
    8. Return to EAP 6.4 / 7.1 JSP service application.

      http://eap-app-eap-app-demo.openshift.example.com/app-jsp.

    9. Click the LOGOUT button to reload role mappings for the appuser.
    10. Click the LOGIN button again and provider appuser credentials.
    11. Click the INVOKE ADMIN button again.

      You should see the Message: admin output already.