red hat single sign-on 7.4 アップグレードガイド...red hat single sign-on サーバーが...

Red Hat Single Sign-On 7.4

アップグレードガイド

Red Hat Single Sign-On 7.4 向け

Last Updated: 2021-04-01

Red Hat Single Sign-On 7.4 アップグレードガイド

Red Hat Single Sign-On 7.4 向け

Enter your first name here. Enter your surname here.Enter your organisation's name here. Enter your organisational division here.Enter your email address here.

法律上の通知法律上の通知

Copyright © 2021 | You need to change the HOLDER entity in the en-US/Upgrading_Guide.ent file|.

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

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

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United Statesand other countries.

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

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

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

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

Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by theofficial Joyent Node.js open source or commercial project.

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

All other trademarks are the property of their respective owners.

概要概要

本ガイドは、以前のバージョンの Red Hat Single Sign-On 7.4 からアプリケーションのアップグレードを説明します。

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

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

目次目次

第第1章章はじめにはじめに1.1. アップグレードについて

1.1.1. メジャーアップグレード1.1.2. マイナーアップデート1.1.3. マイクロアップデート

1.2. KEYCLOAK からの移行

第第2章章変更変更2.1. RH SSO 7.4

2.1.1. EAP 7.3 へのアップグレード2.1.1.1. 依存関係の更新2.1.1.2. 設定変更2.1.1.3. データセンター間のレプリケーションの変更

2.1.2. 認証フローの変更2.1.2.1. 同じ認証フローで REQUIRED および許可される NATIVE の実行はサポートされない2.1.2.2. オプション実行要件の削除2.1.2.3. SPI の変更2.1.2.4. Freemarker テンプレートの変更

2.1.3. ユーザー認証情報の変更2.1.4. 新しいオプションのクライアントスコープ2.1.5. ユーザーロケールの処理が改善2.1.6. JavaScript アダプターにおけるレガシーのイニュレーション2.1.7. サーバーへのスクリプトのデプロイ2.1.8. JavaScript アダプターのクライアント認証情報2.1.9. 新しいデフォルトホスト名プロバイダー2.1.10. 非推奨または削除された機能

2.1.10.1. トークン表現 Java クラスで非推奨となったメソッド2.1.10.2. スクリプトのアップロード

2.1.11. 承認サービスの Drools ポリシー2.2. RH-SSO 7.3

2.2.1. 認証サービスの変更2.2.2. クライアントスコープに変更になったクライアントテンプレート2.2.3. 新しいデフォルトクライアントスコープ

2.2.3.1. プロトコルマッパー SPI の追加2.2.3.2. オーディエンスの解決

2.2.4. EAP 7.2 へのアップグレード2.2.5. ホスト名の設定2.2.6. JavaScipt Adapter Promise2.2.7. Microsoft Identity Provider が Microsoft Graph API を使用するように更新2.2.8. Google ID プロバイダーが Google Sign-in 認証システムを使用するように更新されました。2.2.9. LinkedInž Broker が LinkedIn API のバージョン 2 へ更新されました。

2.3. RH-SSO 7.22.3.1. 新しいパスワードハッシュアルゴリズム2.3.2. ID Token には scope=openid が必要です2.3.3. Microsoft SQL Server には追加の依存関係が必要2.3.4. OpenID Connect の認証レスポンスに session_state パラメーターを追加2.3.5. Microsoft Identity Provider が Microsoft Graph API を使用するように更新2.3.6. Google ID プロバイダーが Google Sign-in 認証システムを使用するように更新されました。2.3.7. LinkedInž Broker が LinkedIn API のバージョン 2 へ更新されました。

2.4. RH-SSO 7.12.4.1. レルムキー

444444

6666666667777777888888999

10101011111111

121212121213131313141414

目次目次

1

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

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

2.4.2. クライアントのリダイレクト URI 一致2.4.3. アイデンティティープロバイダーへの自動リダイレクト2.4.4. Management REST API2.4.5. サーバー設定2.4.6. SAML 評価における鍵暗号化アルゴリズム

第第3章章 RED HAT SINGLE SIGN-ON サーバーのアップグレードサーバーのアップグレード3.1. マイナーアップグレード

3.1.1. アップグレードの準備3.1.2. Red Hat Single Sign-On サーバーのアップグレード

3.1.2.1. スタンドアロンモードアップグレードスクリプトの実行3.1.2.2. スタンドアロン高可用性モードアップグレードスクリプトの実行3.1.2.3. ドメインモードアップグレードスクリプトの実行3.1.2.4. ドメインクラスターモードアップグレードスクリプトの実行

3.1.3. データベースの移行3.1.3.1. データベースの自動移行3.1.3.2. 手動による関係データベース移行

3.1.4. 写真の移行3.1.4.1. テーマの変更 RH-SSO 7.33.1.4.2. Theme changes RH-SSO 7.23.1.4.3. Theme changes RH-SSO 7.13.1.4.4. テンプレートの移行3.1.4.5. メッセージの移行3.1.4.6. シェイプの移行

3.2. マイクロアップグレード3.2.1. ZIP/インストーラーインストールのパッチ適用

3.2.1.1. ZIP インストールパッチに関する重要事項3.2.1.2. パッチの適用3.2.1.3. パッチのロールバック3.2.1.4. パッチ履歴の消去

3.2.2. RPM インストールのパッチ適用3.2.3. ローカル Maven インストールのパッチ適用

3.2.3.1. 前提条件3.2.3.2. ローカルにインストールされた RH-SSO クライアントアダプター Maven リポジトリーの更新

第第4章章 RED HAT SINGLE SIGN-ON アダプターのアップグレードアダプターのアップグレード4.1. 古いアダプターとの互換性4.2. EAP アダプターのアップグレード4.3. JAVASCRIPT アダプターのアップグレード4.4. NODE.JS アダプターのアップグレード

1515151515

1616161618181819191919

2020222424252526262626293233333333

3535353536

Red Hat Single Sign-On 7.4 アップグレードガイドアップグレードガイド

2

目次目次

3

第1章はじめにRed Hat Single Sign-On(RH-SSO)7.4 は Keycloak プロジェクトをベースとしており、SAML 2.0、OpenID Connect、OAuth 2.0 などの一般的な標準に基づいて Web シングルサインオン機能を提供することで、Web アプリケーションのセキュリティーを提供します。Red Hat Single Sign-On サーバーは、SAML または OpenID Connect ベースのアイデンティティープロバイダーとして機能することができ、標準ベースのトークンを使用してエンタープライズユーザーディレクトリーまたは ID 情報用のサードパーティー SSO プロバイダーとアプリケーションを仲介します。

RH-SSO は、スタンドアロンサーバーまたは管理対象ドメインの 2 つの動作モードを提供します。スタンドアロンサーバーの動作モードは、単一のサーバーインスタンスとして RH-SSO を実行することを表します。管理対象ドメインの操作モードでは、単一の制御ポイントから複数の RH-SSO インスタンスを管理できます。アップグレードプロセスは、実装されている操作モードによって異なります。各モードの特定の手順は、必要に応じて提供されます。

本ガイドの目的は、Red Hat Single Sign-On 7.x から Red Hat Single Sign-On 7.4 へのアップグレードに必要な手順を文書化することです。

1.1. アップグレードについて

1.1.1. メジャーアップグレード

Red Hat Single Sign-On 7.2 から Red Hat Single Sign-On 8.0 など、RH-SSO を別のメジャーリリースにアップグレードする場合は、メジャーアップグレードまたは移行が必要です。メジャーリリース間でAPI の変更が切断される可能性があります。この場合、アプリケーションまたはサーバーエクステンションの一部を再書き込みする必要が生じる可能性があります。

1.1.2. マイナーアップデート

Red Hat Single Sign-On は、定期的にポイントリリースを提供します。ポイントリリースは、バグ修正、セキュリティー修正、新機能を含むマイナーアップデートです。Red Hat Single Sign-On のポイントリリースから別のリリースにアップグレードする予定（例： Red Hat Single Sign-On 7.3 から RedHat Single Sign-On 7.4 など）、アプリケーションまたはカスタムサーバーの拡張機能には、プライベート、サポート対象外、またはテクノロジープレビュー API がない限り、コードの変更は必要ありません。

1.1.3. マイクロアップデート

Red Hat Single Sign-On 7.4 は、バグおよびセキュリティー修正を含むマイクロリリースも定期的に提供します。マイクロリリースは、マイナーリリースバージョンを最後の数字で増やします（例： 7.4.0から 7.4.1）。これらのリリースには移行が必要ないため、サーバー設定ファイルには影響を及ぼすべきではありません。ZIP インストールのパッチ管理システムは、パッチおよびサーバー設定をロールバックすることもできます。

マイクロリリースには変更されたアーティファクトのみが含まれます。たとえば、Red Hat SingleSign-On 7.4.1 にサーバーおよび JavaScript アダプターの変更が含まれる場合は、EAP アダプターではなく、サーバーおよび JavaScript アダプターのみがリリースされ、更新が必要です。

1.2. KEYCLOAK からの移行

Keycloak（コミュニティープロジェクト）から、サポートされる Red Hat 製品である Red Hat SingleSign-On に移行することができます。


4

前提条件前提条件

アップグレード前に新機能を確認するには、変更を確認します。

開始点として正しいバージョンの Keycloak をインストールしていることを確認します。RedHat Single Sign-On 7.4 に移行するには、Keycloak 9.0.x が必要です。

手順手順

