流程

1. 使用包含 cluster:admin 角色的用户登录 OpenShift CLI。

2. 创建一个新项目

   $ oc new-project sso-app-demo

3. 将 view 角色添加到 default 服务帐户。这可让服务帐户查看 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 角色添加到 default 服务帐户。这可让服务帐户查看 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

   注意

   要使前面的命令在一个行中正常工作，命令包含进程替换（ <（）语法）。确保您当前的 shell 环境支持此类语法。否则，您可能会遇到与 意外令牌 '（' 消息相关的语法错误。

5. 将 CA 证书导入到 HTTPS 密钥存储中。提供 mykeystorepass 作为密钥存储密码。回复 是 这个证书？[no]: 问题：

   $ 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 密钥存储创建 secret，以及 上一节中 生成的红帽单点登录服务器信任存储。

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

2. 将这些 secret 链接到默认服务帐户，用于运行 Red Hat Single Sign-On Pod。

   $ oc secrets link default sso-app-secret

1. 识别红帽单点登录应用程序的部署配置。

   $ 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 应用容器集。

   $ 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. 打开到用于 OpenShift 容器的 Red Hat Single Sign-On 的远程 shell 会话。

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

3. 在命令行中，通过 add-user-keycloak.sh 脚本为 master realm 创建 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 进程，而不是整个容器。这是因为重启整个容器将从头开始重新创建，无需 Red Hat Single Sign-On 服务器 管理帐户。

5. 使用上述步骤中创建的凭据，登录红帽单点登录服务器的 主域 管理控制台。在浏览器中，进入 http://sso-<project-name>.<hostname>/auth/admin for the Red Hat Single Sign-On web server, or to https://secure-sso-<project-name>.<hostname>/auth/admin for the encrypted Red Hat Single Sign-On web server，并指定用于创建管理员用户的用户名和密码。

流程

1. 首先执行数据库级别备份。

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

2. 缩减 sso 容器集。

   $ 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. 运行以下命令，在 openshift 项目中安装 Red Hat Single Sign-On 7.6.8 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 扩展至一个副本。

    注意

    您可能希望从 dc/sso 中暂时增加存活和就绪度探测阈值和值（以秒为单位）。此步骤在第一次引导时执行数据库升级，这可能需要一些时间。

    $ oc scale --replicas=1 dc/sso

    注意

    如果您有多个副本，请考虑扩展至一个副本。在 Red Hat Single Sign-On 启动后，您可以将 缩减回原始副本数。

1. 识别用于部署容器的部署配置，这些配置在 OpenShift 镜像的红帽单点登录之前版本上运行。

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

2. 在当前命名空间中停止运行之前版本的红帽单点登录的所有 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 到 pod 的文件系统的位置，输出 SQL 迁移文件应存储在这里（例如 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. 从用于运行 OpenShift 镜像的 Red Hat Single Sign-On 的早期版本的部署配置，将数据源定义和数据库访问凭证复制到适合数据库迁移作业模板的位置。

   使用以下脚本，将 DB_SERVICE_PREFIX_MAPPING 和 TX_DATABASE_PREFIX_MAPPING 变量值，以及特定于特定数据源（<PREFIX>_JNDI, <PREFIX>_USERNAME, <PREFIX>_PASSWORD, 和 <PREFIX>_DATABASE) 的环境变量从名为 sso 的部署配置复制到名为 job-to-migrate-db-to-sso76.yaml 的数据库作业迁移模板。

   注意

   虽然 DB_SERVICE_PREFIX_MAPPING 环境变量允许 用逗号分开 < name>-<database_type>=<PREFIX > triplets 列表，但本例脚本只接受一个用于演示目的的数据源 triplet 定义。您可以修改用于处理多个数据源定义脚本。

   $ 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> 字段替换为 pull 规格。

      $ 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

   重要

   数据库迁移过程处理数据架构更新并执行数据操作，因此停止为 OpenShift 镜像运行之前版本的 Red Hat Single Sign-On 的所有 pod，然后再动态生成 SQL 迁移文件。

6. 识别用于部署容器的部署配置，这些配置在 OpenShift 镜像的红帽单点登录之前版本上运行。

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

