2.2. RH SSO 7.5

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 プロトコルを使用した認証に成功すると、ユーザーセッションは作成されません。詳細は、Server Administration Guide を参照してください。

この 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 でユーザーを更新しようとし、ユーザーが間違った属性の変更があった場合、更新が可能でした。現在のバージョンでは更新は不可能であり、理由について即座に通知されます。