Red Hat Single Sign-On 7.2 から Red Hat Single Sign-On 8.0 など、RH-SSO を別のメジャーリリースにアップグレードする場合は、メジャーアップグレードまたは移行が必要になります。メジャーリリース間で API の重大な変更があり、アプリケーションまたはサーバーの拡張機能の一部を書き換えが必要になる場合があります。

Red Hat Single Sign-On は、定期的にポイントリリースを提供します。これは、バグ修正、セキュリティー修正、および新機能が含まれるマイナー更新です。Red Hat Single Sign-On ポイントリリースを別のリリースにアップグレードする場合 (たとえば、Red Hat Single Sign-On 7.3 から Red Hat Single Sign-On 7.5 へ) は、プライベートではないまたはサポート対象外のもの、またはテクノロジープレビュー API が使用されてる場合は、アプリケーションやカスタムサーバーの拡張機能にコードを変更する必要はありません。

Red Hat Single Sign-On 7.5 では、バグ修正やセキュリティー修正が含まれるマイクロリリースを定期的に提供します。マイクロリリースは、7.5.0 から 7.5.1 など、最後の数字のマイナーリリースバージョンを増分します。これらのリリースには移行は必要なく、サーバー設定ファイルには影響を及ぼしません。ZIP インストールのパッチ管理システムは、パッチとサーバー設定をロールバックすることもできます。

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

7.5.3 以降では、RH-SSO 7.5 と完全な下位互換性がある Red Hat Single Sign-On Operator 7.6 を使用できます。Operator は 7.5.z ではリリースされなくなりました。詳細は サーバーのインストールおよび設定ガイド の関連する章を参照してください。

Red Hat Single Sign-On は、発信 HTTP リクエストに対して標準の HTTP_PROXY、HTTPS_PROXY、および NO_PROXY 環境変数を認識するようになりました。この変更が理由で、たとえば、HTTP_PROXY 変数が定義されているにも拘らず、SPI 設定で明示的なプロキシーマッピングが指定されていない場合に、プロキシーサーバーが予期せず使用される可能性があります。Red Hat Single Sign-On がこれらの環境変数を使用しないようにするには、すべてのリクエストに対して no proxy ルートを .*;NO_PROXY として明示的に作成します。

詳細は、サーバーのインストールおよび設定ガイド の関連する章を参照してください。

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

<extension module="org.wildfly.extension.microprofile.config-smallrye"/>
<extension module="org.wildfly.extension.microprofile.health-smallrye"/>
<extension module="org.wildfly.extension.microprofile.metrics-smallrye"/>

<subsystem xmlns="urn:wildfly:microprofile-config-smallrye:1.0"/>
<subsystem xmlns="urn:wildfly:microprofile-health-smallrye:2.0" security-enabled="false" empty-liveness-checks-status="${env.MP_HEALTH_EMPTY_LIVENESS_CHECKS_STATUS:UP}" empty-readiness-checks-status="${env.MP_HEALTH_EMPTY_READINESS_CHECKS_STATUS:UP}"/>
<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:2.0" security-enabled="false" exposed-subsystems="*" prefix="${wildfly.metrics.prefix:wildfly}"/>

UserModel には、カスタム属性に変換される特定のフィールド (username、email、firstName、および lastName) が含まれます。この変更により、今後のバージョンで Red Hat Single Sign-On により高度なユーザープロファイルを追加する準備が加えられました。

この状況は、username も UserModel.getFirstAttribute(UserModel.USERNAME) によってアクセス可能であることを意味しています。他のフィールドには同様の影響が存在します。UserModel を直接的または間接的にサブクラス化する SPI の実装者は、setUsername と setSingleAttribute(UserModel.USERNAME, …​)(および他のフィールドについても同様) の間の動作が一貫していることを確認する必要があります。

ポリシー評価機能のユーザーは、評価する属性の数を使用する場合にはポリシーを調整する必要があります。すべてのユーザーには、デフォルトで 4 つの新しい属性が使用されます。