7. 在当前命名空间中停止运行之前版本的红帽单点登录的所有 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. 手动应用数据库更新。

    • 运行以下命令，如果为 OpenShift 镜像运行一些早期版本的 Red Hat Single Sign-On，则由以临时或持久模式部署的 PostgreSQL 数据库提供支持，并在单独的 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 的 shell 会话。

         $ 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 的 shell 会话。继续 更新镜像更改触发器步骤。

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 上为 OpenShift 镜像设置了 SSO_REALM 配置变量时，将执行数据库导入，以创建 变量所请求的红帽单点登录服务器域。要使数据库导出正确执行，无法在此类镜像上同时定义 SSO_REALM 配置变量。

5. 点击 Create 来部署应用程序模板并启动 Pod 部署。这可能需要几分钟时间。

   然后，使用 管理员帐户 访问位于 https://secure-sso- <sso-app-demo&gt; . <openshift32.example.com> /auth/admin 的 Red Hat Single Sign-On Web 控制台。

   注意

   这个示例工作流使用自生成的 CA 为演示提供一个端到端工作流。访问 Red Hat Single Sign-On Web 控制台将出现不安全的连接警告。
   对于生产环境，红帽建议您使用从验证的证书颁发机构购买的 SSL 证书。

1. 创建一个 realm
2. 创建用户

流程

1. 获取红帽单点登录部署配置并将其缩减为零。

   $ 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 7.6.8 服务器上部署的 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 服务器并导出其数据库。

   $ 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 文件导入到另一个环境中运行的红帽单点登录服务器。

   注意

   有关导入到 OpenShift 上未运行的 Red Hat Single Sign-On 服务器，请参阅 导入和导出数据库。

   当 Red Hat Single Sign-On 服务器作为 Red Hat Single Sign-On 7.6.8 容器运行时，使用 Admin Console Export/Import 功能将资源从之前导出的 JSON 文件导入到 Red Hat Single Sign-On 服务器数据库中。

   1. 使用用于创建管理员用户的凭据，登录红帽单点登录服务器的 主域 管理控制台。在浏览器中，导航到 Red Hat Single Sign -On web 服务器的 http://sso-<project-name>.<hostname>/auth/admin，或指向加密的红帽 Single Sign -On web 服务器的 https://secure-sso-<project-name>.<hostname>/auth/admin。
   2. 在侧边栏的顶部，选择 Red Hat Single Sign-On 域的名称、用户、客户端、域角色和客户端角色。本例使用 master realm。
   3. 单击侧栏底部的 Manage 部分下的 Import 链接。
   4. 在打开的页面中，单击 Select file，然后指定本地文件系统中导出的 demorealm-export.json JSON 文件的位置。
   5. 在 Import from realm 下拉菜单中选择应从其中导入数据的 Red Hat Single Sign-On 域的名称。本例使用 master realm。
   6. 选择应导入哪些用户、客户端、域角色和客户端角色（所有这些角色都默认导入）。

   7. 选择要执行的策略，即资源已存在（ Fail、Skip 或 Overwrite之一）。

      注意

      如果当前数据库中已存在具有相同标识符的对象，尝试导入对象（用户、客户端、域角色或客户端角色）。使用 Skip 策略导入 demorealm-export.json 文件中存在的对象，但不存在于当前数据库中。

   8. 单击 Import 以执行导入。

      当将对象从非 master 域导入到 master 域时，点 Import 按钮后，有时可能会出现类似以下的错误：

      

      在这种情况下，首先需要创建缺少的客户端，将 Access Type 设为 bearer-only。这些客户端可通过从源红帽单点登录服务器（创建导出 JSON 文件）到目标红帽单点登录服务器（其中导入 JSON 文件）的特征来创建。创建必要的客户端后，再次单击 导入 按钮。

      要绕过 上述 错误消息，需要创建缺少的 realm-management 客户端（使用 bearer-only Access Type ），然后再次单击 Import 按钮。

      对于 Skip import 策略，新添加的对象被标记为 ADDED 和跳过的对象，在导入结果页面的 Action 列中被标记为 SKIPPED。

      如果选择（ 覆盖 策略）, Admin Console 导入允许您覆盖 资源。在生产环境中，请谨慎使用此功能。

1. 将光标悬停在域命名空间（默认为 主栏的顶部），然后单击 Add Realm。
2. 输入 realm 名称（本示例使用 OpenShift）并点 Create。