1. マイナーリリースのアップグレード手順を実行します。この手順にはマイナーアップグレードマイナーアップグレードのラベルが付けられていますが、この移行には同じ手順が適用されます。

2. アダプターアップグレード手順を実行します。

第第1章章はじめにはじめに

5

第2章変更アップグレードする前に、これらの変更を慎重に確認してください。

2.1. RH SSO 7.4

Red Hat Single Sign-On 7.3 から Red Hat Single Sign-On 7.4 への以下の変更が行われました。

2.1.1. EAP 7.3 へのアップグレード

Red Hat Single Sign-On サーバーが、EAP 7.3 を基礎となるコンテナーとして使用するようにアップグレードされました。この変更は、特定の Red Hat Single Sign-On サーバー機能に直接関与する訳ではありませんが、移行に関連するいくつかの変更がいくつかあります。

2.1.1.1. 依存関係の更新依存関係の更新

依存関係は EAP 7.3 サーバーによって使用されるバージョンに更新されました。たとえば、Infinispanコンポーネントバージョンは 9.3.1.Final になりました。

2.1.1.2. 設定変更設定変更

standalone(-ha).xml ファイルおよび domain.xml ファイルにはいくつかの設定変更があります。「RedHat Single Sign-On サーバーのアップグレード」セクションに従って、設定ファイルの自動移行を処理します。

2.1.1.3. データセンター間のレプリケーションの変更データセンター間のレプリケーションの変更

JDG をバージョン 7.3.5 にアップグレードする必要があります。古いバージョンは依然として機能している可能性がありますが、テストされていないため、正常に機能することが保証されていません。

2.1.2. 認証フローの変更

認証フローに関連するリファクタリングおよび改善が行われました。これには、移行時に注意が必要です。

2.1.2.1. 同じ認証フローで同じ認証フローで REQUIRED および許可されるおよび許可される NATIVE の実行はサポートされないの実行はサポートされない

以前は、同じ認証フローで、REQUIRED および BSDNATIVE の実行を同じレベルで行うことができました。このアプローチには問題がいくつかあり、認証 SPI でリファクタリングしました。つまり、これが有効ではなくなったことを意味します。IINATIVE および REQUIRED の実行が同じレベルで設定されている場合、NATIVE の実行は無効とみなされます。

したがって、このバージョンに移行すると、既存の認証フローは移行されますが、以前のバージョンの動作を維持します。認証フローに REQUIRED の実行レベルと同じレベルでは、認証フローに含まれると、その実行を別の REQUIRED サブフローに追加されます。

このストラテジーは、各認証フローを以前のバージョンと同じか、または同様の動作になるようにする必要があります。ただし、認証フローの設定を確認し、期待通りに機能していることを確認する必要があります。この推奨事項は、カスタムオーセンティケーター実装を使用したカスタマイズされた認証フローにとくに適用されます。

2.1.2.2. オプション実行要件の削除オプション実行要件の削除

移行について最も重要な変更は、認証実行から OPTIONAL 要件のサポートを削除し、これを


6

移行について最も重要な変更は、認証実行から OPTIONAL 要件のサポートを削除し、これをCONDITIONAL 要件に置き換えることです。これにより、柔軟性が向上します。

以前のバージョンで設定された OPTIONAL オーセンティケーターは、CONDITIONAL サブフローに置き換えられます。これらのサブフローには、Condition - User Configured condition が最初の実行として設定されており、2 回の実行として以前の OPTIONAL オーセンティケーター（OTP Form など）が設定されます。ユーザーの場合、認証中の動作は以前のバージョンの動作に一致します。

2.1.2.3. SPI の変更の変更

Java Authentication SPI および認証情報プロバイダー SPI にはいくつかの変更が存在します。

インターフェースオーセンティケーターは変更されていませんが、新しいクレデンシャルタイプ（CredentialModel のサブクラス）を導入する高度なオーセンティケーターを開発する場合には、影響を受ける可能性があります。変更は CredentialProvider インターフェースに存在し、CredentialValidator などの新しいインターフェースが導入されました。

また、オーセンティケーターが OPTIONAL 実行要件に対応している場合は、影響を受ける可能性があります。詳細は、サーバー開発ガイドの最新の認証例を再確認してください。

2.1.2.4. Freemarker テンプレートの変更テンプレートの変更

変更はフリーマーク用テンプレートに存在します。特に OTP に関連するフォームについては、ログインフォームまたはアカウントフォームのカスタムフリーマーカーのテンプレートが含まれる自分専用のテーマがある場合は、影響を受ける可能性があります。このバージョンの Freemarker テンプレートの変更を確認し、テンプレートを調整することが推奨されます。

2.1.3. ユーザー認証情報の変更

ユーザー認証情報を格納するための柔軟性が追加されました。たとえば、すべてのユーザーが、複数のOTP 認証情報など、同じタイプの認証情報を複数持つこともできます。データベーススキーマに関連する変更がいくつかありますが、以前のバージョンの認証情報は新しい形式に更新されます。ユーザーは、以前のバージョンで定義したパスワードまたは OTP 認証情報を使用してログインできます。

2.1.4. 新しいオプションのクライアントスコープ

MicroProfile/JWT Auth Specification で定義されたクレームを処理する microprofile-jwt オプションクライアントスコープを追加しました。この新しいクライアントスコープは、認証されたユーザーのユーザー名を upn クレームに設定し、レルムロールを groups 要求に設定するプロトコルマッパーを定義します。

2.1.5. ユーザーロケールの処理が改善

ログインページのロケールの選択方法や、ユーザーのロケールが更新されるタイミングが数多く改善されました。詳細は『サーバー管理ガイド』を参照してください。

2.1.6. JavaScript アダプターにおけるレガシーのイニュレーション

JavaScript アダプターで experimentalType を設定する必要はなく、両方を同時に利用できます。レガシー API（成功およびエラー）が削除されるため、できるだけ早期にネイティブのプロセッシングAPI（成功およびキャッチ）を使用するようにアプリケーションを更新することが推奨されます。

2.1.7. サーバーへのスクリプトのデプロイ

それまでは、管理者は Red Hat Single Sign-On 管理コンソールおよび RESTful Admin API 経由でスクリ

第第2章章変更変更

7

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/server_administration_guide/

それまでは、管理者は Red Hat Single Sign-On 管理コンソールおよび RESTful Admin API 経由でスクリプトをサーバーにアップロードできました。この機能は無効になりました。ユーザーは、スクリプトを直接サーバーにデプロイする必要があります。詳細は、JavaScript プロバイダーを参照してください。

2.1.8. JavaScript アダプターのクライアント認証情報

以前のリリースでは、開発者は JavaScript アダプターにクライアントクレデンシャルを提供することができました。現時点で、クライアント側のアプリケーションはシークレットを保持することは安全ではないため、この機能は削除されました。prompt=none をデフォルトの IDP に伝播する機能

Accepts prompt=none forward from client という OIDC アイデンティティープロバイダー設定にスイッチを追加し、prompt=none クエリーパラメーターを含む転送されたリクエストを処理できる IDP を特定しました。

prompt=none で認証要求を受信すると、ユーザーが IDP によって認証されているかどうかを確認せずにユーザーがレルムで認証されないと、レルムは login_required エラーを返すようになりました。これ以降、デフォルトの IDP が認証要求に対して判別できる場合（kc_idp_hint クエリーパラメーターを使用するか、レルムのデフォルト IDP を設定して）、Accepts prompt=none forward from クライアントスイッチからの転送が IDP に対して有効になっている場合、認証リクエストは IDP に転送され、ユーザーが認証されているかどうかを確認するために IDP に転送されます。

このスイッチは、デフォルトの IDP が指定されている場合のみ考慮することが重要です。この場合、ユーザーが IDP を選択するように求めずに auth 要求を転送する場所を把握しておくことが重要です。デフォルトの IDP を判断できない場合は、認証要求を満たすために使用されるものを指定できず、リクエスト転送は行われません。

2.1.9. 新しいデフォルトホスト名プロバイダー

要求および修正されたホスト名プロバイダーは、新しいデフォルトホスト名プロバイダーに置き換えられました。リクエストおよび固定ホスト名プロバイダーは非推奨となり、できるだけ早くデフォルトのホスト名プロバイダーに切り替えることが推奨されます。

2.1.10. 非推奨または削除された機能

特定の機能のステータスが変更になりました。

2.1.10.1. トークン表現トークン表現 Java クラスで非推奨となったメソッドクラスで非推奨となったメソッド

2038 年目では、int は1970 年以降の秒数で保持できなくなりました。したがって、これらを長い値に更新しています。トークン表現には、さらなる問題があります。デフォルトでは、int は JSON 表現で0 になりますが、含めるべきではありません。

非推奨となった方法および置き換えされたメソッドの詳細は、JavaDocs のドキュメントを参照してください。

2.1.10.2. スクリプトのアップロードスクリプトのアップロード

管理 REST エンドポイントおよびコンソールを使用したスクリプトのアップロードが非推奨となりました。これは今後のリリースで削除されます。

2.1.11. 承認サービスの Drools ポリシー

承認サービスの Drools ポリシーが削除されました。


8

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/server_developer_guide/#_script_providers

https://access.redhat.com/webassets/avalon/d/red-hat-single-sign-on/version-7.4/javadocs/

2.2. RH-SSO 7.3

RH-SSO 7.2 から RH-SSO 7.3 への以下の変更が行われました。

2.2.1. 認証サービスの変更

