第2章 変更

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

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

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

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

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

このストラテジーでは、各認証フローで以前のバージョンと同じまたは同様の動作が保証されます。ただし、認証フローの構成を確認し、期待どおりに機能することを再確認することはできます。この推奨事項は、カスタムオーセンティケーターの実装を使用したカスタマイズされた認証フローに特に適用されます。

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

以前のバージョンで設定された OPTIONAL オーセンティケーターは、CONDITIONAL サブフローに置き換えられます。これらのサブフローには、Condition - User 構成条件が最初の実行として構成され、以前の OPTIONAL オーセンティケーター (OTP フォームなど) が 2 番目の実行として構成されています。ユーザーの場合には、認証中の動作は、以前のバージョンの動作と一致します。

Java Authentication SPI および Credential Provider SPI にはいくつかの変更が存在します。

インターフェースオーセンティケーターは変更されていませんが、新しい認証情報タイプ (CredentialModel のサブクラス) を導入する高度なオーセンティケーターを開発する場合は、影響を受ける可能性があります。CredentialProvider インターフェースには変更があり、CredentialValidator などの新しいインターフェースが導入されています。

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

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

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

非推奨となった正確な方法や代替方法の詳細は、JavaDocs ドキュメント を参照してください。

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

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

この 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 管理コンソールの特定のクライアントに対して有効にできます。クライアントの詳細については、OpenID Connect Compatibility Modes のセクションで、スイッチ Use Refresh Tokens For Client Credentials Grant を使用してください。

OpenID Connect パラメーターの request_uri を使用すると、クライアントが Valid Request URIs を設定する必要があるという要件が存在します。このパラメーターは、クライアントの詳細ページの管理コンソール、または 管理 REST API またはクライアント登録 API で設定できます。有効なRequest URI には、特定のクライアントで許可される Request URI 値の一覧が含まれている必要があります。これは、SSRF 攻撃を回避するためのものです。Valid Redirect URIs オプションなど、ワイルドカードまたは相対パスを使用することもできますが、セキュリティーの目的で、通常は特定の値として使用することが推奨されます。