1. 单击 Manage sidebar 中的 Users，以查看域的用户信息。
2. 单击 添加用户。
3. 输入一个有效的 Username （本示例使用 testuser）和任何其他可选信息，然后单击保存。

4. 编辑用户配置：

   1. 单击用户空间中的 Credentials 选项卡，然后输入用户的密码。
   2. 确保将 Temporary Password 选项设为 Off，以便它不会稍后提示输入密码，然后单击 Reset Password 来设置用户密码。弹出窗口提示进行额外的确认。

1. 单击 Manage 栏中的 Clients，再单击 Create。
2. 输入 客户端 ID。这个示例使用 openshift-demo。
3. 从下拉菜单中选择 Client Protocol （本例使用 openid-connect）并点 Save。您将进入 openshift-demo 客户端的配置设置页面。
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 身份提供程序，则 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 hash 可在 Red Hat Single Sign-On Web 控制台中找到： Clients → openshift-demo → Credentials

   2. 可以通过使用红帽单点登录应用程序发出请求来查找 urls 的端点。例如：

      <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 master：

   $ systemctl restart atomic-openshift-master

流程

1. 导航到 OpenShift Web 控制台，在这个示例中为 https://openshift.example.com:8443/console。

   OpenShift 登录页面现在提供使用 htpasswd_auth 或 rh-sso 身份提供程序登录的选项？前者仍然可用，因为它存在于 /etc/origin/master/master-config.yaml 中。

2. 选择 rh-sso，再使用之前在红帽单点登录中创建的 testuser 用户登录 OpenShift。

   在 OpenShift CLI 中添加项目之前，项目对 testuser 可见。这是在 OpenShift 中提供用户特权的唯一方法，因为它目前不接受外部角色映射。

3. 要为 sso-app-demo 提供 testuser 视图 特权，请使用 OpenShift CLI：

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

1. 创建一个新项目

   $ oc new-project eap-app-demo

2. 将 view 角色添加到 default 服务帐户。这可让服务帐户查看 eap-app-demo 命名空间中的所有资源，这是管理集群所必需的。

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

3. EAP 模板需要 SSL 密钥存储和 JGroups 密钥存储。
   本例使用 keytool （Java Development Kit 中包含的软件包）为这些密钥存储生成自签名证书。以下命令将提示输入密码。
   

   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 密钥存储文件为 OpenShift 机密生成 EAP：

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

5. 将 EAP secret 添加到 default 服务帐户：

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

1. 将光标悬停在侧边栏顶部的 realm 命名空间上，然后单击 Add Realm。
2. 输入 realm 名称（本例使用 eap-demo），然后点 Create。

1. 单击 Configure 边栏中的 Roles，以列出此域的角色。这是一个新域，因此只有默认的 offline_access 角色。
2. 点 Add Role。
3. 输入角色名称（本例使用 role eap-user-role），然后单击 Save。

1. 单击 Manage sidebar 中的 Users，以查看域的用户信息。
2. 单击 添加用户。
3. 输入一个有效的 Username （本例使用用户 eap-mgmt-user）并单击 Save。
4. 编辑用户配置。单击用户空间中的 Credentials 选项卡，然后输入用户的密码。确认密码后，您可以单击 重置密码 以设置用户密码。弹出窗口提示进行额外的确认。
5. 单击 Role Mappings，以列出 realm 和 client 角色配置。在 Client Roles 下拉菜单中，选择 realm-management 并将所有可用的角色添加到用户。这提供了红帽单点登录服务器权限，供 JBoss EAP 镜像用于创建客户端。

1. 单击 Manage sidebar 中的 Users，以查看域的用户信息。
2. 单击 添加用户。
3. 输入一个有效的 Username 以及 应用程序用户 的额外可选信息，然后点 Save。
4. 编辑用户配置。单击用户空间中的 Credentials 选项卡，然后输入用户的密码。确认密码后，您可以单击 重置密码 以设置用户密码。弹出窗口提示进行额外的确认。
5. 单击 Role Mappings，以列出 realm 和 client 角色配置。在 Available Roles 中，添加之前创建的角色。