UMA 2.0 のサポートが追加されました。UMA 仕様のこのバージョンでは、サーバーからパーミッションを取得する方法に関する重要な変更がいくつか加えられました。

以下は、UMA 2.0 サポートで導入された主な変更点です。詳細は、『承認サービスガイド』を参照してください。

承認承認 API の削除の削除

UMA 2.0(UMA 1.0)より前のバージョンでは、クライアントアプリケーションは Authorization API を使用して RPT 形式のサーバーからパーミッションを取得していました。新しいバージョンの UMA仕様では、Red Hat Single Sign-On から削除された Authorization API が削除されました。UMA 2.0では、特定の付与タイプを使用して、RPT をトークンエンドポイントから取得できるようになりました。詳細は、『承認サービスガイド』を参照してください。

エンタイトルメントエンタイトルメント API が削除されました。が削除されました。

UMA 2.0 の導入に伴い、トークンエンドポイントと UMA 付与タイプを利用して、Red Hat SingleSign-On から RPT を取得でき、異なる API が使用されないようにします。Entitlement API が提供する機能は同じで、リソースまたはスコープが指定されていない場合でも、サーバーから 1 つ以上のリソースおよびスコープのセットまたはすべてのパーミッションを取得することができます。詳細は、『承認サービスガイド』を参照してください。

UMA 検出エンドポイントへの変更検出エンドポイントへの変更

UMA Discovery ドキュメントが変更されました。詳細は、Authorization Services Guide を参照してください。

Red Hat Single Sign-On 認証認証 JavaScript アダプターの変更アダプターの変更

UMA 2.0 で導入された変更に従い、Red Hat Single Sign-On の Authorization JavaScriptAdapter(keycloak-authz.js)が変更されました。主な変更点は、authorization と entitlement メソッドの両方を呼び出す方法にあります。これにより、認証要求を表す特定のオブジェクトタイプが期待されます。この新しいオブジェクトタイプにより、UMA 付与タイプでサポートされる異なるパラメーターをサポートすることで、サーバーからパーミッションを取得できる柔軟性が向上します。詳細は、『承認サービスガイド』を参照してください。

One of the main changes introduced by this release is that you are no longer required to exchange access tokens with RPTs inorder to access resources protected by a resource server (when not using UMA). Depending on how the policy enforcer is configured on the resource server side, you can just send regularaccess tokens as a bearer token and permissions will still be enforced.

Red Hat Single Sign-On 認証クライアント認証クライアント Java API への変更への変更

Red Hat Single Sign-On Authorization Client Java API の新しいバージョンにアップグレードする際に、一部の表現クラスが org.keycloak:keycloak-core の別のパッケージに移動したことに注意してください。

2.2.2. クライアントスコープに変更になったクライアントテンプレート

クライアントスコープのサポートが追加されました。これには、移行時に注意が必要です。

クライアントスコープに変更になったクライアントテンプレートクライアントスコープに変更になったクライアントテンプレート

クライアントテンプレートがクライアントスコープに変更になりました。クライアントテンプレー


9

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/authorization_services_guide/

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/authorization_services_guide/#_service_obtaining_permissions

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/authorization_services_guide/#_service_obtaining_permissions

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/authorization_services_guide/#_service_authorization_api

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/authorization_services_guide/#_enforcer_js_adapter

クライアントテンプレートがクライアントスコープに変更になりました。クライアントテンプレートがある場合、プロトコルマッパーとロールスコープのマッピングは保持されます。

名前に置き換えたスペース名前に置き換えたスペース

クライアントテンプレートには、クライアントスコープの名前でスペースを指定できないため、スペースをアンダースコアに置き換えることで名前が変更になりました。たとえば、クライアントテンプレート my template はクライアントスコープ my_template に変更されます。

クライアントへのクライアント範囲のリンククライアントへのクライアント範囲のリンク

クライアントテンプレートを持つクライアントでは、対応するクライアントスコープが Default Client Scope としてクライアントに追加されます。したがって、プロトコルマッパーとロールスコープのマッピングはクライアントで保持されます。

レルムデフォルトクライアントスコープが既存のクライアントとリンクされていないレルムデフォルトクライアントスコープが既存のクライアントとリンクされていない

移行時に、組み込みクライアントスコープのリストが、各レルムと、レルムのデフォルトクライアレルムのデフォルトクライアントスコープントスコープのリストが追加されます。ただし、既存のクライアントはアップグレードされず、新しいクライアントスコープは自動的に追加されません。また、すべてのプロトコルマッパーおよびロールスコープマッピングは、既存のクライアントに保持されます。新しいバージョンでは、新しいクライアントを作成すると、自動的に Realm Default Client Scopes がアタッチされ、プロトコルマッパーが割り当てられません。クライアントのプロトコルマッパー用に持つカスタマイズを適切に検出できないため、移行時に既存のクライアントは変更されませんでした。既存のクライアントを更新する場合（それらのクライアントからプロトコルマッパーを削除して、クライアントスコープにリンクする）場合は、手動で操作を行う必要があります。

同意書を再度確認する必要があります同意書を再度確認する必要があります

クライアントスコープの変更では、同意のリファクタリングが必要になります。現在は、ロールやプロトコルマッパーではなく、クライアントスコープを参照するようになりました。この変更により、これまで確認された永続的な同意は有効ではなくなるため、ユーザーは移行後に同意ページを再度確認する必要があります。

一部の設定スイッチが削除される一部の設定スイッチが削除される

スイッチ Scope Param Required がロールの詳細から削除されました。Consent Required スイッチおよび Consent Text スイッチが、プロトコルマッパーの詳細から削除されました。これらのスイッチはクライアントスコープ機能に置き換えられました。

2.2.3. 新しいデフォルトクライアントスコープ

新しいレルムのデフォルトクライアントスコープ roles および web-origins を追加しました。これらのクライアントスコープには、ユーザーのロールを追加するプロトコルマッパーが含まれ、許可されるWeb オリジンをトークンに追加します。移行時に、これらのクライアントスコープは、デフォルトのクライアントスコープとしてすべての OpenID Connect クライアントに自動的に追加する必要があります。したがって、データベースの移行が完了した後には、設定は必要ありません。

2.2.3.1. プロトコルマッパープロトコルマッパー SPI の追加の追加

これに関連し、（サポート対象外の）Protocol Mappers SPI に追加されています。カスタムProtocolMapper を実装している場合にのみ、影響を受けることができます。ProtocolMapper インターフェースには、新しい getPriority() メソッドがあります。メソッドのデフォルト実装は return 0 に設定されています。プロトコルマッパー実装が、realmAccess プロパティーまたは resourceAccess プロパティーのロールに依存する場合は、マッパーの優先度を増やす必要がある場合があります。

2.2.3.2. オーディエンスの解決オーディエンスの解決

認証されたユーザーには、トークンに最低でも 1 つのクライアントロールがあるすべてのクライアントのオーディエンスが、アクセストークンの aud 要求に自動的に追加されるようになりました。一方、アクセストークンには、フロントエンドクライアントのオーディエンスが自動的に含まれない場合があります。詳細は『サーバー管理ガイド』を参照してください。


10

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/server_administration_guide/#_audience

2.2.4. EAP 7.2 へのアップグレード

Red Hat Single Sign-On サーバーが、EAP 7.2 を基礎となるコンテナーとして使用するようにアップグレードされました。これは、特定の Red Hat Single Sign-On サーバー機能に直接関与する訳ではありませんが、移行に関連する変更はほとんどありませんが、注意すべき変更点はいくつかあります。

依存関係の更新依存関係の更新

依存関係は EAP 7.2 サーバーによって使用されるバージョンに更新されました。たとえば、Infinispan は 9.3.1.Final になります。

設定変更設定変更

standalone(-ha).xml および domain.xml ファイルの設定変更はほとんどありません。設定ファイルの移行を自動的に処理するには、「Red Hat Single Sign-On サーバーのアップグレード」セクションに従う必要があります。

データセンター間のレプリケーションの変更データセンター間のレプリケーションの変更

JDG サーバーをバージョン 7.3.5 にアップグレードする必要があります。古いバージョンは依然として機能している可能性がありますが、テストしていないため保証されません。

Red Hat Single Sign-On 設定の remote-store 要素の設定に、値が 2.6 の protocolVersionプロパティーを追加する必要があります。これは、HotRod プロトコルのバージョンをダウングレードして JDG 7.3.5 で使用されるバージョンと互換性を維持する必要があるため、必要です。

2.2.5. ホスト名の設定

以前のバージョンでは、許可されるホスト名を指定するためにフィルターを使用することが推奨されました。固定ホスト名を設定して、有効なホスト名を簡単に使用できるようになり、内部アプリケーションで代替 URL（内部 IP アドレスなど）を使用して Red Hat Single Sign-On を呼び出せるようになりました。実稼働環境ではこの方法に切り替えることが推奨されます。

2.2.6. JavaScipt Adapter Promise

JavaScript アダプターでネイティブの JavaScript Promise を使用できるようにするには、init オプションで、promiseType を native に設定する必要があります。

以前のリリースでは、ネイティブの提案が利用可能な場合は、レガシーの Keycloak 提案とネイティブの提案の両方を提供していました。これにより、エラーハンドラーがネイティブエラーイベントの前に常に設定されていなかったため、問題が生じていました。その結果、Uncaught (in promise) エラーが発生していました。

2.2.7. Microsoft Identity Provider が Microsoft Graph API を使用するように更新

