2.4. RH SSO 7.3
RH-SSO 7.2 から RH-SSO 7.3 に以下の変更が加えられました。
2.4.1. 認可サービスの変更
UMA 2.0 のサポートが追加されました。このバージョンの UMA 仕様では、パーミッションの取得方法に関する重要な変更がいくつか導入されました。
以下は、UMA 2.0 サポートによって導入される主な変更です。詳細は、Authorization Services Guide を参照してください。
- 認可 API が削除されました。
- UMA 2.0 (UMA 1.0) より前のバージョンでは、クライアントアプリケーションは Authorization API を使用して RPT の形式でサーバーからパーミッションを取得していました。新しいバージョンの UMA 仕様では、Red Hat Single Sign-On からも削除された Authorization API が削除されました。UMA 2.0 では、特定の付与タイプを使用して、RPT がトークンエンドポイントから取得できるようになりました。詳細は、Authorization Services Guide を参照してください。
- エンタイトルメント API が削除されました。
- UMA 2.0 の導入に伴い、トークンエンドポイントと UMA 付与タイプを活用して、Red Hat Single Sign-On から RPT を取得できるようにし、異なる API を使用しないようにすることにしました。Entitlement API によって提供される機能は同じままであり、リソースまたはスコープが提供されていない場合でも、サーバーから 1 つ以上のリソースとスコープのセットに対するアクセス許可、またはすべてのアクセス許可を取得できます。詳細は、Authorization Services Guide を参照してください。
- UMA 検出エンドポイントへの変更
- UMA 検出ドキュメントが変更されました。詳細は、Authorization Services Guide を参照してください。
- Red Hat Single Sign-On Authorization JavaScript アダプターの変更点
Red Hat Single Sign-On Authorization JavaScript アダプター (keycloak-authz.js) は、以前と同じ動作を維持しながら、UMA 2.0 によって導入された変更に準拠するために変更されました。主な変更点は、
authorizationとentitlementメソッドの両方を呼び出す方法にあります。これにより、認可要求を表す特定のオブジェクトタイプが期待されます。この新しいオブジェクトタイプでは、UMA 付与タイプでサポートされる異なるパラメーターをサポートし、サーバーから取得できるパーミッションを柔軟に提供できます。詳細は、Authorization Services Guide を参照してください。One of the main changes introduced by this release is that you are no longer required to exchange access tokens with RPTs in order to access resources protected by a resource server (when not using UMA). Depending on how the policy enforcer is configured on the resource server side, you can just send regular access tokens as a bearer token and permissions will still be enforced.
- Red Hat Single Sign-On Authorization Client Java API への変更
-
Red Hat Single Sign-On Authorization Client Java API の新しいバージョンにアップグレードする際に、一部の表現クラスが
org.keycloak:keycloak-coreの別のパッケージに移動したことに注意してください。
2.4.2. クライアントスコープに変更になったクライアントテンプレート
Client Scopes がサポートされるようになりました。これには、移行時に注意する必要があります。
- クライアントスコープに変更になったクライアントテンプレート
- クライアントテンプレートはクライアントスコープに変更されました。クライアントテンプレートがある場合、プロトコルマッパーおよびロールスコープのマッピングは保持されます。
- 名前で置き換えられたスペース
-
名前に空白文字が含まれるクライアントテンプレートは、クライアントスコープの名前に空白を使用できないため、空白をアンダースコアに置き換えるように名前が変更されました。たとえば、クライアントテンプレート
my templateはクライアントスコープmy_templateに変更されます。 - クライアントスコープのクライアントへのリンク
-
クライアントテンプレートを持つクライアントでは、対応するクライアントスコープが
Default Client Scopeとしてクライアントに追加されます。そのため、プロトコルマッパーとロールマッピングはクライアントに保存されます。 - レルムのデフォルトのクライアントスコープが既存のクライアントにリンクされていない
-
移行時に、組み込みクライアントスコープのリストが、各レルムと、
レルムのデフォルトクライアントスコープのリストが追加されます。ただし、既存のクライアントはアップグレードされず、新しいクライアントスコープは自動的に追加されません。また、プロトコルマッパーとロールスコープのマッピングはすべて既存のクライアントに保持されます。新しいバージョンでは、新規クライアントの作成時に、Realm Default Client Scopes が自動的に割り当てられ、プロトコルマッパーが割り当てられません。たとえば、クライアントのプロトコルマッパーのカスタマイズを適切に検出することは不可能であるため、移行中に既存のクライアントを変更しませんでした。既存のクライアントを更新する (プロトコルマッパーをクライアントから削除し、クライアントスコープにリンクする) 場合は、手動で行う必要があります。 - 競合を再度確認する必要がある
- クライアントスコープの変更では、連携のリファクタリングが必要でした。これで、ロールまたはプロトコルマッパーではなく、クライアントスコープを参照するようになりました。この変更により、以前に確認されたユーザーによる永続的な同意は無効になり、ユーザーは移行後に同意ページを再度確認する必要があります。
- いくつかの設定スイッチが削除される
-
スイッチ
Scope Param Requiredがロールの詳細から削除されました。Consent RequiredスイッチおよびConsent Textスイッチが、プロトコルマッパーの詳細から削除されました。これらのスイッチは Client Scope 機能に置き換えられました。
2.4.3. 新しいデフォルトのクライアントスコープ
新しいレルムのデフォルトクライアントスコープ roles および web-origins を追加しました。これらのクライアントスコープには、ユーザーのロールと許可された Web オリジンをトークンに追加するプロトコルマッパーが含まれます。移行時に、これらのクライアントスコープをデフォルトのクライアントスコープとしてすべての OpenID Connect クライアントに自動的に追加する必要があります。したがって、データベースの移行が完了したら、設定は必要ありません。
2.4.3.1. プロトコルマッパー SPI の追加
これに関連して、(サポートされていない) プ Protocol Mappers SPI に小規模な追加があります。カスタム ProtocolMapper を実装している場合にのみ、影響を受ける可能性があります。ProtocolMapper インターフェイスには、新しい getPriority() メソッドがあります。メソッドでは、デフォルトの実装は 0 を返すように設定されます。プロトコルマッパー実装が、realmAccess プロパティーまたは resourceAccess プロパティーのロールに依存する場合は、マッパーの優先度を増やす必要がある場合があります。
2.4.3.2. オーディエンスの解決
認証されたユーザーには、トークンに最低でも 1 つのクライアントロールがあるすべてのクライアントのオーディエンスが、アクセストークンの aud 要求に自動的に追加されるようになりました。一方、アクセストークンには、それが発行されたフロントエンドクライアントのオーディエンスが自動的に含まれない場合があります。詳細は、Server Administration Guide を参照してください。
2.4.4. EAP 7.2 へのアップグレード
Red Hat Single Sign-On サーバーが EAP 7.2 を基礎となるコンテナーとして使用するようにアップグレードされました。これには、特定の Red Hat Single Sign-On サーバー機能は直接関係しませんが、言及する価値がある移行に関連する変更はほとんどありません。
- 依存関係の更新
- この依存関係は、EAP 7.2 サーバーが使用するバージョンに更新されました。たとえば、Infinispan は 9.3.1.Final になりました。
- 設定変更
-
standalone(-ha).xmlおよびdomain.xmlファイルの設定変更はほとんどありません。設定ファイルの自動移行を処理するには、「Red Hat Single Sign-On サーバーのアップグレード」 セクションに従う必要があります。 - データセンター間のレプリケーションの変更
- RHDG サーバーをバージョン 7.3 にアップグレードする必要があります。古いバージョンはまだ動作する場合もありますが、テストしていないため保証はありません。
-
Red Hat Single Sign-On 設定の
remote-store要素の設定に、値が2.6のprotocolVersionプロパティーを追加する必要があります。これは、RHD 7.3 で使用されるバージョンと互換性を持たせるために HotRod プロトコルのバージョンをダウングレードする必要があるため必要です。
2.4.5. ホスト名の設定
以前のバージョンでは、許可されたホスト名を指定するためにフィルターを使用することが推奨されます。固定ホスト名を設定することで、有効なホスト名が使用されることを確認し、内部アプリケーションが内部 IP アドレスなどの別の URL を使用して Red Hat Single Sign-On を呼び出すことができるようになっています。実稼働環境で、このアプローチに切り替えることが推奨されます。
2.4.6. JavaScript アダプターの promise
JavaScript アダプターでネイティブの JavaScript Promise を使用できるようにするには、init オプションで、promiseType を native に設定する必要があります。
過去にネイティブな promise が利用できる場合は、従来の Keycloak の promise とネイティブの promise の両方を提供していたラッパーが返されていました。これにより、エラーハンドラーがネイティブエラーイベントの前に常に設定されていなかったため、問題が生じていました。その結果、Uncaught (in promise) エラーが発生していました。
2.4.7. Microsoft Identity Provider が Microsoft Graph API を使用するように更新
認可の 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 ポータルでクライアントアプリケーションを再度登録する必要があります。
2.4.8. Google ID プロバイダーが Google Sign-in 認証システムを使用するように更新されました。
認可の 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 ドキュメントを参照してください。
2.4.9. LinkedIn Social Broker が LinkedIn API のバージョン 2 に更新
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 が設定されていることを示しています。