1. 返回到 OpenShift Web 控制台，点 Add to project 列出默认镜像流和模板。
2. 使用 Filter by keyword 搜索栏，将列表限制为与 sso 匹配的列表。您可能需要点击 See all 以显示所需的应用程序模板。

3. 选择 eap71-sso-s2i 镜像，以列出所有部署参数。包含以下 Red Hat Single Sign-On 参数，以在 EAP 构建期间配置 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 应用服务器，然后单击 登录。您将被重定向到 Red Hat Single Sign-On 登录。
2. 使用在示例中创建的 Red Hat Single Sign-On 用户登录。您已通过 Red Hat Single Sign-On 服务器进行身份验证，并返回给 JBoss EAP 应用服务器。

1. 将光标悬停在域命名空间（默认为 主栏的顶部），然后单击 Add Realm。
2. 输入 realm 名称（本例使用 saml-demo），然后点 Create。

1. 单击 Configure 边栏中的 Roles，以列出此域的角色。这是一个新域，因此只有默认的 offline_access 角色。
2. 点 Add Role。
3. 输入角色名称（本例使用 role saml-user-role）并点 Save。

1. 单击 Manage sidebar 中的 Users，以查看域的用户信息。
2. 单击 添加用户。
3. 输入一个有效的 Username （本示例使用用户 app-mgmt-user）并点 Save。
4. 编辑用户配置。单击用户空间中的 Credentials 选项卡，然后输入用户的密码。确认密码后，您可以单击 重置密码 以设置用户密码。弹出窗口提示进行额外的确认。

1. 单击 Manage sidebar 中的 Users，以查看域的用户信息。
2. 单击 添加用户。
3. 输入一个有效的 Username 以及 应用程序用户 的额外可选信息，然后点 Save。
4. 编辑用户配置。单击用户空间中的 Credentials 选项卡，然后输入用户的密码。确认密码后，您可以单击 重置密码 以设置用户密码。弹出窗口提示进行额外的确认。
5. 单击 Role Mappings，以列出 realm 和 client 角色配置。在 Available Roles 中，添加之前创建的角色。

1. 单击 Configure 边栏中的 Clients，以列出域中的客户端。点 Create。
2. 输入一个有效 的客户端 ID。这个示例使用 sso-saml-demo。
3. 在 Client Protocol 下拉菜单中选择 saml。
4. 输入应用程序的 Root URL。这个示例使用 https://demoapp-eap-app-demo.openshift32.example.com。
5. 点击 Save。

1. 对于 Root URL，请输入创建客户端时使用的相同地址。这个示例使用 https://demoapp-eap-app-demo.openshift32.example.com。
2. 对于 有效的重定向 URL，在登录或注销时输入要重定向到的用户的地址。这个示例使用相对于 root https://demoapp-eap-app-demo.openshift32.example.com/* 的重定向地址。

1. 点 sso-saml-demo 客户端空间中的 SAML Keys 标签页，点 Export。
2. 在本例中，将 归档格式 保留为 JKS。这个示例使用 sso-saml-demo 的默认 Key Alias 和 default Realm Certificate Alias of saml-demo。
3. 输入密钥密码 ， 并输入 "存储密码 "。这个示例使用 password。
4. 单击 Download 并保存 密钥存储-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 角色添加到 default 服务帐户。这可让服务帐户查看 eap-app-demo 命名空间中的所有资源，这是管理集群所必需的。

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

3. EAP 模板需要 SSL 密钥存储和 JGroups 密钥存储。
   本例使用 keytool （Java Development Kit 中包含的软件包）为这些密钥存储生成自签名证书。以下命令将提示输入密码。
   

   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 密钥存储文件为 OpenShift 机密生成 EAP：

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

5. 将 EAP 应用程序 secret 添加到之前创建的 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. 删除 & lt;PrivateKeyPem& gt; 和 < 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 参数在应用程序模板中指定。
   当从 Red Hat Single Sign-On 客户端导出 SAML 密钥时，配置的 PrivateKey 和 Certificate 的别名和密码。

5. 删除第二个 & lt;CertificatePem > 标签和密钥，并将其替换为 realm 证书信息：

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

   从 Red Hat Single Sign-On 客户端导出 SAML 密钥时，会配置证书别名和密码。

6. 保存并关闭 /configuration/secure-saml-deployments 文件。