Red Hat Single Sign-On での Microsoft Identity Provider 実装は、認証およびユーザープロファイルの取得に Live SDK エンドポイントに依存します。2018 年 11 月以降、Microsoft は新しい Microsoft GraphAPI を優先して、ライブ SDK API のサポートを削除しています。Red Hat Single Sign-On ID プロバイダーが新しいエンドポイントを使用するように更新されました。そのため、この統合が使用されている場合は、最新の Red Hat Single Sign-On バージョンにアップグレードしてください。

アプリケーションの ID 形式の変更により、「Live SDK applications」で登録されたレガシークライアントアプリケーションは Microsoft Graph エンドポイントでは動作しません。アプリケーション ID がディレクトリーに見つからないことを示すエラーが出された場合、Microsoft Application Registration Portalでクライアントアプリケーションを再度登録して新しいアプリケーション ID を取得する必要があります。


11

https://account.live.com/developers/applications/create

2.2.8. Google ID プロバイダーが Google Sign-in 認証システムを使用するように更新されました。

Red Hat Single Sign-On の Google Identity Provider 実装は、承認およびユーザープロファイルの取得に Google+ API エンドポイントエンドポイントに依存します。2019 年 3 月以降、Google は新しいGoogle サインイン認証システムを優先し、Google+ API のサポートは修了しています。Red Hat SingleSign-On ID プロバイダーが新しいエンドポイントを使用するように更新されました。そのため、この統合が使用されている場合は、最新の Red Hat Single Sign-On バージョンにアップグレードしてください。

アプリケーション ID がディレクトリーに見つからないことを示すエラーが出された場合、Google APIConsole ポータルでクライアントアプリケーションを再度登録して新しいアプリケーション ID およびシークレットを取得する必要があります。

Google+ ユーザー情報エンドポイントによって提供され、Google Sign-in API によって異なる名前の下に提供される非標準要求のカスタムマッパーを調整する必要がある場合があります。利用可能なクレームに関する最新情報は、Google のドキュメントを参照してください。

2.2.9. LinkedInž Broker が LinkedIn API のバージョン 2 へ更新されました。

これに基づいて、すべての開発者は API および OAuth 2.0 のバージョン 2.0 に移行する必要があります。このため、LinkedInž Broker を更新しました。

LinkedIn API のバージョン 2 を使用してユーザーのプロファイルを取得すると、このブローカーを使用する既存のデプロイメントでエラーが発生する可能性があります。このエラーは、プロファイル API へのアクセスが承認されない、または認証プロセス中に特定の OAuth2 スコープを要求するために使用される可能性のあるブローカーの設定に使用されるクライアントアプリケーションに付与されるパーミッションがないことに関連する可能性があります。

新たに作成された LinkedIn クライアントアプリケーションであっても、クライアントは r_liteprofile おおよびよび r_ emailaddress OAuth2 スコープを要求できることを確認するスコープを要求できることを確認する必要があります。また、クライアントアプリケーションが https://api.linkedin.com/v2/me エンドポイントから現在のメンバーのプロファイルをフェッチできることを確認する必要がありあります。

メンバーの情報へのアクセスと現在のメンバーのプロファイル API によって返される要求の制限により、LinkedIn の制限により、メンバーのメールアドレスをデフォルトユーザー名として使用するようになりました。これは、認証中に承認要求を送信する際に、常に r_emailaddress が設定されていることを示しています。

2.3. RH-SSO 7.2


2.3.1. 新しいパスワードハッシュアルゴリズム

新しいパスワードハッシュアルゴリズム（pbkdf2-sha256 および pbkdf2-sha512）を追加しました。新しいレルムは、27500 ハッシュの反復で pbkdf2-sha256 ハッシュアルゴリズムを使用します。pbkdf2-sha256 は pbkdf2 よりも若干高速であるため、反復は 20000 から 27500 に増えました。

パスワードポリシーにハッシュアルゴリズム（指定なし）および反復(20000)のデフォルト値が含まれる場合、既存のレルムがアップグレードされます。ハッシュの反復を変更した場合は、より安全なハッシュアルゴリズムを使用する場合は、pbkdf2-sha256 に手動で変更する必要があります。

2.3.2. ID Token には scope=openid が必要です

RH-SSO 7.0 では、認証要求に scope=openid クエリーパラメーターが存在するかどうかに関わらず ID


12

https://console.developers.google.com/apis/credentials

https://api.linkedin.com/v2/me

RH-SSO 7.0 では、認証要求に scope=openid クエリーパラメーターが存在するかどうかに関わらず IDトークンが返されました。これは OpenID Connect の仕様に準拠していません。

RH-SSO 7.1 では、このクエリーパラメーターをアダプターに追加しましたが、移行を調整するために以前の動作は残されていました。

RH-SSO 7.2 では、この動作が変更され、要求を OpenID Connect 要求としてマークするために scope=openid クエリーパラメーターが必要になりました。このクエリーパラメーターを省略すると、ID トークンが生成されません。

2.3.3. Microsoft SQL Server には追加の依存関係が必要

Microsoft JDBC Driver 6.0 では、JDBC ドライバーモジュールに追加の依存関係を追加する必要があります。Microsoft SQL Server の使用時に NoClassDefFoundError エラーが発生した場合は、以下の依存関係を JDBC ドライバーの module.xml ファイルに追加します。

2.3.4. OpenID Connect の認証レスポンスに session_state パラメーターを追加

OpenID Connect Session Management 仕様では、session_state パラメーターが OpenID ConnectAuthentication Response に存在する必要があります。

RH-SSO 7.1 ではこのパラメーターがありませんが、Red Hat Single Sign-On ではこの仕様で必要なように、このパラメーターをデフォルトで追加しています。

ただし、一部の OpenID Connect / OAuth2 アダプターおよび特に古い Red Hat Single Sign-On アダプター（RH-SSO 7.1 以前など）には、この新しいパラメーターで問題が発生する場合があります。

たとえば、クライアントアプリケーションへの認証に成功した後に、パラメーターは常にブラウザーURL に表示されます。RH-SSO 7.1、もしくはレガシー OAuth2 または OpenID Connect アダプターを使用する場合は、認証応答への session_state パラメーターの追加を無効にすると役に立つ場合があります。これは、に記載の OpenID Connect の互換性モードに関するセクションで、の互換性モードに関するセクションで、Red Hat Single Sign-On 管理コンソールの特定のクライアントに対して実行管理コンソールの特定のクライアントに対して実行でき「古いアダプターとの互換性」ます。認証応答から除外セッションの状態認証応答から除外セッションの状態スイッチがあり、session_state パラメーターを認証応答に追加しないようにオンにすることができます。

2.3.5. Microsoft Identity Provider が Microsoft Graph API を使用するように更新

Red Hat Single Sign-On のバージョン 7.2.4 の Microsoft Identity Provider 実装は、認証およびユーザープロファイルの取得に Live SDK エンドポイントに依存します。2018 年 11 月以降、Microsoft は新しいMicrosoft Graph API を優先して、ライブ SDK API のサポートを削除しています。Red Hat Single Sign-On アイデンティティープロバイダーは、新しいエンドポイントを使用するように更新されました。このインテグレーションが使用されている場合は、必ず Red Hat Single Sign-On バージョン 7.2.5 にアップグレードしてください。

アプリケーションの ID 形式の変更により、「Live SDK applications」で登録されたレガシークライアントアプリケーションは Microsoft Graph エンドポイントでは動作しません。アプリケーション ID がディレクトリーに見つからないことを示すエラーが出された場合、Microsoft Application Registration Portalでクライアントアプリケーションを再度登録して新しいアプリケーション ID を取得する必要があります。

2.3.6. Google ID プロバイダーが Google Sign-in 認証システムを使用するように更新されました。

<module name="javax.xml.bind.api"/>


13

https://account.live.com/developers/applications/create

Red Hat Single Sign-On のバージョン 7.2.5 の Google Identity Provider 実装は、承認およびユーザープロファイルの取得に Google+ API エンドポイントエンドポイントに依存します。2019 年 3 月以降、Google は新しい Google サインイン認証システムを優先し、Google+ API のサポートは修了しています。Red Hat Single Sign-On アイデンティティープロバイダーは、新しいエンドポイントを使用するように更新されました。このインテグレーションが使用されている場合は、必ず Red Hat Single Sign-Onバージョン 7.2.6 以降にアップグレードするようにしてください。

アプリケーション ID がディレクトリーに見つからないことを示すエラーが出された場合、Google APIConsole ポータルでクライアントアプリケーションを再度登録して新しいアプリケーション ID およびシークレットを取得する必要があります。

Google+ ユーザー情報エンドポイントによって提供され、Google Sign-in API によって異なる名前の下に提供される非標準要求のカスタムマッパーを調整する必要がある場合があります。利用可能なクレームに関する最新情報は、Google のドキュメントを参照してください。

2.3.7. LinkedInž Broker が LinkedIn API のバージョン 2 へ更新されました。

これに基づいて、すべての開発者は API および OAuth 2.0 のバージョン 2.0 に移行する必要があります。そのため、LinkedInž Broker が更新され、このインテグレーションが使用されている場合は、RedHat Single Sign-On バージョン 7.2.6 以降にアップグレードするようにしてください。

LinkedIn API のバージョン 2 を使用してユーザーのプロファイルを取得すると、このブローカーを使用する既存のデプロイメントでエラーが発生する可能性があります。このエラーは、プロファイル API へのアクセスが承認されない、または認証プロセス中に特定の OAuth2 スコープを要求するために使用される可能性のあるブローカーの設定に使用されるクライアントアプリケーションに付与されるパーミッションがないことに関連する可能性があります。