UserModel の公開 API は変更されませんでした。フロントエンドリソースやユーザーデータにアクセスする SPI への変更は必要ありません。また、データベースはまだ変更されませんでした。

Red Hat Single Sign-On ログイン用のテーマのコンポーネントは PatternFly 4 にアップグレードされました。古い PatternFly 3 は新しいパターンと同時に実行されるので、PF3 コンポーネントを保持することができます。

ただし、ログインテーマの設計にいくつかの変更が加えられました。カスタムログインテーマを新しいバージョンにアップグレードしてください。必要な変更に関する例は、examples/themes/theme/sunrise ディレクトリーにあります。追加の設定は必要ありません。

Instagram IdP は新しい API を使用するようになりました。古いレガシー API は非推奨となりました。この変更には、新しい API クレデンシャルが必要です。詳細は、Server Administration Guide を参照してください。

Instagram IdP を使用して Instagram にログインするユーザーの場合は、パスワードなどの別の認証方法が必要になります。ログインして、Instagram ソーシャルリンクを手動で更新したり、Red Hat Single Sign-On で新しいアカウントを作成したりすることができます。この制限は、以前の API の Instagram ユーザー ID は新しい API と互換性がないためです。ただし、新規 API は一時的に新規ユーザー ID と古いユーザー ID の両方を返し、移行を許可します。Red Hat Single Sign-On は、ユーザーのログイン時に ID を自動的に移行します。

OpenID Connect パラメーターの request_uri を使用する場合、クライアントが SSRF 攻撃から保護するように 有効なリクエスト URI を設定する必要があります。

この機能は、クライアントの詳細ページの管理コンソール、または管理 REST API またはクライアント登録 API で設定できます。有効な Request URI には、特定のクライアントで許可される Request URI 値の一覧が含まれている必要があります。

代わりに、Valid Redirect URIs オプションなどのワイルドカードまたは相対パスを使用することもできます。ただし、セキュリティー上の理由から、できるだけ特定の値を使用することが推奨されます。

読み取り専用ユーザー属性を使用できるようになりました。これらのユーザー属性の一部は、REST API または Red Hat Single Sign-On ユーザーインターフェイスを使用してユーザーを更新する場合、ユーザーまたは管理者が編集することはできません。特に、この変更は以下のいずれかを使用する際に重要です。

詳細は、Threat model mitigation chapter を参照してください。

Docker プロトコルを使用した認証に成功すると、ユーザーセッションは作成されません。詳細は、サーバー管理ガイド を参照してください。

この Red Hat Single Sign-On バージョンの場合、OAuth2 Client Credentials Grant エンドポイントはデフォルトでトークンの更新を実行しません。この動作は、OAuth2 仕様に合わせて調整されます。

そのため、クライアント認証情報の認証に成功した後に、Red Hat Single Sign-On サーバー側でユーザーセッションが作成されません。その結果、パフォーマンスとメモリーの消費が向上されます。Client Credentials Grant を使用するクライアントでは、更新トークンの使用を停止することが推奨されます。代わりに、refresh_token を付与タイプとして使用する代わりに、grant_type=client_credentials のすべての要求で認証することが推奨されます。

これに関連して、Red Hat Single Sign-On は OAuth2 Revocation Endpoint のアクセストークンの取り消しをサポートします。そのため、必要に応じて、クライアントは個別のアクセストークンを取り消すことができます。

後方互換性を維持するには、以前のバージョンの動作を維持することができます。このアプローチが使用されると、クライアント認証情報の付与を使用した認証に成功した後に更新トークンが発行されます。また、ユーザーセッションが作成されます。特定のクライアントでは、以下のように管理コンソールで以前の動作を有効にすることができます。

