手順

1. cluster:admin ロールを持つユーザーとして OpenShift CLI にログインします。

2. 新しいプロジェクトを作成します。

   $ oc new-project sso-app-demo

3. view ロールを デフォルト のサービスアカウントに追加します。これにより、サービスアカウントが sso-app-demo 名前空間のすべてのリソースを表示できるようになります。これは、クラスターの管理に必要です。

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

手順

1. cluster:admin ロールを持つユーザーとして OpenShift CLI にログインします。

2. 新しいプロジェクトを作成します。

   $ oc new-project sso-app-demo

3. view ロールを デフォルト のサービスアカウントに追加します。これにより、サービスアカウントが sso-app-demo 名前空間のすべてのリソースを表示できるようになります。これは、クラスターの管理に必要です。

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

手順

1. CA 証明書を生成します。パスワードを選択し、忘れないようにしてください。以下の CA 証明書で証明書署名要求に署名する際に、同じパスワードを指定します。

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

2. HTTPS キーストアの秘密鍵を生成するmykeystorepass をキーストアパスワードとして提供します。

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

3. HTTPS キーストアの証明書署名要求を生成します。mykeystorepass をキーストアパスワードとして提供します。

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

4. CA 証明書を使用して証明書署名要求に署名します。CA 証明書の生成 に使用されたパスワードを指定します。

   $ openssl x509 -req -extfile  <(printf "subjectAltName=DNS:secure-sso-sso-app-demo.openshift.example.com") -CA xpaas.crt -CAkey xpaas.key -in sso.csr -out sso.crt -days 365 -CAcreateserial

   注記

   上記のコマンドを 1 行で機能させるために、コマンドにはプロセス置換 ( <() 構文) が含まれています。現在のシェル環境がそのような構文をサポートしていることを確認してください。そうしないと、syntax error near unexpected token `(' が発生する可能性があります。

5. CA 証明書を HTTPS キーストアにインポートします。mykeystorepass をキーストアパスワードとして提供します。Trust this certificate? [no]: の質問に yes を返信します。

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

6. 署名済み証明書署名要求を HTTPS キーストアにインポートします。mykeystorepass をキーストアパスワードとして提供します。

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

1. 前のセクション で生成された HTTPS および JGroups キーストアのシークレットと Red Hat Single Sign-On サーバートラストストアを作成します。

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

2. これらのシークレットを、Red Hat Single Sign-On Pod の実行に使用されるデフォルトのサービスアカウントにリンクします。

   $ oc secrets link default sso-app-secret

1. Red Hat Single Sign-On アプリケーションのデプロイメント設定を特定します。

   $ oc get dc -o name
   deploymentconfig/sso
   deploymentconfig/sso-postgresql

2. SSO_ADMIN_USERNAME および SSO_ADMIN_PASSWORD 変数の設定を削除します。

   $ oc set env dc/sso \
     -e SSO_ADMIN_USERNAME="" \
     -e SSO_ADMIN_PASSWORD=""

手順

1. Red Hat Single Sign-On アプリケーション Pod を特定します。

   $ oc get pods
   NAME                     READY     STATUS    RESTARTS   AGE
   sso-12-pt93n             1/1       Running   0          1m
   sso-postgresql-6-d97pf   1/1       Running   0          2m

2. Red Hat Single Sign-On for OpenShift コンテナーに対してリモートシェルセッションを開きます。

   $ oc rsh sso-12-pt93n
   sh-4.2$

3. add-user-keycloak.sh スクリプトを使用して、コマンドラインで master レルムの Red Hat Single Sign-On サーバー管理者アカウントを作成します。

   sh-4.2$ cd /opt/eap/bin/
   sh-4.2$ ./add-user-keycloak.sh \
           -r master \
           -u sso_admin \
           -p sso_password
   Added 'sso_admin' to '/opt/eap/standalone/configuration/keycloak-add-user.json', restart server to load user

   注記

   上記の例の sso_admin または sso_password 認証情報はデモ目的にのみ使用されます。安全なユーザー名とパスワードの作成方法は、組織内で適用されるパスワードポリシーを参照してください。

4. 基盤の JBoss EAP サーバーインスタンスを再起動して、新たに追加したユーザーアカウントをロードします。サーバーが正しく再起動するまで待ちます。

   sh-4.2$ ./jboss-cli.sh --connect ':reload'
   {
       "outcome" => "success",
       "result" => undefined
   }

   警告

   サーバーを再起動する場合は、コンテナー全体ではなく、実行中の Red Hat Single Sign-On コンテナー内で JBoss EAP プロセスを再起動することが重要です。これは、master レルムの Red Hat Single Sign-On サーバー管理アカウントなしに、コンテナー全体の再起動がゼロから再作成されるためです。

5. 上記の手順で作成した認証情報を使用して、Red Hat Single Sign-On サーバーの master レルムの管理コンソールにログインします。ブラウザーで、Red Hat Single Sign-On Web サーバーの場合は http://sso-<project-name>.<hostname>/auth/admin に移動するか、暗号化された Red Hat Single Sign-On Web サーバーの場合は https://secure-sso-<project-name>.<hostname>/auth/admin に移動し、管理者ユーザーの作成に使用するユーザー名とパスワードを指定します。

手順

1. まず、データベースレベルのバックアップを実行します。

   $ oc rsh <POSTGRE-SQL-POD> pg_dump -C <DATABASE> rhsso_db.bak

2. sso Pod をスケールダウンします。

   $ oc scale dc/sso --replicas=0

3. dc/sso-postgresql を編集します。

   $ oc edit dc/sso-postgresql

   ImageStreamTag を :postgresql:13-el8 に切り替えます。

   - imageChangeParams:
         automatic: true
         containerNames:
         - sso-postgresql
         from:
           kind: ImageStreamTag
           name: postgresql:13-el8
           namespace: openshift

4. sso-postgresql Pod が実行され、安定するまで待機します。

5. Pod sso-postgresql のバージョンが正しいことを確認してください。

   $ oc rsh dc/sso-postgresql /bin/bash -c "psql --version"
   psql (PostgreSQL) 13.5

6. 変数 POSTGRESQL_UPGRADE の設定を解除し、sso-postgresql Pod を再度デプロイします。

   $ oc set env dc/sso-postgresql POSTGRESQL_UPGRADE-

7. sso-posgresql Pod が実行され、安定するまで待ちます。

8. 以下のコマンドを実行して、openshift プロジェクト内の OpenShift 用の Red Hat Single Sign-On 7.6.8 リソースのコアセットを更新します。

   OpenShift 3.x クラスターを使用している場合は、以下のコマンドを使用します。

   $ for resource in sso76-image-stream.json \
     passthrough/ocp-3.x/sso76-ocp3-https.json \
     passthrough/ocp-3.x/sso76-ocp3-postgresql.json \
     passthrough/ocp-3.x/sso76-ocp3-postgresql-persistent.json \
     reencrypt/ocp-3.x/sso76-ocp3-x509-https.json \
     reencrypt/ocp-3.x/sso76-ocp3-x509-postgresql-persistent.json
   do
     oc replace -n openshift --force -f \
     https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/sso76-dev/templates/${resource}
   done

   OpenShift 4.x クラスターを使用している場合は、以下のコマンドを使用します。

   $ for resource in sso76-image-stream.json \
     passthrough/ocp-4.x/sso76-ocp4-https.json \
     passthrough/ocp-4.x/sso76-ocp4-postgresql.json \
     passthrough/ocp-4.x/sso76-ocp4-postgresql-persistent.json \
     reencrypt/ocp-4.x/sso76-ocp4-x509-https.json \
     reencrypt/ocp-4.x/sso76-ocp4-x509-postgresql-persistent.json
   do
     oc replace -n openshift --force -f \
     https://raw.githubusercontent.com/jboss-container-images/redhat-sso-7-openshift-image/sso76-dev/templates/${resource}
   done

9. 以下のコマンドを実行して、Red Hat Single Sign-On 7.6.8 OpenShift イメージストリームを openshift プロジェクトにインストールします。

   $ oc -n openshift import-image rh-sso-7/sso76-openshift-rhel8:7.6 --from=registry.redhat.io/rh-sso-7/sso76-openshift-rhel8:7.6 --confirm

10. Red Hat Single Sign-On 7.6.8 イメージを参照するように、既存のデプロイメント設定のイメージ変更トリガーを更新します。

    $ oc patch dc/sso --type=json -p '[{"op": "replace", "path": "/spec/triggers/0/imageChangeParams/from/name", "value": "sso76-openshift-rhel8:7.6"}]'
    "sso" patched

11. イメージ変更トリガーで定義された最新のイメージに基づいて、新規の Red Hat Single Sign-On 7.6.8 イメージのロールアウトを開始します。

    $ oc rollout latest dc/sso

12. sso Pod を 1 つのレプリカにスケールアップします。

    注記

    Liveness and Readiness Probes のしきい値と値を dc/sso から秒単位で一時的に増やす場合があります。この手順では、最初の起動時にデータベースのアップグレードを実行します。これには時間がかかる場合があります。

    $ oc scale --replicas=1 dc/sso

    注記

    複数のレプリカがある場合は、単一のレプリカにスケールアップすることを検討してください。Red Hat Single Sign-On の起動後、レプリカの数を元に戻すことができます。

1. Red Hat Single Sign-On for OpenShift イメージの以前のバージョンを実行して、コンテナーをデプロイするために使用されるデプロイメント設定を特定します。

   $ oc get dc -o name --selector=application=sso
   deploymentconfig/sso
   deploymentconfig/sso-postgresql

2. 現在の名前空間で、以前のバージョンの Red Hat Single Sign-On for OpenShift イメージを実行するすべての Pod を停止します。同じデータベースに対して同時に実行することはできません。

   $ oc scale --replicas=0 dc/sso
   deploymentconfig "sso" scaled

3. Red Hat Single Sign-On 7.6.8 イメージを参照するように、既存のデプロイメント設定のイメージ変更トリガーを更新します。

   $ oc patch dc/sso --type=json -p '[{"op": "replace", "path": "/spec/triggers/0/imageChangeParams/from/name", "value": "sso76-openshift-rhel8:7.6"}]'
   "sso" patched

4. イメージ変更トリガーで定義された最新のイメージに基づいて、新規の Red Hat Single Sign-On 7.6.8 イメージのロールアウトを開始します。

   $ oc rollout latest dc/sso
   deploymentconfig "sso" rolled out

5. 変更したデプロイメント設定を使用して、Red Hat Single Sign-On 7.6.8 コンテナーをデプロイします。

   $ oc scale --replicas=1 dc/sso
   deploymentconfig "sso" scaled

6. (必要に応じて) データベースが正常に更新されたことを確認します。

   $ oc get pods --selector=application=sso
   NAME                     READY     STATUS    RESTARTS   AGE
   sso-4-vg21r              1/1       Running   0          1h
   sso-postgresql-1-t871r   1/1       Running   0          2h

   $ oc logs sso-4-vg21r | grep 'Updating'
   11:23:45,160 INFO  [org.keycloak.connections.jpa.updater.liquibase.LiquibaseJpaUpdaterProvider] (ServerService Thread Pool -- 58) Updating database. Using changelog META-INF/jpa-changelog-master.xml

1. Red Hat Single Sign-On 7.6.8 を正しいデータソースで設定します。

2. standalone-openshift.xml ファイルに以下の設定オプションを設定します。

   1. initializeEmpty=false
   2. migrationStrategy=manual
   3. migrationExport は、出力 SQL 移行ファイルが保存される Pod のファイルシステム上の場所に移行します (例: migrationExport="${jboss.home.dir}/keycloak-database-update.sql")。

1. OpenShift データベース移行ジョブ のテンプレートを準備し、SQL ファイルを生成します。

   $ cat job-to-migrate-db-to-sso76.yaml.orig
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: job-to-migrate-db-to-sso76
   spec:
     autoSelector: true
     parallelism: 0
     completions: 1
     template:
       metadata:
         name: job-to-migrate-db-to-sso76
       spec:
         containers:
         - env:
           - name: DB_SERVICE_PREFIX_MAPPING
             value: <<DB_SERVICE_PREFIX_MAPPING_VALUE>>
           - name: <<PREFIX>>_JNDI
             value: <<PREFIX_JNDI_VALUE>>
           - name: <<PREFIX>>_USERNAME
             value: <<PREFIX_USERNAME_VALUE>>
           - name: <<PREFIX>>_PASSWORD
             value: <<PREFIX_PASSWORD_VALUE>>
           - name: <<PREFIX>>_DATABASE
             value: <<PREFIX_DATABASE_VALUE>>
           - name: TX_DATABASE_PREFIX_MAPPING
             value: <<TX_DATABASE_PREFIX_MAPPING_VALUE>>
           - name: <<SERVICE_HOST>>
             value: <<SERVICE_HOST_VALUE>>
           - name: <<SERVICE_PORT>>
             value: <<SERVICE_PORT_VALUE>>
           image: <<SSO_IMAGE_VALUE>>
           imagePullPolicy: Always
           name: job-to-migrate-db-to-sso76
           # Keep the pod running after the SQL migration
           # file was generated, so we can retrieve it
           command:
             - "/bin/bash"
             - "-c"
             - "/opt/eap/bin/openshift-launch.sh || sleep 600"
         restartPolicy: Never

   $ cp job-to-migrate-db-to-sso76.yaml.orig \
        job-to-migrate-db-to-sso76.yaml

2. 以前のバージョンの Red Hat Single Sign-On for OpenShift イメージを実行するのに使用されるデプロイメント設定から、データソース定義およびデータベースアクセス認証情報をデータベース移行ジョブのテンプレートの適切な場所にコピーします。

   以下のスクリプトを使用して、sso という名前のデプロイメント設定から、job-to-migrate-db-to-sso76.yaml という名前のデータベースジョブ移行テンプレートに、DB_SERVICE_PREFIX_MAPPING 変数および TX_DATABASE_PREFIX_MAPPING 変数の値と、特定のデータソース固有の環境変数の値 (<PREFIX>_JNDI、<PREFIX>_USERNAME、<PREFIX>_PASSWORD、および <PREFIX>_DATABASE) をコピーします。

   注記

   DB_SERVICE_PREFIX_MAPPING 環境変数では、<name>-<database_type>=<PREFIX> トリプレットのコンマ区切りリスト を値として指定することができますが、この例のスクリプトでは、デモのために 1 つのデータソースのトリプレット定義のみを受け付けます複数のデータソース定義トリプレットを処理するスクリプトを変更できます。

   $ cat mirror_sso_dc_db_vars.sh
   #!/bin/bash
   
   # IMPORTANT:
   #
   # If the name of the SSO deployment config differs from 'sso'
   # or if the file name of the YAML definition of the migration
   # job is different, update the following two variables
   SSO_DC_NAME="sso"
   JOB_MIGRATION_YAML="job-to-migrate-db-to-sso76.yaml"
   
   # Get existing variables of the $SSO_DC_NAME deployment config
   # in an array
   declare -a SSO_DC_VARS=( \
     $(oc set env dc/${SSO_DC_NAME} --list \
     | sed '/^#/d') \
   )
   
   # Get the PREFIX used in the names of environment variables
   PREFIX=$( \
     grep -oP 'DB_SERVICE_PREFIX_MAPPING=[^ ]+' \
     <<< "${SSO_DC_VARS[@]}" \
   )
   PREFIX=${PREFIX##*=}
   
   # Substitute:
   # * <<PREFIX>> with actual $PREFIX value and
   # * <<PREFIX with "<<$PREFIX" value
   # The order in which these replacements are made is important!
   sed -i "s#<<PREFIX>>#${PREFIX}#g" ${JOB_MIGRATION_YAML}
   sed -i "s#<<PREFIX#<<${PREFIX}#g" ${JOB_MIGRATION_YAML}
   
   # Construct the array of environment variables
   # specific to the datasource
   declare -a DB_VARS=(JNDI USERNAME PASSWORD DATABASE)
   
   # Prepend $PREFIX to each item of the datasource array
   DB_VARS=( "${DB_VARS[@]/#/${PREFIX}_}" )
   
   # Add DB_SERVICE_PREFIX_MAPPING and TX_DATABASE_PREFIX_MAPPING
   # variables to datasource array
   DB_VARS=( \
     "${DB_VARS[@]}" \
     DB_SERVICE_PREFIX_MAPPING \
     TX_DATABASE_PREFIX_MAPPING \
   )
   
   # Construct the SERVICE from DB_SERVICE_PREFIX_MAPPING
   SERVICE=$( \
     grep -oP 'DB_SERVICE_PREFIX_MAPPING=[^ ]' \
     <<< "${SSO_DC_VARS[@]}" \
   )
   SERVICE=${SERVICE#*=}
   SERVICE=${SERVICE%=*}
   SERVICE=${SERVICE^^}
   SERVICE=${SERVICE//-/_}
   
   # If the deployment config contains <<SERVICE>>_SERVICE_HOST
   # and <<SERVICE>>_SERVICE_PORT variables, add them to the
   # datasource array. Their values also need to be propagated into
   # yaml definition of the migration job.
   HOST_PATTERN="${SERVICE}_SERVICE_HOST=[^ ]"
   PORT_PATTERN="${SERVICE}_SERVICE_PORT=[^ ]"
   if
     grep -Pq "${HOST_PATTERN}" <<< "${SSO_DC_VARS[@]}" &&
     grep -Pq "${PORT_PATTERN}" <<< "${SSO_DC_VARS[@]}"
   then
     DB_VARS=( \
       "${DB_VARS[@]}" \
       "${SERVICE}_SERVICE_HOST" \
       "${SERVICE}_SERVICE_PORT" \
     )
   # If they are not defined, delete their placeholder rows in
   # yaml definition file (since if not defined they are not
   # expanded which make the yaml definition invalid).
   else
     for KEY in "HOST" "PORT"
     do
       sed -i "/SERVICE_${KEY}/d" ${JOB_MIGRATION_YAML}
     done
   fi
   
   # Substitute:
   # * <<SERVICE_HOST>> with ${SERVICE}_SERVICE_HOST and
   # * <<SERVICE_HOST_VALUE>> with <<${SERVICE}_SERVICE_HOST_VALUE>>
   # The order in which replacements are made is important!
   # Do this for both "HOST" and "PORT"
   for KEY in "HOST" "PORT"
   do
     PATTERN_1="<<SERVICE_${KEY}>>"
     REPL_1="${SERVICE}_SERVICE_${KEY}"
     sed -i "s#${PATTERN_1}#${REPL_1}#g" ${JOB_MIGRATION_YAML}
     PATTERN_2="<<SERVICE_${KEY}_VALUE>>"
     REPL_2="<<${SERVICE}_SERVICE_${KEY}_VALUE>>"
     sed -i "s#${PATTERN_2}#${REPL_2}#g" ${JOB_MIGRATION_YAML}
   done
   
   # Propagate the values of the datasource array items into
   # yaml definition of the migration job
   for VAR in "${SSO_DC_VARS[@]}"
   do
     IFS=$'=' read KEY VALUE <<< $VAR
     if grep -q $KEY <<< ${DB_VARS[@]}
     then
       KEY+="_VALUE"
       # Enwrap integer port value with double quotes
       if [[ ${KEY} =~ ${SERVICE}_SERVICE_PORT_VALUE ]]
       then
         sed -i "s#<<${KEY}>>#\"${VALUE}\"#g" ${JOB_MIGRATION_YAML}
       # Character values do not need quotes
       else
         sed -i "s#<<${KEY}>>#${VALUE}#g" ${JOB_MIGRATION_YAML}
       fi
       # Verify that the value has been successfully propagated.
       if
         grep -q '(JNDI|USERNAME|PASSWORD|DATABASE)' <<< "${KEY}" &&
         grep -q "<<PREFIX${KEY#${PREFIX}}" ${JOB_MIGRATION_YAML} ||
         grep -q "<<${KEY}>>" ${JOB_MIGRATION_YAML}
       then
         echo "Failed to update value of ${KEY%_VALUE}! Aborting."
         exit 1
       else
         printf '%-60s%-40s\n' \
                "Successfully updated ${KEY%_VALUE} to:" \
                "$VALUE"
       fi
     fi
   done

   スクリプトを実行します。

   $ chmod +x ./mirror_sso_dc_db_vars.sh
   $ ./mirror_sso_dc_db_vars.sh
   Successfully updated DB_SERVICE_PREFIX_MAPPING to:          sso-postgresql=DB
   Successfully updated DB_JNDI to:                            java:jboss/datasources/KeycloakDS
   Successfully updated DB_USERNAME to:                        userxOp
   Successfully updated DB_PASSWORD to:                        tsWNhQHK
   Successfully updated DB_DATABASE to:                        root
   Successfully updated TX_DATABASE_PREFIX_MAPPING to:         sso-postgresql=DB

3. 事前設定されたソース を使用して Red Hat Single Sign-On 7.6.8 データベース移行イメージをビルドし、ビルドが完了するまで待ちます。

   $ oc get is -n openshift | grep sso76 | cut -d ' ' -f1
   sso76-openshift-rhel8

   $ oc new-build sso76-openshift-rhel8:7.6~https://github.com/iankko/openshift-examples.git#KEYCLOAK-8500 \
     --context-dir=sso-manual-db-migration \
     --name=sso76-db-migration-image
   --> Found image bf45ac2 (7 days old) in image stream "openshift/sso76-openshift-rhel8" under tag "7.6" for "sso76-openshift-rhel8:7.6"
   
       Red Hat SSO 7.6.8
       ---------------
       Platform for running Red Hat SSO
   
       Tags: sso, sso7, keycloak
   
       * A source build using source code from https://github.com/iankko/openshift-examples.git#KEYCLOAK-8500 will be created
         * The resulting image will be pushed to image stream "sso76-db-migration-image:latest"
         * Use 'start-build' to trigger a new build
   
   --> Creating resources with label build=sso76-db-migration-image ...
       imagestream "sso76-db-migration-image" created
       buildconfig "sso76-db-migration-image" created
   --> Success
       Build configuration "sso76-db-migration-image" created and build triggered.
       Run 'oc logs -f bc/sso76-db-migration-image' to stream the build progress.

   $ oc logs -f bc/sso76-db-migration-image --follow
   Cloning "https://github.com/iankko/openshift-examples.git#KEYCLOAK-8500" ...
   ...
   Push successful

4. データベース移行ジョブのテンプレート (job-to-migrate-db-to-sso76.yaml) をビルドされた sso76-db-migration-image イメージへの参照で更新します。

   1. イメージの docker pull 参照を取得します。

      $ PULL_REF=$(oc get istag -n $(oc project -q) --no-headers | grep sso76-db-migration-image | tr -s ' ' | cut -d ' ' -f 2)

   2. ジョブテンプレートの <<SSO_IMAGE_VALUE>> フィールドを、プル仕様に置き換えます。

      $ sed -i "s#<<SSO_IMAGE_VALUE>>#$PULL_REF#g" job-to-migrate-db-to-sso76.yaml

   3. フィールドが更新されていることを確認します。

5. ジョブテンプレートからデータベース移行ジョブをインスタンス化します。

   $ oc create -f job-to-migrate-db-to-sso76.yaml
   job "job-to-migrate-db-to-sso76" created

   重要

   データベースの移行プロセスでは、データスキーマの更新を処理し、データの操作を実行します。したがって、SQL 移行ファイルを動的に生成する前に、以前のバージョンの Red Hat Single Sign-On for OpenShift イメージを実行するすべての Pod を停止します。

6. Red Hat Single Sign-On for OpenShift イメージの以前のバージョンを実行して、コンテナーをデプロイするために使用されるデプロイメント設定を特定します。

   $ oc get dc -o name --selector=application=sso
   deploymentconfig/sso
   deploymentconfig/sso-postgresql

7. 現在の名前空間で、以前のバージョンの Red Hat Single Sign-On for OpenShift イメージを実行するすべての Pod を停止します。

   $ oc scale --replicas=0 dc/sso
   deploymentconfig "sso" scaled

8. データベースの移行ジョブを実行し、Pod が正しく実行されるのを待機します。

   $ oc get jobs
   NAME                            DESIRED   SUCCESSFUL   AGE
   job-to-migrate-db-to-sso76   1         0            3m

   $ oc scale --replicas=1 job/job-to-migrate-db-to-sso76
   job "job-to-migrate-db-to-sso76" scaled

   $ oc get pods
   NAME                                  READY     STATUS      RESTARTS   AGE
   sso-postgresql-1-n5p16                1/1       Running     1          19h
   job-to-migrate-db-to-sso76-b87bb   1/1       Running     0          1m
   sso76-db-migration-image-1-build      0/1       Completed   0          27m

   注記

   デフォルトでは、データベース移行ジョブは、移行ファイルの生成後 600 秒 後に自動的に終了します。この期間を調整できます。

9. Pod から動的に生成された SQL データベース移行ファイルを取得します。

   $ mkdir -p ./db-update
   $ oc rsync job-to-migrate-db-to-sso76-b87bb:/opt/eap/keycloak-database-update.sql ./db-update
   receiving incremental file list
   keycloak-database-update.sql
   
   sent 30 bytes  received 29,726 bytes  59,512.00 bytes/sec
   total size is 29,621  speedup is 1.00

10. keycloak-database-update.sql ファイルを調べて、Red Hat Single Sign-On 7.6.8 バージョンへの手動データベース更新で実行される変更を確認します。

11. データベースの更新を手動で適用します。

    • PostgreSQL データベース (一時的または永続的モードでデプロイ) がサポートする Red Hat Single Sign-On for OpenShift イメージの以前のバージョンを別の Pod で実行する場合は、以下のコマンドを実行します。

      1. 生成された SQL 移行ファイルを PostgreSQL Pod にコピーします。

         $ oc rsync --no-perms=true ./db-update/ sso-postgresql-1-n5p16:/tmp
         sending incremental file list
         
         sent 77 bytes  received 11 bytes  176.00 bytes/sec
         total size is 26,333  speedup is 299.24

      2. PostgreSQL Pod へのシェルセッションを開始します。

         $ oc rsh sso-postgresql-1-n5p16
         sh-4.2$

      3. psql ツールを使用して、データベースの更新を手動で適用します。

         sh-4.2$ alias psql="/opt/rh/rh-postgresql95/root/bin/psql"
         sh-4.2$ psql --version
         psql (PostgreSQL) 9.5.4
         sh-4.2$ psql -U <PREFIX>_USERNAME -d <PREFIX>_DATABASE -W -f /tmp/keycloak-database-update.sql
         Password for user <PREFIX>_USERNAME:
         INSERT 0 1
         INSERT 0 1
         ...

         重要

         <PREFIX>_USERNAME および <PREFIX>_DATABASE を、前のセクション で取得した実際のデータベースの認証情報に置き換えます。また、プロンプトが表示されたら、データベースのパスワードとして <PREFIX>_PASSWORD の値を使用します。

      4. PostgreSQL Pod へのシェルセッションを閉じます。イメージ変更トリガーの更新手順 に進みます。

12. Red Hat Single Sign-On 7.6.8 イメージを参照するように、既存のデプロイメント設定のイメージ変更トリガーを更新します。

    $ oc patch dc/sso --type=json -p '[{"op": "replace", "path": "/spec/triggers/0/imageChangeParams/from/name", "value": "sso76-openshift-rhel8:7.6"}]'
    "sso" patched

13. イメージ変更トリガーで定義された最新のイメージに基づいて、新規の Red Hat Single Sign-On 7.6.8 イメージのロールアウトを開始します。

    $ oc rollout latest dc/sso
    deploymentconfig "sso" rolled out

14. 変更したデプロイメント設定を使用して、Red Hat Single Sign-On 7.6.8 コンテナーをデプロイします。

    $ oc scale --replicas=1 dc/sso
    deploymentconfig "sso" scaled

手順

1. OpenShift Web コンソールにログインし、sso-app-demo プロジェクトスペースを選択します。
2. Add to project をクリックし、デフォルトのイメージストリームおよびテンプレートをリスト表示します。
3. Filter by keyword 検索バーを使用して、リストを sso に一致するものに制限します。See all をクリックして、必要なアプリケーションテンプレートを表示する必要がある場合があります。

4. sso76-ocp4-postgresql Red Hat Single Sign-On アプリケーションテンプレートを選択します。テンプレートをデプロイする際には、必ず SSO_REALM 変数が設定されていない (デフォルト値) ことを確認してください。

   警告

   Red Hat Single Sign-On for OpenShift イメージに SSO_REALM 設定変数が設定されていると、変数で要求される Red Hat Single Sign-On サーバーレルムを作成するためにデータベースのインポートが実行されます。データベースのエクスポートを正しく実行するには、そのイメージに SSO_REALM 設定変数を同時に定義することはできません。

5. Create をクリックしてアプリケーションテンプレートをデプロイし、Pod デプロイメントを開始します。これには数分の時間がかかる場合があります。

   その後、管理者アカウント を使用して https://secure-sso-<sso-app-demo>.<openshift32.example.com>/auth/admin で Red Hat Single Sign-On の Web コンソールにアクセスします。

   注記

   このワークフロー例では、自己生成された CA を使用して、デモ目的でエンドツーエンドのワークフローを提供します。Red Hat Single Sign-On Web コンソールにアクセスすると、セキュリティーが保護されていない接続に関する警告が表示されます。
   実稼働環境では、検証された認証局から購入した SSL 証明書を使用することを推奨します。

1. レルムを作成します。
2. ユーザーを作成します。

手順

1. Red Hat Single Sign-On デプロイメント設定を取得し、これをゼロにスケールダウンします。

   $ oc get dc -o name
   deploymentconfig/sso
   deploymentconfig/sso-postgresql
   
   $ oc scale --replicas=0 dc sso
   deploymentconfig "sso" scaled

2. Red Hat Single Sign-On for OpenShift イメージにデプロイされた Red Hat Single Sign-On 7.6.8 サーバーに、Red Hat Single Sign-On サーバーの起動時にデータベースのエクスポートを実行するよう指示します。

   $ oc set env dc/sso \
     -e "JAVA_OPTS_APPEND= \
       -Dkeycloak.migration.action=export \
       -Dkeycloak.migration.provider=singleFile \
       -Dkeycloak.migration.file=/tmp/demorealm-export.json"

3. Red Hat Single Sign-On デプロイメント設定のバックアップを拡張します。これにより、Red Hat Single Sign-On サーバーが起動し、そのデータベースをエクスポートします。

   $ oc scale --replicas=1 dc sso
   deploymentconfig "sso" scaled

4. (必要に応じて) エクスポートが成功したことを確認します。

   $ oc get pods
   NAME                     READY     STATUS    RESTARTS   AGE
   sso-4-ejr0k              1/1       Running   0          27m
   sso-postgresql-1-ozzl0   1/1       Running   0          4h
   
   $ oc logs sso-4-ejr0k | grep 'Export'
   09:24:59,503 INFO  [org.keycloak.exportimport.singlefile.SingleFileExportProvider] (ServerService Thread Pool -- 57) Exporting model into file /tmp/demorealm-export.json
   09:24:59,998 INFO  [org.keycloak.services] (ServerService Thread Pool -- 57) KC-SERVICES0035: Export finished successfully

手順

1. Pod から Red Hat Single Sign-On データベースの JSON ファイルを取得します。

   $ oc get pods
   NAME                     READY     STATUS    RESTARTS   AGE
   sso-4-ejr0k              1/1       Running   0          2m
   sso-postgresql-1-ozzl0   1/1       Running   0          4h
   
   $ oc rsync sso-4-ejr0k:/tmp/demorealm-export.json .

2. (必要に応じて) Red Hat Single Sign-On データベースの JSON ファイルを、別の環境で実行している Red Hat Single Sign-On サーバーにインポートします。

   注記

   OpenShift で実行されていない Red Hat Single Sign-On サーバーへのインポートについては、Importing and exporting the database を参照してください。

   Red Hat Single Sign-On サーバーが OpenShift で Red Hat Single Sign-On 7.6.8 コンテナーとして実行されている場合は、管理コンソールのエクスポート/インポート 機能を使用して、以前にエクスポートした JSON ファイルから Red Hat Single Sign-On サーバーのデータベースにリソースをインポートします。

   1. 管理者ユーザーの作成に使用する認証情報を使用して、Red Hat Single Sign-On サーバーの master レルムの管理コンソールにログインします。ブラウザーで、Red Hat Single Sign-On Web サーバーの場合は http://sso-<project-name>.<hostname>/auth/admin に移動し、暗号化された Red Hat Single Sign-On Web サーバーの場合は https://secure-sso-<project-name>.<hostname>/auth/admin に移動します。
   2. サイドバーの上部に、Red Hat Single Sign-On レルム名、ユーザー、クライアント、レルムロール、およびクライアントロールのインポート先を選択します。この例では、master レルムを使用します。
   3. サイドバーの下部にある Manage セクションにある Import のリンクをクリックします。
   4. 開いたページで Select file をクリックし、ローカルファイルシステムでエクスポートされた JSON ファイル demorealm-export.json の場所を指定します。
   5. Import from realm ドロップダウンメニューから、データのインポート元となる Red Hat Single Sign-On レルムの名前を選択します。この例では、master レルムを使用します。
   6. インポートするユーザー、クライアント、レルムロール、およびクライアントロールを選択します (すべてのユーザーはデフォルトでインポートされます)。

   7. リソースがすでに存在する場合 (Fail、Skip、または Overwriteのいずれか) に実行するストラテジーを選択します。

      注記

      オブジェクト (ユーザー、クライアント、レルムロール、またはクライアントロール) をインポートしようとすると、現在のデータベースに同じ識別子を持つオブジェクトがすでに存在する場合に失敗します。Skip ストラテジーを使用して、demorealm-export.json ファイルにあるが、現在のデータベースに存在しないオブジェクトをインポートします。

   8. インポート をクリックしてインポートを実行します。

      Import ボタンをクリックすると、master レルム以外のレルムから master レルムにオブジェクトをインポートする場合や、その逆の場合、以下のようなエラーが発生することがあります。

      

      この場合、まず、Access Type を bearer-only に設定して、不足しているクライアントを作成する必要があります。これらのクライアントは、エクスポート JSON ファイルが作成されたソースの Red Hat Single Sign-On サーバーから、JSON ファイルがインポートされるターゲット Red Hat Single Sign-On サーバーに、その特性を手動でコピーして作成できます。必要なクライアントを作成したら、再度 Import ボタンをクリックします。

      上記の エラーメッセージを非表示にするには、Access Type が bearer-only の不足している realm-management クライアントを作成して、Import ボタンを再度クリックする必要があります。

      Skip インポートストラテジーでは、新たに追加されたオブジェクトは ADDED としてマークされ、スキップされたオブジェクトが、インポート結果ページの Action 列の SKIPPED としてマークされます。

      管理コンソールのインポートにより、選択した場合にリソースを 上書き できます (Overwrite ストラテジー)。実稼働システムでは、この機能を注意して使用します。

1. カーソルをサイドバーの上部にあるレルム名前空間 (デフォルトは Master) の上に置き、Add Realm をクリックします。
2. レルム名 (この例では OpenShiftを使用) を入力し、Create をクリックします。

1. Manage サイドバーで Users をクリックし、レルムのユーザー情報を表示します。
2. Add User をクリックします。
3. 有効な ユーザー名 (この例では testuser を使用し) と任意の追加情報を入力し、Save をクリックします。

4. ユーザー設定を編集します。

   1. ユーザー空間の Credentials タブをクリックし、ユーザーのパスワードを入力します。
   2. Temporary Password オプションを Off に設定して、後でパスワードの変更を要求しないようにし、Reset Password をクリックしてユーザーパスワードを設定します。ポップアップウィンドウに追加の確認を求めるプロンプトが表示されます。

1. Manage サイドバーで Clients をクリックし、Create をクリックします。
2. Client ID を入力します。この例では openshift-demo を使用します。
3. ドロップダウンメニューから クライアントプロトコル を選択し (この例では openid-connectを使用)、Save をクリックします。openshift-demo クライアントの Settings ページに移動します。
4. Access Type ドロップダウンメニューから、confidential を選択します。これは、サーバー側のアプリケーションのアクセスタイプです。
5. Valid Redirect URIs ダイアログで、OpenShift Web コンソールの URI (この例では https://openshift.example.com:8443/*) を入力します。

手順

1. /etc/origin/master/master-config.yaml ファイルを編集し、identityProviders セクションを見つけます。たとえば、OpenShift マスターが HTPassword ID プロバイダー で設定されている場合、identityProviders セクションは以下のようになります。

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

   以下のスニペットのような内容で、Red Hat Single Sign-On をセカンダリーアイデンティティープロバイダーとして追加します。

   - name: rh_sso
     challenge: false
     login: true
     mappingMethod: 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

   1. clientSecret の Red Hat Single Sign-On Secret ハッシュは、Red Hat Single Sign-On Web コンソールの Clients → openshift-demo → Credentials にあります。

   2. urls のエンドポイントは、Red Hat Single Sign-On アプリケーションでリクエストを行うことで確認できます。以下に例を示します。

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

      応答には、authorization_endpoint、token_endpoint、および userinfo_endpoint が含まれます。

   3. このワークフロー例では、自己生成された CA を使用して、デモ目的でエンドツーエンドのワークフローを提供します。このため、ca は <ca: xpaas.crt> として提供されます。この CA 証明書も /etc/origin/master ディレクトリーにコピーする必要があります。検証済みの認証局から購入した証明書を使用する場合、この作業は必要ありません。

2. 設定を保存して OpenShift マスターを再起動します。

   $ systemctl restart atomic-openshift-master

手順

1. OpenShift Web コンソールに移動します。この例では https://openshift.example.com:8443/console が使用されています。

   OpenShift ログインページに、htpasswd_auth または rh-sso ID プロバイダーのいずれかを使用してログインするためのオプションが提供されるようになりましたか ?/etc/origin/master/master-config.yaml に存在するため、以前のバージョンは引き続き利用できます。

2. rh-sso を選択し、Red Hat Single Sign-On に先に作成した testuser ユーザーを使用して OpenShift にログインします。

   OpenShift CLI に追加されるまで、testuser にはプロジェクトは表示されません。これは、現在外部ロールマッピングを受け入れないため、OpenShift のユーザー特権を提供する唯一の方法です。

3. sso-app-demo に testuser view 権限を提供するには、OpenShift CLI を使用します。

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

1. 新しいプロジェクトを作成します。

   $ oc new-project eap-app-demo

2. view ロールを デフォルト のサービスアカウントに追加します。これにより、サービスアカウントが eap-app-demo 名前空間のすべてのリソースを表示できるようになります。これは、クラスターの管理に必要です。

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

3. EAP テンプレートには、SSL キーストアと JGroups キーストア が必要です。
   この例では、Java Development Kit に含まれるパッケージの keytool を使用して、これらのキーストアの自己署名証明書を生成します。以下のコマンドはパスワードを要求します。
   

   1. SSL キーストアのセキュアキーを生成します。

      $ keytool -genkeypair -alias https -storetype JKS -keystore eapkeystore.jks

   2. JGroups キーストアのセキュアキーを生成します。

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

4. SSL および JGroup キーストアファイルで EAP for OpenShift シークレットを生成します。

   $ oc create secret generic eap-ssl-secret --from-file=eapkeystore.jks
   $ oc create secret generic eap-jgroup-secret --from-file=eapjgroups.jceks

5. EAP シークレットを default のサービスアカウントに追加します。

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

1. サイドバーの上部にあるレルム名前空間にカーソルを合わせ、Add Realm をクリックします。
2. レルム名を入力して (この例では eap-demoを使用)、Create をクリックします。

1. Configure サイドバーの Roles をクリックし、このレルムのロールをリスト表示します。これは新しいレルムであるため、デフォルトの offline_access ロールのみが必要です。
2. Add Role をクリックします。
3. ロール名を入力して (この例ではロール eap-user-role を使用)、Save をクリックします。

1. Manage サイドバーで Users をクリックし、レルムのユーザー情報を表示します。
2. Add User をクリックします。
3. 有効なユーザー名 を入力して (この例ではユーザー eap-mgmt-user を使用)、Save をクリックします。
4. ユーザー設定を編集します。ユーザー空間の Credentials タブをクリックし、ユーザーのパスワードを入力します。パスワードを確認した後、Reset Password をクリックしてユーザーパスワードを設定できます。ポップアップウィンドウに追加の確認を求めるプロンプトが表示されます。
5. Role Mappings をクリックし、レルムおよびクライアントロール設定をリスト表示します。Client Roles ドロップダウンメニューで realm-management を選択し、利用可能なロールをすべてユーザーに追加します。これにより、JBoss EAP イメージによるクライアント作成に使用できる Red Hat Single Sign-On サーバーの権限が提供されます。

1. Manage サイドバーで Users をクリックし、レルムのユーザー情報を表示します。
2. Add User をクリックします。
3. アプリケーションユーザー の有効な ユーザー名 と任意の追加情報を入力し、Save をクリックします。
4. ユーザー設定を編集します。ユーザー空間の Credentials タブをクリックし、ユーザーのパスワードを入力します。パスワードを確認した後、Reset Password をクリックしてユーザーパスワードを設定できます。ポップアップウィンドウに追加の確認を求めるプロンプトが表示されます。
5. Role Mappings をクリックし、レルムおよびクライアントロール設定をリスト表示します。Available Roles で、先に作成したロールを追加します。

1. OpenShift Web コンソールに戻り、Add to project をクリックしてデフォルトのイメージストリームおよびテンプレートをリスト表示します。
2. Filter by keyword 検索バーを使用して、リストを sso に一致するものに制限します。See all をクリックして、必要なアプリケーションテンプレートを表示する必要がある場合があります。

3. eap71-sso-s2i イメージを選択して、すべてのデプロイメントパラメーターをリスト表示します。EAP ビルド時に Red Hat Single Sign-On 認証情報を設定するには、以下の Red Hat Single Sign-On パラメーターを追加します。

   変数	値の例
   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	eapkeystore.jks
   HTTPS_PASSWORD	password
   HTTPS_SECRET	eap-ssl-secret
   JGROUPS_ENCRYPT_KEYSTORE	eapjgroups.jceks
   JGROUPS_ENCRYPT_PASSWORD	password
   JGROUPS_ENCRYPT_SECRET	eap-jgroup-secret

4. Create をクリックして JBoss EAP イメージをデプロイします。

手順

1. JBoss EAP アプリケーションサーバーにアクセスし、Login をクリックします。Red Hat Single Sign-On ログインにリダイレクトされます。
2. この例で作成した Red Hat Single Sign-On ユーザーを使用してログインします。Red Hat Single Sign-On サーバーに対して認証され、JBoss EAP アプリケーションサーバーに返されます。

1. カーソルをサイドバーの上部にあるレルム名前空間 (デフォルトは Master) の上に置き、Add Realm をクリックします。
2. レルム名を入力して (この例では saml-demoを使用)、Create をクリックします。

1. Configure サイドバーの Roles をクリックし、このレルムのロールをリスト表示します。これは新しいレルムであるため、デフォルトの offline_access ロールのみが必要です。
2. Add Role をクリックします。
3. ロール名を入力して (この例では、saml-user-role ロールを使用)、Save をクリックします。

1. Manage サイドバーで Users をクリックし、レルムのユーザー情報を表示します。
2. Add User をクリックします。
3. 有効なユーザー名 を入力して (この例ではユーザー app-mgmt-user を使用)、Save をクリックします。
4. ユーザー設定を編集します。ユーザー空間の Credentials タブをクリックし、ユーザーのパスワードを入力します。パスワードを確認した後、Reset Password をクリックしてユーザーパスワードを設定できます。ポップアップウィンドウに追加の確認を求めるプロンプトが表示されます。

1. Manage サイドバーで Users をクリックし、レルムのユーザー情報を表示します。
2. Add User をクリックします。
3. アプリケーションユーザー の有効な ユーザー名 と任意の追加情報を入力し、Save をクリックします。
4. ユーザー設定を編集します。ユーザー空間の Credentials タブをクリックし、ユーザーのパスワードを入力します。パスワードを確認した後、Reset Password をクリックしてユーザーパスワードを設定できます。ポップアップウィンドウに追加の確認を求めるプロンプトが表示されます。
5. Role Mappings をクリックし、レルムおよびクライアントロール設定をリスト表示します。Available Roles で、先に作成したロールを追加します。

1. Configure サイドバーの Clients をクリックし、レルム内のクライアントをリスト表示します。Create をクリックします。
2. 有効な クライアント ID を入力します。この例では sso-saml-demo を使用しています。
3. Client Protocol ドロップダウンメニューで、saml を選択します。
4. アプリケーションの ルート URL を入力します。この例では、https://demoapp-eap-app-demo.openshift32.example.com を使用します。
5. Save をクリックします。

1. Root URL には、クライアントの作成時に使用したアドレスと同じアドレスを入力します。この例では、https://demoapp-eap-app-demo.openshift32.example.com を使用します。
2. Valid Redirect URLs には、ログイン時またはログアウト時にリダイレクトされるユーザーのアドレスを入力します。以下の例では、ルート https://demoapp-eap-app-demo.openshift32.example.com/* に関連してリダイレクトアドレスを使用しています。

1. sso-saml-demo クライアント領域の SAML Keys タブをクリックし、Export をクリックします。
2. この例では、アーカイブ形式 を JKS のままにします。この例では、デフォルトの キーエイリアス sso-saml-demo と、デフォルトのレルム証明書エイリアス saml-demo を使用しています。
3. Key Password と Store Password。この例では、両方の パスワード を使用しています。
4. 後で使用できるように keystore-saml.jks ファイルを ダウンロード して保存します。
5. sso-saml-demo クライアントをクリックして、次の手順の準備が整ったクライアント領域に戻ります。

1. Installation をクリックします。
2. Format Option ドロップダウンメニューを使用してフォーマットを選択します。この例では、Keycloak SAML Wildfly/JBoss Subsystem を使用します。
3. Download をクリックして keycloak-saml-subsystem.xml ファイルを保存します。

手順

1. 新しいプロジェクトを作成します。

   $ oc new-project eap-app-demo

2. view ロールを デフォルト のサービスアカウントに追加します。これにより、サービスアカウントが eap-app-demo 名前空間のすべてのリソースを表示できるようになります。これは、クラスターの管理に必要です。

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

3. EAP テンプレートには、SSL キーストアと JGroups キーストア が必要です。
   この例では、Java Development Kit に含まれるパッケージの keytool を使用して、これらのキーストアの自己署名証明書を生成します。以下のコマンドはパスワードを要求します。
   

   1. SSL キーストアのセキュアキーを生成します。

      $ keytool -genkeypair -alias https -storetype JKS -keystore eapkeystore.jks

   2. JGroups キーストアのセキュアキーを生成します。

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

4. SSL および JGroup キーストアファイルで EAP for OpenShift シークレットを生成します。

   $ oc create secret generic eap-ssl-secret --from-file=eapkeystore.jks
   $ oc create secret generic eap-jgroup-secret --from-file=eapjgroups.jceks

5. EAP アプリケーションシークレットを、以前に作成した EAP サービスアカウントに追加します。

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

手順

1. テキストエディターで /configuration/secure-saml-deployments ファイルを開きます。
2. secure-deployment name タグの YOUR-WAR.war 値を、アプリケーションの .war ファイルに置き換えます。この例では sso-saml-demo.war を使用します。
3. logout page タグの SPECIFY YOUR LOGOUT PAGE! の値を url に置き換え、ユーザーがアプリケーションからログアウトしたときにユーザーをリダイレクトします。この例では、/index.jsp を使用します。

4. <PrivateKeyPem> および <CertificatePem> のタグキーを削除し、これをキーストア情報に置き換えます。

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

   keystore-saml.jks のマウントパス (この例では /etc/eap-secret-volume/keystore-saml.jks) は、EAP_HTTPS_KEYSTORE_DIR パラメーターを使用してアプリケーションテンプレートで指定できます。
   PrivateKey と 証明書 のエイリアスおよびパスワードは、SAML キーが Red Hat Single Sign-On クライアントからエクスポートされたときに設定されていました。

5. 2 番目の <CertificatePem> タグおよびキーを削除し、これをレルム証明書情報に置き換えます。

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

   証明書エイリアスとパスワードは、SAML キーが Red Hat Single Sign-On クライアントからエクスポートされている場合に設定されます。

6. /configuration/secure-saml-deployments ファイルを保存し、閉じます。