新たに作成された LinkedIn クライアントアプリケーションであっても、クライアントは r_liteprofile おおよびよび r_ emailaddress OAuth2 スコープを要求できることを確認するスコープを要求できることを確認する必要があります。また、クライアントアプリケーションが https://api.linkedin.com/v2/me エンドポイントから現在のメンバーのプロファイルをフェッチできることを確認する必要がありあります。

メンバーの情報へのアクセスと現在のメンバーのプロファイル API によって返される要求の制限により、LinkedIn の制限により、メンバーのメールアドレスをデフォルトユーザー名として使用するようになりました。これは、認証中に承認要求を送信する際に、常に r_emailaddress が設定されていることを示しています。

2.4. RH-SSO 7.1


2.4.1. レルムキー

RH-SSO 7.0 では、レルムに関連付けることができるキーのセットは 1 つだけです。そのため、キーを変更すると現在のクッキーとトークンがすべて無効になり、すべてのユーザーを再認証する必要がありました。RH-SSO 7.1 では、1 つのレルムに対して複数の鍵のサポートが追加されました。キーの 1 つが署名の作成に使用されるアクティブなセットですが、署名の検証に使用される鍵が複数存在する可能性があります。つまり、古いクッキーとトークンを検証し、新しい署名で更新でき、キーが変更されるとユーザーが認証されたままになります。また、『Administration Guide』の「 Realm Keys 」を参照してください。

シームレスな鍵ローテーションを許可するには、クライアントアダプターからハードコーディングされた鍵を削除する必要があります。クライアントアダプターは、レルムキーが指定されていない場合は、サーバーからキーを自動的に取得します。また、クライアントアダプターは、鍵のローテーション時に新しい鍵を自動的に取得します。


14

https://console.developers.google.com/apis/credentials

https://api.linkedin.com/v2/me

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/server_administration_guide/#realm_keys

2.4.2. クライアントのリダイレクト URI 一致

RH-SSO 7.0 では、クライアントに対して有効なリダイレクト URI が一致すると、クエリーパラメーターは無視されます。RH-SSO 7.1 では、クエリーパラメーターは無視されなくなりました。リダイレクト URI にクエリーパラメーターを含める必要がある場合は、クライアントの有効なリダイレクト URIにクエリーパラメーターを指定するか（例： https :// hostname / app / login ? foo = bar）、またはワイルドカード（例： https://hostname/app/login/*）を使用する必要があります。フラグメントは、ValidRedirect URI（つまり https://hostname/app#fragment）で許可されなくなりました。

2.4.3. アイデンティティープロバイダーへの自動リダイレクト

RH-SSO 7.1 の場合、アイデンティティープロバイダーをデフォルトの認証プロバイダーとして設定することはできません。RH-SSO 7.1 のアイデンティティープロバイダーに自動的にリダイレクトするには、アイデンティティープロバイダーの再配置を設定する必要があります。詳細は、『サーバー管理ガイド』の「デフォルトのアイデンティティープロバイダー」を参照してください参照してください。デフォルトの認証プロバイダーオプションが設定されたアイデンティティープロバイダーがある場合、サーバーが RH-SSO 7.1 にアップグレードされると、この値はアイデンティティープロバイダーのリース値として自動的に使用されます。

2.4.4. Management REST API

RH-SSO 7.0 では、maxResults クエリーパラメーターが指定されていない場合に、Admin REST API のページネーションされたエンドポイントはすべて結果を返します。これにより、一時的な負荷が高くなり、多数の結果が返されると（ユーザーなど）タイムアウトが発生する可能性がありました。RH-SSO7.1 では、maxResults の値が指定されていない場合、最大 100 件の結果が返されます。maxResults を -1として指定すると、すべての結果を返すことができます。

2.4.5. サーバー設定

RH-SSO 7.0 では、サーバー設定は keycloak-server.json ファイルと standalone/domain.xml またはdomain.xml ファイルの間で分割されます。RH-SSO 7.1 では、keycloak-server.json ファイルが削除され、すべてのサーバー設定が standalone.xml または domain.xml ファイルを使用して行われます。RH-SSO 7.1 のアップグレード手順により、サーバー設定が keycloak-server.json ファイルからstandalone.xml または domain.xml ファイルに自動的に移行されます。

2.4.6. SAML 評価における鍵暗号化アルゴリズム

RH-SSO 7.1 では、SAML アサーションとドキュメントの鍵が RSA-OAEP 暗号化スキームを使用して暗号化されるようになりました。暗号化したアサーションを使用するには、サービスプロバイダーがこの暗号化スキームに対応していることを確認してください。RSA-OAEP をサポートしないサービスプロバイダーがある場合、RH-SSO はシステムプロパティー "keycloak.saml.key_trans.rsa_v1.5" を true に設定して、レガシー RSA-v1.5 暗号化スキームを使用するように設定できます。これを行う場合は、よりセキュアな RSA-OAEP 暗号化スキームに戻すことができるように、できるだけ早期にサービスプロバイダーをアップグレードする必要があります。


15

https://access.redhat.com/documentation/en-us/red_hat_single_sign-on/7.4/html-single/server_administration_guide/#default_identity_provider

第3章 RED HAT SINGLE SIGN-ON サーバーのアップグレードRed Hat Single Sign-On サーバーのアップグレードまたは移行プロセスは、以前のバージョンのソフトウェアによって異なります。

7.0.0 から 7.1.0 などの新しいマイナーリリースにアップグレードする場合は、「マイナーリリースのアップグレード」に記載の手順に従います。

Keycloak 9.0.x から移行する場合は、「最小アップグレード」の手順に従います。

たとえば 7.1.0 から 7.1.1 などの新しいマイクロリリースにアップグレードする場合は、MicroUpgrades の手順に従います。

3.1. マイナーアップグレード

3.1.1. アップグレードの準備

アップグレードの前に、アップグレード手順の実行に必要な順序を書き留めておきます。また、アップグレードプロセス内で発生する可能性のある問題にも注意してください。通常、Red Hat Single Sign-On サーバーを最初にアップグレードしてからアダプターをアップグレードする必要があります。

1. アップグレードを適用する前に、開かれたトランザクションをすべて処理し、data/tx-object-store/ トランザクションディレクトリーを削除します。

2. 以前のインストール（設定、テーマなど）のバックアップを作成します。

3. データベースのバックアップを作成します。データベースのバックアップ方法の詳細は、使用しているリレーショナルデータベースのドキュメントを参照してください。

4. Red Hat Single Sign-On サーバーをアップグレードします。

インストールの問題が実稼働環境で公開されるのを防ぐために、非実稼働環境でアップグレードをテストすることがベストプラクティスです。

アップグレード後にデータベースと古いサーバーとの互換性がなくなることに注意してください。

実稼働環境でアダプターをアップグレードする前に、アップグレードしたサーバーが機能していることを確認します。

5. アップグレードを元に戻す必要がある場合は、最初に古いインストールを復元してから、バックアップコピーからデータベースを復元します。

6. アダプターをアップグレードします。

3.1.2. Red Hat Single Sign-On サーバーのアップグレード

アダプターをアップグレードする前に、Red Hat Single Sign-On サーバーをアップグレードすることが重要です。

Red Hat Single Sign-On サーバーをアップグレードするには、以下の手順を実行します。

1. アップグレードを適用する前に、開かれたトランザクションをすべて処理し、data/tx-object-store/ トランザクションディレクトリーを削除します。


16

2. 新しいサーバーアーカイブをダウンロードします。

3. ダウンロードしたアーカイブを任意の場所に移動します。

4. アーカイブを展開します。この手順では、最新の Red Hat Single Sign-On リリースのインスタンスがクリーンインストールされます。

5. スタンドアロンインストールの場合は、以前のインストールの RHSSO_HOME/standalone/ディレクトリーを、新規インストールのディレクトリーにコピーします。ドメインインストールの場合は、前のインストールの RHSSO_HOME/domain/ ディレクトリーを新規インストールのディレクトリーにコピーします。

ドメインインストールの場合は、空のディレクトリー RHSSO_HOME/domain/deployments を作成します。

注記： bin ディレクトリーのファイルは、以前のバージョンのファイルで上書きしないでください。変更は手作業で行う必要があります。

6. modules ディレクトリーに追加されたカスタムモジュールをコピーします。

7. 以下の該当するアップグレードスクリプトを実行します。

Red Hat Single Sign-On サーバーの RPM ディストリビューションをアップグレードするには、以下の手順を実行します。

1. アップグレードを適用する前に、開いているトランザクションをすべて処理し、/var/opt/rh/rh-sso7/lib/keycloak/standalone/data/tx-object-store/ トランザクションディレクトリーを削除します。

2. JBOSS EAP および Red Hat Single Sign-On を含む適切なリポジトリーにサブスクライブしていることを確認してください。

subscription-manager repos --enable=jb-eap-7.1-for-rhel-7-server-rpmssubscription-manager repos --enable=rh-sso-7.2-for-rhel-7-server-rpms

注記注記

JBOSS EAP と Red Hat Single Sign-On の両方で古い製品リポジトリーを無効にするには、以下を実行します。

subscription-manager repos --disable=<OLDER_PRODUCT_REPO>

リポジトリーの使用方法を確認するには、以下を行います。

yum repolist