以前のバージョンでは、Red Hat Single Sign-On がアドバタイズされた 2 つのイントロスペクションエンドポイント (token_introspection_endpoint および introspection_endpoint)後者は RFC-8414 で定義されるものと同じです。前者は非推奨となり、削除されました。

以前の Red Hat Single Sign-On バージョンでは、LDAP プロバイダーが Import Users OFF で設定されている場合、LDAP 以外のマッピング属性が変更されてもユーザーを更新することができました。この状況では、混乱を生じさせる動作が発生していました。更新されると表示される属性ですが、更新されませんでした。

たとえば、管理 REST API でユーザーを更新しようとし、ユーザーが間違った属性の変更があった場合、更新が可能でした。現在のバージョンでは更新は不可能であり、理由について即座に通知されます。

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

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

本リリースでは、レルムに重複した最上位グループを作成できる問題を修正しています。以前の重複グループが存在すると、アップグレードプロセスが失敗します。Red Hat Single Sign-On サーバーは、H2、MariaDB、MySQL、または PostgreSQL データベースを使用している場合は、この問題の影響を受けます。アップグレードを開始する前に、サーバーに重複した最上位グループが含まれているかどうかを確認します。たとえば、以下の SQL クエリーはデータベースレベルで実行して一覧表示できます。

SELECT REALM_ID, NAME, COUNT(*) FROM KEYCLOAK_GROUP WHERE PARENT_GROUP is NULL GROUP BY REALM_ID, NAME HAVING COUNT(*) > 1;

同じ名前のレルムごとに 1 つの最上位グループのみが存在します。重複は、アップグレード前に確認および削除する必要があります。アップグレードのエラーには、Change Set META-INF/jpa-changelog-9.0.1.xml::9.0.1- KEYCLOAK-12579-add-not-null-constraint::keycloak failed というメッセージが含まれます。

ユーザー認証情報の保存に柔軟性が追加されました。一方で、すべてのユーザーが、複数の OTP クレデンシャルなど、同じタイプの複数の認証情報を持つことができます。これに関連してデータベーススキーマに変更がいくつか存在しますが、前のバージョンの認証情報は新しい形式に更新されます。ユーザーは、以前のバージョンで定義されたパスワードまたは OTP 認証情報を使用してログインできます。

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

ログインページのロケールの選択方法や、ユーザーのロケールが更新された時などに多くの改良が加えられました。詳細は、サーバー管理ガイド を参照してください。

JavaScript アダプターに promiseType を設定する必要はなく、いずれも同時に利用できるようになりました。レガシー API (success および error) がある時点ですぐにネイティブな promise API (then および catch) を使用するようにアプリケーションを更新することが推奨されます。

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

以前のリリースでは、開発者は JavaScript アダプターにクライアント認証情報を提供することができました。クライアント側のアプリは秘密を守るという点で安全ではないため、現在、この機能は削除されました。prompt=none をデフォルトの IDP に伝播する機能

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

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

この切り替えは、デフォルトの IDP が指定されている場合にのみ考慮されることに注意してください。この場合は、ユーザーに IDP の選択を求めることなく、認証要求を転送する場所がわかります。デフォルトの IDP を決定できない場合は、認証要求を実行するためにどちらが使用されるかを想定できないため、要求の転送は実行されません。

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

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

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

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

以下は、UMA 2.0 サポートによって導入される主な変更です。詳細は、認証サービスガイド を参照してください。

Client Scopes がサポートされるようになりました。これには、移行時に注意する必要があります。

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

Red Hat Single Sign-On サーバーが EAP 7.2 を基礎となるコンテナーとして使用するようにアップグレードされました。これには、特定の Red Hat Single Sign-On サーバー機能は直接関係しませんが、言及する価値がある移行に関連する変更はほとんどありません。

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

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

過去にネイティブな promise が利用できる場合は、従来の Keycloak の promise とネイティブの promise の両方を提供していたラッパーが返されていました。これにより、エラーハンドラーがネイティブエラーイベントの前に常に設定されていなかったため、問題が生じていました。その結果、Uncaught (in promise) エラーが発生していました。

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

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

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

