2.3. RH SSO 7.4
Red Hat Single Sign-On 7.3 から Red Hat Single Sign-On 7.4 に以下の変更が加えられました。
2.3.1. EAP 7.3 へのアップグレード
Red Hat Single Sign-On サーバーが EAP 7.3 を基礎となるコンテナーとして使用するようにアップグレードされました。この変更には、特定の Red Hat Red Hat Single Sign-On 機能は直接含まれていませんが、移行に関連する変更がいくつかあります。
2.3.1.1. 依存関係の更新
依存関係は、EAP 7.3 サーバーが使用するバージョンに更新されました。たとえば、Infinispan コンポーネントバージョンは 9.3.1.Final になりました。
2.3.1.2. 設定変更
standalone(-ha).xml ファイルおよび domain.xml ファイルにはいくつかの設定変更があります。Red Hat Single Sign-On サーバーのアップグレードセクションに従って、設定ファイルの自動移行を処理します。
2.3.1.3. データセンター間のレプリケーションの変更
RHDG をバージョン 7.3 にアップグレードする必要があります。古いバージョンはまだ機能する可能性はありますが、テストされていないため、機能する保証はありません。
2.3.2. 認証フローの変更
認証フローに関連するリファクタリングおよび改善がありました。これには、移行時に注意する必要があります。
2.3.2.1. REQUIRED と ALTERNATIVE の実行は、同じ認証フローでは対応していません。
以前のバージョンでは、同じレベルの同じ認証フローに REQUIRED および ALTERNATIVE の実行を行うことができました。このアプローチにはいくつかの問題があり、Authentication SPI のリファクタリングが行われました。つまり、これは有効ではなくなります。ALTERNATIVE および REQUIRED の実行が同じレベルで設定されている場合、ALTERNATIVE 実行は無効にされます。
したがって、このバージョンに移行すると、既存の認証フローが移行されますが、以前のバージョンの動作が保持されます。認証フローに ALTERNATIVE 実行が REQUIRED 実行と同じレベルに含まれる場合は、ALTERNATIVE 実行が別個の REQUIRED サブフローに追加されます。
このストラテジーでは、各認証フローで以前のバージョンと同じまたは同様の動作が保証されます。ただし、認証フローの設定を確認し、期待どおりに機能することを再確認することはできます。この推奨事項は、カスタムオーセンティケーターの実装を使用したカスタマイズされた認証フローに特に適用されます。
2.3.2.2. OPTIONAL の実行要件が削除されました
移行に関して最も重要な変更は、認証の実行から OPTIONAL 要件のサポートを削除し、それを CONDITIONAL 要件に置き換えることです。これにより、柔軟性が向上します。
以前のバージョンで設定された OPTIONAL オーセンティケーターは、CONDITIONAL サブフローに置き換えられます。これらのサブフローには、Condition - User 設定条件が最初の実行として設定され、以前の OPTIONAL オーセンティケーター (OTP フォームなど) が 2 番目の実行として設定されています。ユーザーの場合には、認証中の動作は、以前のバージョンの動作と一致します。
2.3.2.3. SPI の変更点
Java Authentication SPI および Credential Provider SPI にはいくつかの変更が存在します。
インターフェイスオーセンティケーターは変更されていませんが、新しい認証情報タイプ (CredentialModel のサブクラス) を導入する高度なオーセンティケーターを開発する場合は、影響を受ける可能性があります。CredentialProvider インターフェイスには変更があり、CredentialValidator などの新しいインターフェイスが導入されています。
また、オーセンティケーターが OPTIONAL 実行要件に対応している場合は、影響を受ける可能性があります。詳細については、サーバー開発ガイドの最新の認証例を再確認することが推奨されます。
2.3.2.4. Freemarker テンプレートの変更
フリーマーカーテンプレートに変更があります。ログインフォームまたは一部のアカウントフォーム、特に OTP に関連するフォーム用のカスタムフリーマーカーテンプレートを使用した独自のテーマがある場合は、影響を受ける可能性があります。このバージョンの FreeMarker テンプレートの変更を確認し、テンプレートを調整することが推奨されます。
2.3.3. 重複した最上位のグループ
本リリースでは、レルムに重複した最上位グループを作成できる問題を修正しています。以前の重複グループが存在すると、アップグレードプロセスが失敗します。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
というメッセージが含まれます。
2.3.4. ユーザー認証情報の変更
ユーザー認証情報の保存に柔軟性が追加されました。一方で、すべてのユーザーが、複数の OTP クレデンシャルなど、同じタイプの複数の認証情報を持つことができます。これに関連してデータベーススキーマに変更がいくつか存在しますが、前のバージョンの認証情報は新しい形式に更新されます。ユーザーは、以前のバージョンで定義されたパスワードまたは OTP 認証情報を使用してログインできます。
2.3.5. 新しい任意のクライアントスコープ
MicroProfile/JWT Auth Specification で定義される要求を処理するために microprofile-jwt の任意のクライアントスコープが追加されました。この新しいクライアントスコープは、認証済みユーザーのユーザー名を upn 要求に設定し、レルムロールを groups 要求に設定するプロトコルマッパーを定義します。
2.3.6. ユーザーロケールの処理が改善
ログインページのロケールの選択方法や、ユーザーのロケールが更新された時などに多くの改良が加えられました。詳細は、Server Administration Guide を参照してください。
2.3.7. JavaScript アダプターのレガシープロミス
JavaScript アダプターに promiseType を設定する必要はなく、いずれも同時に利用できるようになりました。レガシー API (success および error) がある時点ですぐにネイティブな promise API (then および catch) を使用するようにアプリケーションを更新することが推奨されます。
2.3.8. サーバーへのスクリプトのデプロイ
これまで、管理者は Red Hat Single Sign-On 管理コンソールおよび RESTful Admin API を使用してスクリプトをサーバーにアップロードできるようになりました。この機能は無効にされています。ユーザーはスクリプトを直接サーバーにデプロイする必要があります。詳細は、JavaScript Providers を参照してください。
2.3.9. 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 を決定できない場合は、認証要求を実行するためにどちらが使用されるかを想定できないため、要求の転送は実行されません。
2.3.10. 新しいデフォルトホスト名プロバイダー
要求および固定ホスト名プロバイダーが新規のデフォルトのホスト名プロバイダーに置き換えられました。要求および固定のホスト名プロバイダーは非推奨となり、できるだけ早くデフォルトのホスト名プロバイダーに切り替えることが推奨されます。
2.3.11. 非推奨または削除された機能
特定の機能のステータスが変更になりました。
2.3.11.1. トークン表現の Java クラスの非推奨のメソッド
2038 年に、int は 1970 年以降、秒の値を保持できなくなります。そのため、これらを長い値に更新する作業を行っています。トークン表現では、さらに問題があります。int は、デフォルトでは JSON 表現で 0 になりますが、含めるべきではありません。
非推奨となった正確な方法や代替方法の詳細は、JavaDocs ドキュメント を参照してください。
2.3.11.2. スクリプトのアップロード
管理 REST エンドポイントおよびコンソールを使用したスクリプトのアップロードが非推奨となりました。これは今後のリリースで削除されます。
2.3.12. 認可サービスの Drools ポリシー
認可サービスの Drools ポリシーが削除されました。