3. RPM のアップグレードプロセスでは、変更された設定ファイルは置き換えられず、代わりに、新しい Red Hat Single Sign-On バージョンのデフォルト設定用に .rpmnew ファイルを作成します。新しいサブシステムなど、新リリースの新機能をアクティベートするには、各 .rpmnew ファイルを手作業で既存の設定ファイルにマージする必要があります。

4. modules ディレクトリーに追加されたカスタムモジュールをコピーします。

第第3章章 RED HAT SINGLE SIGN-ON サーバーのアップグレードサーバーのアップグレード

17

5. 以下で説明されているように、適用可能なアップグレードスクリプトを実行します。

注記注記

Red Hat Single Sign-On RPM サーバーディストリビューションが使用中

RHSSO_HOME=/opt/rh/rh-sso7/root/usr/share/keycloak

以下の移行スクリプトを呼び出す際に使用します。

3.1.2.1. スタンドアロンモードアップグレードスクリプトの実行スタンドアロンモードアップグレードスクリプトの実行

スタンドアロンモードのアップグレードスクリプトを実行するには、以下の手順を実行します。

1. デフォルトの設定ファイルとは異なる設定ファイルを使用している場合は、移行スクリプトを編集して新しいファイル名を指定します。

2. サーバーを停止します。

3. アップグレードスクリプトを実行します。

bin/jboss-cli.sh --file=bin/migrate-standalone.cli

3.1.2.2. スタンドアロン高可用性モードアップグレードスクリプトの実行スタンドアロン高可用性モードアップグレードスクリプトの実行

スタンドアロン高可用性(HA)モードでは、すべてのインスタンスを同時にアップグレードする必要があります。

standalone-HA モードのアップグレードスクリプトを実行するには、以下の手順を実行します。

1. デフォルトの設定ファイルとは異なる設定ファイルを使用している場合は、移行スクリプトを編集して新しいファイル名を指定します。


3. アップグレードスクリプトを実行します。

bin/jboss-cli.sh --file=bin/migrate-standalone-ha.cli

3.1.2.3. ドメインモードアップグレードスクリプトの実行ドメインモードアップグレードスクリプトの実行

ドメインモードの場合は、全インスタンスを同時にアップグレードする必要があります。

ドメインモードのアップグレードスクリプトを実行するには、以下の手順を実行します。

1. プロファイル名を変更した場合は、アップグレードスクリプトを編集して、スクリプトの先頭にある変数を変更する必要があります。

2. ドメインスクリプトを編集して、keycloak-server.json ファイルの場所を追加します。


4. ドメインコントローラーでのみアップグレードスクリプトを実行します。

bin/jboss-cli.sh --file=bin/migrate-domain.cli


18

3.1.2.4. ドメインクラスターモードアップグレードスクリプトの実行ドメインクラスターモードアップグレードスクリプトの実行

ドメインクラスターモードの場合は、すべてのインスタンスを同時にアップグレードする必要があります。

ドメインクラスターモードのアップグレードスクリプトを実行するには、以下の手順を実行します。

1. プロファイル名を変更した場合は、アップグレードスクリプトを編集して、スクリプトの先頭にある変数を変更する必要があります。

2. domain-clustered スクリプトを編集して、keycloak-server.json ファイルの場所を追加します。


4. ドメインコントローラーでのみアップグレードスクリプトを実行します。

bin/jboss-cli.sh --file=bin/migrate-domain-clustered.cli

3.1.3. データベースの移行

Red Hat Single Sign-On は、データベーススキーマを自動的に移行するか、手動で行うこともできます。デフォルトでは、新規インストールの初回起動時に、データベースは自動的に移行されます。

3.1.3.1. データベースの自動移行データベースの自動移行

データベーススキーマの自動アップグレードを有効にするには、デフォルトの connectionJpa プロバイダーの migrationStrategy プロパティーの値を「update」に設定します。

または、この CLI コマンドを実行します。

この設定でサーバーを起動すると、データベーススキーマが新しいバージョンで変更された場合には、データベースが自動的に移行されます。

3.1.3.2. 手動による関係データベース移行手動による関係データベース移行

データベーススキーマの手動アップグレードを有効にするには、デフォルトの connectionJpa プロバイダーの migrationStrategy プロパティーの値を「manual」に設定します。

<spi name="connectionsJpa"> <provider name="default" enabled="true"> <properties> ... <property name="migrationStrategy" value="update"/> </properties> </provider></spi>

/subsystem=keycloak-server/spi=connectionsJpa/provider=default/:map-put(name=properties,key=migrationStrategy,value=update)

<spi name="connectionsJpa"> <provider name="default" enabled="true"> <properties>


19

または、この CLI コマンドを実行します。

この設定でサーバーを起動すると、データベースを移行する必要があるかどうかを確認します。必要な変更は、データベースに対して確認し、手動で実行できる SQL ファイルに書き込まれます。このファイルをデータベースに適用する方法は、使用しているリレーショナルデータベースのドキュメントを参照してください。変更がファイルに書き込まれると、サーバーは終了します。

3.1.4. 写真の移行

カスタムテーマを作成したら、それらを新しいサーバーに移行する必要があります。カスタマイズした内容に応じて、カスタムテーマに変更を加える必要がある場合があります。

古いサーバー「themes」ディレクトリーから新しいサーバー「themes」ディレクトリーに、カスタムテーマをコピーする必要があります。以下の変更を確認してから、変更をカスタムテーマに適用する必要があるかどうかを検討してください。

概要：

以下に示す変更したテンプレートのいずれかをカスタマイズする場合は、ベーステーマからテンプレートを比較して、適用が必要な変更の有無を確認する必要があります。

スタイルのいずれかをカスタマイズし、Red Hat Single Sign-On テーマを拡張する場合は、スタイルの変更を確認する必要があります。ベーステーマを拡張する場合は、この手順を省略できます。

メッセージをカスタマイズする場合は、キーまたは値を変更するか、別のメッセージを追加する必要がある場合があります。

各ステップは、変更の一覧に従って詳細を説明します。

3.1.4.1. テーマの変更テーマの変更 RH-SSO 7.3

Templates

Account: account.ftl

Account: applications.ftl

Account: resource-detail.ftl (new)

Account: resources.ftl (new)

Account: template.ftl

Account: totp.ftl

Email-html: email-test.ftl

... <property name="migrationStrategy" value="manual"/> </properties> </provider></spi>

/subsystem=keycloak-server/spi=connectionsJpa/provider=default/:map-put(name=properties,key=migrationStrategy,value=manual)


20

Email-html: email-verification-with-code.ftl (new)

Email-html: email-verification.ftl

Email-html: event-login_error.ftl

Email-html: event-removed_totp.ftl

Email-html: event-update_password.ftl

Email-html: event-update_totp.ftl

Email-html: executeActions.ftl

Email-html: identity-provider-link.ftl

Email-html: password-reset.ftl

Email-text: email-verification-with-code.ftl (new)

Email-text: email-verification.ftl

Email-text: executeActions.ftl

Email-text: identity-provider-link.ftl

Email-text: password-reset.ftl

Login: cli_splash.ftl (new)

Login: code.ftl

Login: error.ftl

Login: info.ftl

Login: login-config-totp-text.ftl (new)

Login: login-config-totp.ftl

Login: login-idp-link-confirm.ftl

Login: login-idp-link-email.ftl

Login: login-oauth-grant.ftl

Login: login-page-expired.ftl

Login: login-reset-password.ftl

Login: login-totp.ftl

Login: login-update-password.ftl

Login: login-update-profile.ftl

Login: login-verify-email-code-text.ftl (new)


21

Login: login-verify-email.ftl

Login: login-x509-info.ftl

Login: login.ftl

Login: register.ftl

Login: template.ftl

Login: terms.ftl

Welcome: index.ftl (new)

Messages

Account: messages_en.properties

Admin: admin-messages_en.properties

Email: messages_en.properties

Login: messages_en.properties

Styles

Login: login-rhsso.css (new)

Welcome: welcome-rhsso.css

3.1.4.2. Theme changes RH-SSO 7.2

Templates


Account: applications.ftl

Account: federatedIdentity.ftl

Account: password.ftl

Account: sessions.ftl

Account: template.ftl

Account: totp.ftl

Admin: index.ftl

Email: email-test.ftl (new)

Email: email-verification.ftl

Email: event-login_error.ftl

Email: event-removed_totp.ftl


22

Email: event-update_password.ftl

Email: event-update_totp.ftl

Email: executeActions.ftl

Email: identity-provider-link.ftl

Email: password-reset.ftl

Login: bypass_kerberos.ftl (removed)

Login: error.ftl

Login: info.ftl


Login: login-idp-link-email.ftl

Login: login-oauth-grant.ftl

Login: login-page-expired.ftl (new)


Login: login-totp.ftl

Login: login-update-password.ftl

Login: login-update-profile.ftl

Login: login-verify-email.ftl

Login: login-x509-info.ftl (new)

Login: login.ftl (new)

Login: register.ftl (new)

Login: template.ftl (new)

Login: terms.ftl (new)

Messages

Account: messages_en.properties

Admin: admin-messages_en.properties

Admin: messages_en.properties

Email: messages_en.properties

Login: messages_en.properties

Styles


23

Account: account.css

Login: login.css

3.1.4.3. Theme changes RH-SSO 7.1

Templates


Account: federatedIdentity.ftl

Account: totp.ftl

Login: info.ftl



Login: login.ftl

Messages