アプリケーション ID がディレクトリーで見つからないというエラーが発生した場合は、クライアントアプリケーションを Google API Console ポータルに登録し、新規アプリケーション ID およびシークレットを取得する必要があります。

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

LinkedIn に応じて、すべての開発者は API および OAuth 2.0 のバージョン 2.0 に移行する必要があります。そのため、LinkedIn Social Broker を更新しました。

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

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

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

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

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

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

RH-SSO 7.1 では、このクエリーパラメーターをアダプターに追加しましたが、以前の動作を維持し、移行に対応しました。

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

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

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

OpenID Connect Session Management 仕様では、session_state パラメーターが OpenID Connect Authentication 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 Compatibility Modes のセクションにあるクライアントの詳細で、Red Hat Single Sign-On 管理コンソールの特定のクライアントに対して実行できます。認証応答から除外セッションの状態 スイッチがあり、session_state パラメーターを認証応答に追加しないようにオンにすることができます。

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

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

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

アプリケーション ID がディレクトリーで見つからないというエラーが発生した場合は、クライアントアプリケーションを Google API Console ポータルに登録し、新規アプリケーション ID およびシークレットを取得する必要があります。

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

LinkedIn に応じて、すべての開発者は API および OAuth 2.0 のバージョン 2.0 に移行する必要があります。そのため、LinkedIn Social Broker を更新しました。この統合を使用している場合は、Red Hat Single Sign-On バージョン 7.2.6 以降にアップグレードしてください。

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

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

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

RH-SSO 7.0 の場合は、1 つのキーセットのみがレルムに関連付けることができます。つまり、キーを変更すると、現在のクッキーとトークンがすべて無効になり、すべてのユーザーが再認証する必要があります。RH-SSO 7.1 で、1 つのレルムに対して複数のキーのサポートが追加されました。いつでも、1 セットのキーが署名の作成に使用されるアクティブセットですが、署名の検証に使用される複数のキーが存在する可能性があります。つまり、古い Cookie とトークンを検証してから、新しい署名で更新できることを意味し、キーを変更した時にユーザーが認証したままになることを可能にあります。また、管理コンソールおよび管理 REST API でキーを管理する方法にはいくつかの変更があります。詳細は、サーバー管理ガイドの レルムキー を参照してください。

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

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

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

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

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 ファイルに自動的に移行します。

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

アップグレードする前に、アップグレード手順を実行する必要があります。特に、アダプターをアップグレードする前に Red Hat Single Sign-On サーバーをアップグレードするようにしてください。

以下のガイドラインに従って、サーバーが正常にアップグレードされるようにします。

インストールに使用した方法に基づいて、サーバーを ZIP ファイル または RPM からアップグレードします。

以前のインストールに基づいて、お使いの状況に適した適切なアップグレードスクリプトを実行します。

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

 <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="connectionsLiquibase">
    <provider name="default" enabled="true">
        <properties>
            <property name="indexCreationThreshold" value="300000"/>
        </properties>
    </provider>
</spi>

/subsystem=keycloak-server/spi=connectionsLiquibase/:add(default-provider=default)
/subsystem=keycloak-server/spi=connectionsLiquibase/provider=default/:add(properties={indexCreationThreshold => "300000"},enabled=true)

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

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

カスタムテーマを作成している場合は、それらを新しいサーバーに移行する必要があります。組み込みテーマへの変更は、カスタマイズした内容によっては、カスタムテーマに反映する必要がある場合があります。

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

つまり、以下のようになります。

各ステップについて、変更のリストをより詳細に説明しています。

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

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

管理対象ドメイン環境の複数の RH-SSO ホストの場合、各ホストは RH-SSO ドメインコントローラーからパッチを当てることができます。

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

/core-service=patching:ageout-history

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

yum update