アップグレードガイド

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.4 へ) は、プライベートではないまたはサポート対象外のもの、またはテクノロジープレビュー API が使用されてる場合は、アプリケーションやカスタムサーバーの拡張機能にコードを変更する必要はありません。

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

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

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;

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"/>

<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 サーバーをアップグレードしてから、アダプターをアップグレードする必要があります。

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

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

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

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

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

 <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)

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

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

 <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)

/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

$ 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

/core-service=patching:ageout-history

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

yum update

yum update

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

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

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

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