Account: editAccountHtmlTtile renamed to editAccountHtmlTitle

Account: role_uma_authorization added

Login: loginTotpStep1 value changed

Login: invalidPasswordGenericMessage added

Login: invlidRequesterMessage renamed to invalidRequesterMessage

Login: clientDisabledMessage added

Styles

Account: account.css

Login: login.css

3.1.4.4. テンプレートの移行テンプレートの移行

テンプレートのいずれかをカスタマイズする場合には、テンプレートに加えた変更を慎重に確認して、カスタマイズされたテンプレートにこれらの変更を適用する必要があるかどうかを判断します。カスタマイズしたテンプレートに同じ変更を適用する必要があります。一覧表示されているテンプレートもカスタマイズしていない場合には、このセクションを省略できます。

ベストプラクティスは、diff ツールを使用してテンプレートを比較し、カスタマイズしたテンプレートへの変更を確認することです。マイナーな変更を加えるだけで、更新されたテンプレートをカスタマイズしたテンプレートと比較すると便利です。ただし、多くの変更を加えると、新しいテンプレートをカスタマイズした古いテンプレートと比較することがより簡単になる可能性があります。これは、変更が必要な変更を示しています。

以下のスクリーンショットは、ログインテーマとカスタムテーマのサンプルから info.ftl テンプレートを比較します。


24

ログインテーマテンプレートの更新バージョンとカスタムログインテーマのテンプレートの例ログインテーマテンプレートの更新バージョンとカスタムログインテーマのテンプレートの例の比較の比較

この比較から、最初の変更(Hello world!!)がカスタマイズされており、2 つ目の変更（pageRedirectUriの場合）はベーステーマの変更です。2 つ目の変更をカスタムテンプレートにコピーすると、カスタマイズされたテンプレートが正常に更新されました。

別の方法としては、以下のスクリーンショットは、古いインストールの info.ftl テンプレートと、新規インストールの更新された info.ftl テンプレートを比較します。

カスタムログインテーマテンプレートの例と、ログインテーマのテンプレートの更新バージョカスタムログインテーマテンプレートの例と、ログインテーマのテンプレートの更新バージョンの比較ンの比較

この比較により、ベーステンプレートで変更した内容を簡単に特定できます。その後、変更したテンプレートに同じ変更を加える必要があります。このアプローチは最初のアプローチほどシンプルではないため、最初のアプローチを実行できない場合に限り使用してください。

3.1.4.5. メッセージの移行メッセージの移行

別の言語のサポートを追加している場合は、上記の変更をすべて適用する必要があります。別の言語のサポートを追加していない場合、変更が必要な場合もあります。自分専用のテーマで影響を受けるメッセージを変更した場合のみです。

値を追加したら、ベーステーマのメッセージの値を確認して、そのメッセージをカスタマイズする必要があるかどうかを判断します。

キーの名前を変更し、カスタムテーマのキーの名前を変更します。

変更した値については、ベーステーマの値を確認して、カスタムテーマに変更を加える必要があるかどうかを判断します。

3.1.4.6. シェイプの移行シェイプの移行

keycloak または rh-sso テーマからスタイルを継承する場合は、組み込みテーマの変更を反映するよう


25

keycloak または rh-sso テーマからスタイルを継承する場合は、組み込みテーマの変更を反映するようにカスタムスタイルを更新する必要がある場合があります。

ベストプラクティスは、diff ツールを使用して、古いサーバーインストールと新しいサーバーインストール間のスタイルシートへの変更を比較することです。

たとえば、diff コマンドを使用します。

変更を確認し、カスタムスタイリングに影響するかどうかを判断します。

3.2. マイクロアップグレード

3.2.1. ZIP/インストーラーインストールのパッチ適用

RH-SSO の ZIP インストールのパッチは、Red Hat カスタマーポータルからダウンロードできます。

管理対象ドメイン環境の複数の RH-SSO ホストの場合、個々のホストは RH-SSO ドメインコントローラーからパッチできます。

パッチを適用する他に、パッチの適用をロールバックすることもできます。

3.2.1.1. ZIP インストールパッチに関する重要事項インストールパッチに関する重要事項

モジュールを更新するパッチを適用すると、起動時に使用される新しいパッチが適用されたJAR は RHSSO_HOME/modules/system/layers/base/.overlays/PATCH_ID/MODULE に保存されます。パッチが適用されていない元のファイルは RHSSO_HOME/modules/system/layers/base/MODULE に残りますが、これらの JAR は起動時に使用されません使用されません。

RH-SSO 7 の累計パッチリリースのサイズを大幅に小さくするため、累計パッチを部分的にロールバックすることはできません。適用済みのパッチはパッチ全体のみをロールバックできます。たとえば、CP03 を RH-SSO 7.0.0 に適用する場合、CP01 または CP02 にロールバックすることはできません。各累計パッチリリースにロールバックできるようにするには、各累計パッチをリリース順に個別に適用する必要があります。

3.2.1.2. パッチの適用パッチの適用

注記注記

RPM メソッドを使用してインストールされた RH-SSO サーバーは、上記の手順に従って更新することはできません。代わりに、「パッチを適用する RPM の手順」を参照してください。

管理 CLI または管理コンソールのいずれかを使用して、ダウンロードしたパッチを RH-SSO サーバーに適用できます。

管理管理 CLI を使用したを使用した RH-SSO へのパッチ適用へのパッチ適用

1. Red Hat カスタマーポータルの https://access.redhat.com/downloads/ からパッチファイルを

$ diff RHSSO_HOME_OLD/themes/keycloak/login/resources/css/login.css \RHSSO_HOME_NEW/themes/keycloak/login/resources/css/login.css


26

https://access.redhat.com/

1. Red Hat カスタマーポータルの https://access.redhat.com/downloads/ からパッチファイルをダウンロードします。

2. パッチファイルへの適切なパスを指定して、以下のコマンドを使用してパッチを適用します。

patch apply /path/to/downloaded-patch.zip

注記注記

管理対象ドメインの別の RH-SSO ホストにパッチを適用するには、--host= 引数を使用して RH-SSO ホスト名を指定できます。以下に例を示します。

patch apply /path/to/downloaded-patch.zip --host=my-host

パッチの適用時に競合が存在する場合は、パッチツールによって警告が表示されます。競合が存在する場合は、利用可能な引数に patch --help を入力し、競合の解決方法を指定する引数を使用してコマンドを再実行します。

3. RH-SSO サーバーを再起動して、パッチを適用します。

shutdown --restart=true

管理コンソールを使用した管理コンソールを使用した RH-SSO へのパッチ適用へのパッチ適用

1. Red Hat カスタマーポータルの https://access.redhat.com/downloads/ からパッチファイルをダウンロードします。

2. 管理コンソールを開き、Patch Management ビューに移動します。

a. スタンドアロンサーバーの場合は、Patching タブをクリックします。

スタンドアロンサーバーのパッチ管理画面スタンドアロンサーバーのパッチ管理画面


27

https://access.redhat.com/downloads/

https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html-single/configuration_guide/#management_cli_overview

https://access.redhat.com/downloads/

https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.0/html-single/configuration_guide/#management_console_overview

b. 管理対象ドメインのサーバーの場合は Patching タブをクリックし、表からパッチを適用するホストを選択して View をクリックします。

管理対象ドメインのパッチ管理画面管理対象ドメインのパッチ管理画面

3. Apply a New Patch をクリックします。

a. 管理対象ドメインホストにパッチを当てる場合は、次の画面で、ホストのサーバーをシャットダウンするかどうかを選択し、Next をクリックします。


28

4. Browse ボタンをクリックして適用するダウンロードしたパッチを選択し、Next をクリックします。

パッチ画面の適用パッチ画面の適用

..パッチの適用時に競合が存在する場合は、警告が表示されます。View error details をクリックして、競合の詳細を確認します。競合が存在する場合は、操作をキャンセルするか、Override all conflicts を選択し、Next をクリックします。競合をオーバーライドすると、ユーザーの変更が上書きされます。

5. パッチの適用が正常に完了したら、今すぐ RH-SSO を再起動するかどうかを選択し、パッチを適用するかどうかを選択し、Finish をクリックします。

3.2.1.3. パッチのロールバックパッチのロールバック

管理 CLI または管理コンソールを使用して、以前適用した RH-SSO パッチをロールバックできます。

重要重要

パッチ管理システムを使用したパッチのロールバックは、一般的なアンインストール機能として使用するものではありません。これは、望ましくない影響のあるパッチの適用直後に使用することを目的としています。


以前に適用されたパッチ。


29

警告警告

いずれかの手順を行場合は、Reset Configuration オプションの値を指定する際に注意して行ってください。

TRUE に設定されていると、パッチのロールバックプロセスによって RH-SSOサーバー設定ファイルもパッチ前の状態にロールバックされます。パッチの適用後に RH-SSO サーバー設定ファイルに追加された変更はすべて失われます。

FALSE に設定すると、サーバー設定ファイルはロールバックされません。このような場合は、namespace などの設定がパッチによって変更されている可能性があるため、手動で修正する必要がある可能性があるため、ロールバック後にサーバーを起動できない可能性があります。

管理管理 CLI を使用したパッチのロールバックを使用したパッチのロールバック

1. 管理 CLI から patch history コマンドを使用して、ロールバックするパッチの ID を見つけます。

注記注記

管理対象ドメインを使用している場合は、この手順のコマンドに --host=HOSTNAME 引数を追加して、RH-SSO ホストを指定する必要があります。

2. 前の手順で適切なパッチ ID でパッチをロールバックします。

patch rollback --patch-id=PATCH_ID --reset-configuration=TRUE

パッチのロールバック時に競合が存在する場合は、パッチツールによって警告が表示されます。競合が存在する場合は、利用可能な引数に patch --help を入力し、競合の解決方法を指定する引数を使用してコマンドを再実行します。

3. RH-SSO サーバーを再起動して、パッチのロールバックを有効にします。

shutdown --restart=true

管理コンソールを使用したパッチのロールバック管理コンソールを使用したパッチのロールバック

1. 管理コンソールを開き、Patch Management ビューに移動します。

a. スタンドアロンサーバーの場合は、Patching タブをクリックします。

b. 管理対象ドメインのサーバーの場合は Patching タブをクリックし、表からパッチを適用するホストを選択して View をクリックします。

2. 表に一覧表示されているものからロールバックするパッチを選択し、Rollback をクリックします。

最新のパッチ履歴画面最新のパッチ履歴画面


30

..管理対象ドメインホストでパッチをロールバックする場合は、次の画面で、ホストのサーバーをシャットダウンするかどうかを選択し、Next をクリックします。

3. ロールバックプロセスのオプションを選択して、Next をクリックします。

パッチのロールバックオプションパッチのロールバックオプション


31

4. ロールバックするオプションとパッチを確認してから Next をクリックします。

a. パッチのロールバック時に競合が発生し、Override all オプションが選択されなかった場合は、警告が表示されます。View error details をクリックして、競合の詳細を確認します。競合が存在する場合は、操作をキャンセルするか、Choose Options をクリックし、Override all チェックボックスを選択して操作を再試行します。競合をオーバーライドすると、ユーザーの変更がオーバーライドされます。

5. パッチが正常にロールバックされたら、変更を有効にするために RH-SSO サーバーを再起動するかどうかを選択し、Finish をクリックします。

3.2.1.4. パッチ履歴の消去パッチ履歴の消去

パッチが RH-SSO サーバーに適用されると、ロールバック操作で使用するためにパッチの内容と履歴が保存されます。複数の累計パッチが適用されると、パッチ履歴で大量のディスク領域が使用される可能性があります。

以下の管理 CLI コマンドを使用すると、現在使用されていない古いパッチをすべて削除することができます。このコマンドを使用する場合は、最新の累積パッチのみが GA リリースとともに保持されます。これは、以前に複数の累積パッチが適用された場合に限り、空き領域を解放するのに役立ちます。

/core-service=patching:ageout-history

重要重要


32

重要重要

パッチ履歴を消去すると、以前に適用されたパッチをロールバックできなくなります。

3.2.2. RPM インストールのパッチ適用


ベースオペレーティングシステムが最新の状態で、標準の Red Hat Enterprise Linux リポジトリーから更新をサブスクライブおよび有効化していることを確認します。

更新に関連する RH-SSO リポジトリーにサブスクライブしていることを確認してください。

設定ファイル、デプロイメント、およびユーザーデータをすべてバックアップします。

重要重要

管理対象ドメインの場合は、最初に RH-SSO ドメインコントローラーを更新する必要があります。

サブスクライブしているリポジトリーから RPM で RH-SSO パッチをインストールするには、以下のコマンドを実行して Red Hat Enterprise Linux システムを更新します。

3.2.3. ローカル Maven インストールのパッチ適用

Red Hat カスタマーポータルからダウンロードした ZIP ファイルを使用して RH-SSO Client AdaptersMaven リポジトリーをインストールしている場合は、パッチを当てる必要がある場合があります。

RH-SSO Client Adapters Maven リポジトリーはオンラインで利用でき、ダウンロードした ZIP ファイルとして使用することができます。公開ホストされているオンライン Maven リポジトリーを使用する場合は、更新は自動的に適用されるため、更新は必要ありません。しかし、ZIP ファイルを使用してMaven リポジトリーをローカルにインストールしている場合は、リポジトリーに更新を適用する必要があります。

RH-SSO の累積パッチがリリースされると、RH-SSO クライアントアダプターの Maven リポジトリーに対応するパッチが提供されます。このパッチは、既存のローカルリポジトリーで展開される増分 ZIPファイル形式で利用できます。既存のファイルは上書きまたは削除しないため、ロールバックの要件はありません。

以下の手順に従って、ローカルインストールされた RH-SSO クライアントアダプター Maven リポジトリーに更新を適用します。

3.2.3.1. 前提条件前提条件

Red Hat カスタマーポータルへの有効なアクセスおよびサブスクリプション。

以前ローカルにダウンロードおよびインストールされた RH-SSO クライアントアダプターMaven リポジトリー。

3.2.3.2. ローカルにインストールされたローカルにインストールされた RH-SSO クライアントアダプタークライアントアダプター Maven リポジトリポジトリーの更新リーの更新

yum update


33


1. ブラウザーを開き、Red Hat カスタマーポータルにログインします。

2. ページの上部にあるメニューから Downloads を選択します。

3. 一覧から Red Hat Single Sign-On を選択します。

4. Version ドロップダウンメニューから Red Hat Single Sign-On の正しいバージョンを選択し、Patches タブを選択します。

5. リストから Red Hat Single Sign-On 7.x.y Client Adapters Incremental Maven Repositoryを見つけます。ここで、x.y は更新する累計パッチ番号と一致します。Download を選択します。

6. RH-SSO Client Adapters Maven リポジトリーへのパスを見つけます。これは、以下のコマンドで RH-SSO_MAVEN_REPOSITORY_PATH と呼ばれます。ダウンロードした Maven パッチファイルを直接このディレクトリーに展開します。以下に例を示します。

a. Red Hat Enterprise Linux の場合は、ターミナルを開き、以下のコマンドを実行します。累計パッチ番号と Maven リポジトリーパスの値を置き換えます。

$ unzip -o rh-sso-7.x.y-incremental-maven-repository.zip -d RH-SSO_MAVEN_REPOSITORY_PATH

b. Microsoft Windows の場合は、Windows 抽出ユーティリティーを使用して ZIP ファイルを RH-SSO_MAVEN_REPOSITORY_PATH ディレクトリーのルートに展開します。


34


第4章 RED HAT SINGLE SIGN-ON アダプターのアップグレード最初に Red Hat Single Sign-On サーバーをアップグレードしてからアダプターをアップグレードすることが重要です。アダプターの以前のバージョンは、新しいバージョンの Red Hat Single Sign-On サーバーと連携する可能性がありますが、Red Hat Single Sign-On サーバーの以前のバージョンは、それ以降のバージョンのアダプターでは機能しない可能性があります。

4.1. 古いアダプターとの互換性

上記のように、アダプターの古いリリースバージョンと連携する Red Hat Single Sign-On サーバーの新リリースバージョンのサポートを試みます。ただし、Red Hat Single Sign-On サーバー側に修正を含める必要がある場合があります。これにより、アダプターの古いバージョンとの互換性が失われる可能性があります。たとえば、OpenID Connect 仕様の新しい側面を実装する場合に、古いクライアントアダプターのバージョンを認識しませんでした。

この場合、互換性モードを追加しました。OpenId Connect クライアントでは、クライアント詳細が含まれるページに、Red Hat Single Sign-On 管理コンソールの OpenID Connect Compatibility Modesという名前のセクションがあります。ここでは、Red Hat Single Sign-On サーバーの新しい側面を無効にして、古いクライアントアダプターとの互換性を維持することができます。詳細は、個々のスイッチのツールヒントを参照してください。

4.2. EAP アダプターのアップグレード

ダウンロードしたアーカイブを使用してアダプターを最初にインストールして JBoss EAP アダプターをアップグレードする場合は、以下の手順を行います。

1. 新しいアダプターアーカイブをダウンロードします。

2. EAP_HOME/modules/system/add-ons/keycloak/ ディレクトリーを削除して、以前のアダプターモジュールを削除します。

3. ダウンロードしたアーカイブを EAP_HOME に展開します。

RPM を使用してアダプターを最初にインストールした場合は、アダプターをアップグレードするには、マイナーアップグレードまたはマイクロアップグレードを実行しているかどうかによって異なります。

1. マイナーアップグレードの場合は、Yum を使用して、現在インストールされているアダプターをアンインストールしてから、Yum を使用して新しいバージョンのアダプターをインストールします。

2. マイクロアップグレードの場合は、Yum を使用してアダプターをアップグレードします。これは、マイクロアップグレードの唯一の手順です。

4.3. JAVASCRIPT アダプターのアップグレード

Web アプリケーションにコピーされた JavaScript アダプターをアップグレードするには、以下の手順を実行します。


2. アプリケーションの keycloak.js ファイルを、ダウンロードしたアーカイブの keycloak.js ファイ

yum update

第第4章章 RED HAT SINGLE SIGN-ON アダプターのアップグレードアダプターのアップグレード

35

2. アプリケーションの keycloak.js ファイルを、ダウンロードしたアーカイブの keycloak.js ファイルで上書きします。

4.4. NODE.JS アダプターのアップグレード

Web アプリケーションにコピーされた Node.js アダプターをアップグレードするには、以下の手順を実行します。


2. 既存の Node.js アダプターディレクトリーを削除します。

3. 更新されたファイルをその場所に展開します。

4. アプリケーションの package.json で keycloak-connect の依存関係を変更します。


36

red hat single sign-on 7.4 アップグレードガイド...red hat single sign-on サーバーが...

Documents