Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

12.2. レガシートークン交換

注記

トークン交換は プレビュー であり、完全にはサポートされていません。この機能はデフォルトで無効化されています。

有効にするには、--features=preview または --features=token-exchange でサーバーを起動します。

トークンの交換は テクノロジープレビュー であるため、完全にサポートされていません。

注記

内部トークンから内部トークンへの交換 フロー以上のものを使用するには、admin-fine-grained-authz 機能も有効にします。詳細は、機能の有効化と無効化 の章を参照してください。

12.2.1. トークン交換の仕組み
リンクのコピー

Red Hat build of Keycloak では、トークン交換とは、一連の認証情報またはトークンを使用してまったく異なるトークンを取得するプロセスのことです。クライアントは、信頼性の低いアプリケーションで呼び出したい場合があるため、現在のトークンをダウングレードしたい場合があります。クライアントは、Red Hat build of Keycloak トークンを、リンクされたソーシャルプロバイダーアカウント用に保存されているトークンと交換することを推奨します。他の Red Hat build of Keycloak レルムまたは外部 IDP によって生成された外部トークンを信頼することを推奨します。クライアントでは、ユーザーの権限を借用しなければならない場合があります。以下は、トークン交換に関する Red Hat build of Keycloak の現行機能に関する概要です。

  • クライアントは、特定のクライアント用に作成された既存の Red Hat build of Keycloak トークンを、別のクライアントを対象とした新しいトークンと交換できます。
  • クライアントは、既存の Red Hat build of Keycloak トークンを外部トークン (リンクされた Facebook アカウントなど) と交換できます。
  • クライアントが外部トークンを Red Hat build of Keycloak トークンと交換できる。
  • クライアントはユーザーの権限を借用できます。

Red Hat build of Keycloak におけるトークン交換は、IETF の OAuth トークン交換 仕様の非常に緩い実装です。この仕様を少し拡張し、一部を無視して、他の部分は大まかに解釈しました。これは、レルムの OpenID Connect トークンエンドポイントにおける単純な付与タイプ呼び出しです。 

/realms/{realm-name}/protocol/openid-connect/token
Copy to Clipboard Toggle word wrap

これは、フォームパラメーター (application/x-www-form-urlencoded) を入力として受け付け、出力は交換を要求したトークンのタイプによって異なります。トークン交換はクライアントエンドポイントであるため、リクエストは呼び出し元のクライアントに対して認証情報を提供する必要があります。パブリッククライアントは、クライアント識別子を form パラメーターとして指定します。機密クライアントは、フォームパラメーターを使用して、クライアント ID とシークレット、Basic 認証、または管理者がレルムで設定したクライアント認証フローを渡すこともできます。

12.2.1.1. フォームパラメーター
リンクのコピー

client_id
必須の可能性あり。このパラメーターは、認証にフォームパラメーターを使用するクライアントに必要です。Basic 認証、クライアント JWT トークン、またはクライアント証明書認証を使用している場合は、このパラメーターを指定しないでください。
client_secret
必須の可能性あり。このパラメーターは、認証にフォームパラメーターを使用し、認証情報としてクライアントシークレットを使用するクライアントに必要です。レルムのクライアント呼び出しが別の手段で認証されている場合は、このパラメーターは指定しないでください。
grant_type
必須。パラメーターの値は urn:ietf:params:oauth:grant-type:token-exchange にする必要があります。
subject_token
任意。リクエストが行われている当事者の ID を表すセキュリティートークン。これは、既存のトークンを新しいトークンと交換する場合に必要です。
subject_issuer
任意。subject_token の発行者を特定します。トークンが現在のレルムから送信される場合や、発行者が subject_token_type から判断できる場合は空白のままにすることができます。それ以外の場合は指定する必要があります。有効な値は、レルムに設定された Identity Provider のエイリアスです。または、特定の Identity Provider によって設定された発行者クレーム識別子です。
subject_token_type
任意。このパラメーターは、subject_token パラメーターで渡されるトークンのタイプです。subject_token がレルムから取得され、アクセストークンである場合、デフォルトは urn:ietf:params:oauth:token-type:access_token に設定されます。外部トークンの場合には、subject_issuer の要件に応じてこのパラメーターを指定する必要がある場合とそうでない場合があります。
requested_token_type
任意。このパラメーターは、クライアントが交換するトークンのタイプを表します。現在、oauth および OpenID Connect トークンタイプのみがサポートされます。このデフォルト値は urn:ietf:params:oauth:token-type:refresh_token であるかどうかによって異なります。この場合、応答内でアクセストークンとリフレッシュトークンの両方が返されます。その他の適切な値は、urn:ietf:params:oauth:token-type:access_token および urn:ietf:params:oauth:token-type:id_token です。
audience
任意。このパラメーターは、新しいトークンを作成するターゲットクライアントを指定します。
requested_issuer
任意。このパラメーターは、クライアントが外部プロバイダーによって作成されたトークンを必要とすることを指定します。レルム内で設定された Identity Provider のエイリアスである必要があります。
requested_subject
任意。これは、クライアントが別のユーザーになりすます場合のユーザー名またはユーザー ID を指定します。
scope
任意。このパラメーターは、クライアントが要求しているターゲットの OAuth および OpenID Connect スコープセットを表します。返されるスコープは、スコープパラメーターとアクセストークンスコープのカルテジアン積です。
注記

現在、OpenID Connect および OAuth の交換のみをサポートします。SAML ベースのクライアントおよびアイデンティティープロバイダーのサポートは、ユーザーの需要に応じて今後追加される可能性があります。

12.2.1.2. トークン交換リクエストからのレスポンス
リンクのコピー

交換の呼び出しが成功した場合のレスポンスは、HTTP 200 レスポンスコードを返します。その際コンテンツタイプは、クライアントが要求する requested-token-type と requested_issuer によって決まります。OAuth が要求するトークンタイプは、OAuth Token Exchange 仕様で説明されているように、JSON ドキュメントを返します。 

{
   "access_token" : ".....",
   "refresh_token" : ".....",
   "expires_in" : "...."
 }
Copy to Clipboard Toggle word wrap

リフレッシュトークンを要求するクライアントは、レスポンスでアクセストークンとリフレッシュトークンの両方を返します。アクセストークンタイプのみを要求するクライアントは、レスポンスでアクセストークンのみを取得します。requested_issuer パラメーターを介して外部発行者を要求するクライアントの有効期限情報は、含まれる場合とそうでない場合があります。

通常、エラー応答は 400 HTTP 応答コードカテゴリーに分類されますが、エラーの重大度に応じて他のエラーステータスコードが返される場合があります。エラー応答には、requested_issuer に依存するコンテンツが含まれる場合があります。OAuth ベースの交換では、以下のように JSON ドキュメントが返される場合があります。 

{
   "error" : "...."
   "error_description" : "...."
}
Copy to Clipboard Toggle word wrap

交換タイプに応じて、追加のエラークレームを返すことができます。たとえば、ユーザーにアイデンティティープロバイダーへのリンクがない場合、OAuth アイデンティティープロバイダーに追加の account-link-url クレームが含まれることがあります。このリンクは、クライアント起点のリンクのリクエストに使用できます。

注記

トークン交換の設定には、詳細にわたる管理者権限に関する知識が必要です (詳細は、サーバー管理ガイド を参照してください)。交換にクライアントパーミッションを付与する必要があります。これは、この章で後ほど説明します。

この章の残りの部分では、セットアップ要件を説明し、さまざまな交換シナリオの例を示します。分かりやすくするために、現在のレルムで作成された最小のトークンを 内部 トークンとして呼び出し、外部レルムまたは ID プロバイダーによって作成されたトークンを 外部 トークンと呼ぶことにします。

12.2.2. 内部トークンから内部トークンへの交換
リンクのコピー

注記

内部トークン間の交換では、以下に説明するレガシートークン交換フローを使用する代わりに、標準トークン交換 を使用することを推奨します。標準トークン交換が正式にサポートされています。

内部のトークンからトークンへの交換では、特定のクライアントに作成された既存のトークンがあり、このトークンを別のターゲットクライアントに作成された新しいトークンと交換する必要があります。なぜこれを実行する必要があるのでしょうか。これは通常、あるクライアントが自身のために発行されたトークンを保有しており、アクセストークンに含まれるものとは異なるクレームや権限を必要とする他のアプリケーションに、追加のリクエストを行う必要が生じた場合に発生します。このタイプの交換が必要となるかもしれないその他の理由は、アプリが信頼性の低いアプリで呼び出す必要があり、現在のアクセストークンを伝播したくない場合の "パーミッションのダウングレード" を実行する必要がある場合です。

12.2.2.1. 交換のための権限付与
リンクのコピー

別のクライアントのトークンを交換する必要のあるクライアントは、管理コンソールで認可される必要があります。交換するパーミッションを付与するクライアントに、token-exchange の細かいパーミッションを定義する必要があります。

図12.3 ターゲットクライアントパーミッション

ターゲットクライアントパーミッション
View larger image
ターゲットクライアントパーミッション

手順

  1. Permissions Enabled を On に切り替えます。

    図12.4 ターゲットクライアントパーミッション

    ターゲットクライアント交換のパーミッション設定
    View larger image
    ターゲットクライアント交換のパーミッション設定

    そのページには、token-exchange のリンクが表示されます。

  2. そのリンクをクリックして、パーミッションの定義を開始します。

    このセットアップページが表示されます。

    図12.5 ターゲットクライアント交換のパーミッション設定

    ターゲットクライアント交換のパーミッション設定
    View larger image
    ターゲットクライアント交換のパーミッション設定
  3. 画面上部のブレッドクラムで Client details をクリックします。
  4. このパーミッションのポリシーを定義します。
  5. 画面上部のブレッドクラムで Authorization をクリックします。
  6. このパーミッションのポリシーを定義します。
  7. Policies タブをクリックします。

  8. Create policy ボタンをクリックして Client を作成します。

    図12.6 クライアントポリシーの作成

    クライアントポリシーの作成
    View larger image
    クライアントポリシーの作成
  9. トークン交換を要求している認証済みクライアントである開始クライアントを入力します。

  10. このポリシーを作成したら、ターゲットクライアントの token-exchange パーミッションに戻り、定義したクライアントポリシーを追加します。

    図12.7 クライアントポリシーの適用

    クライアントポリシーの適用
    View larger image
    クライアントポリシーの適用

これでクライアントを呼び出すパーミッションがある。これを正しく行わないと、エクスチェンジを作成しようとすると、403 Forbidden 応答が返されます。

12.2.2.2. リクエストの作成
リンクのコピー

クライアントが、既存のトークンを他のクライアントをターゲットにしたトークンと交換する場合は、audience パラメーターを使用します。このパラメーターは、管理コンソールで設定したターゲットクライアントのクライアント識別子である必要があります。 

curl -X POST \
    -d "client_id=starting-client" \
    -d "client_secret=the client secret" \
    --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
    -d "subject_token=...." \
    --data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:refresh_token" \
    -d "audience=target-client" \
    http://localhost:8080/realms/myrealm/protocol/openid-connect/token
Copy to Clipboard Toggle word wrap

subject_token パラメーターは、ターゲットレルムのアクセストークンである必要があります。requested_token_type パラメーターがリフレッシュトークンタイプである場合、応答にはアクセストークン、リフレッシュトークン、および有効期限が含まれます。以下は、この呼び出しから返される JSON 応答の例です。

audience パラメーターが設定されていない場合、このパラメーターの値は、デフォルトでトークン交換リクエストを行うクライアントに設定されます。

機密クライアントとは異なり、パブリッククライアントは他のクライアントからのトークンを使用してトークン交換を実行することはできません。subject_token を指定する場合には、トークンを発行した (機密の) クライアントと、リクエストを行ったクライアントが同じである必要があります。別のクライアントに対して発行された場合には、リクエストを行ったクライアントは、トークンに設定されたオーディエンスに含まれている必要があります。

ターゲットの audience (リクエストを行うクライアントとは異なるクライアント) を明示的に設定している場合は、リクエストを行うクライアントが交換を正常に完了できるように、クライアントの token-exchange スコープ権限が audience パラメーターに設定されていることも確認する必要があります。 

{
   "access_token" : "....",
   "refresh_token" : "....",
   "expires_in" : 3600
}
Copy to Clipboard Toggle word wrap

12.2.3. 内部トークンから外部トークンへの交換
リンクのコピー

レルムトークンを、外部 ID プロバイダーによって作成された外部トークンと交換できます。この外部 ID プロバイダーは、管理コンソールの Identity Provider セクション内で設定する必要があります。現時点で、OAuth/OpenID Connect ベースの外部 ID プロバイダーのみがサポートされます。これには、すべてのソーシャルプロバイダーが含まれます。Red Hat build of Keycloak は外部プロバイダーへのバックチャネル交換を実行しません。そのため、アカウントがリンクされていない場合は、外部トークンを取得できなくなります。これらの条件の 1 つの外部トークンを取得できるようにするには、以下の条件を満たしている必要があります。

  • ユーザーは、少なくとも 1 回、外部 ID プロバイダーを使用してログインしている必要があります。
  • ユーザーは、ユーザーアカウントサービスを使用して、外部 ID プロバイダーとリンクされている必要があります。
  • このユーザーアカウントが、クライアント起点のアカウントリンク API を使用して、外部のアイデンティティープロバイダー経由でリンクされている必要があります。

最後に、外部のアイデンティティープロバイダーがトークンを保存するように設定されている必要があります。または、上記のアクションの 1 つが、交換する内部トークンと同じユーザーセッションで実行されている必要があります。

アカウントがリンクされていない場合、交換応答には、アカウントを確立するために使用できるリンクが含まれます。詳細は、リクエストの作成 セクションで説明されています。

12.2.3.1. 交換のための権限付与
リンクのコピー

内部トークンから外部トークンへの交換リクエストは、管理者が呼び出し元クライアントに対して外部アイデンティティープロバイダーとのトークン交換を許可するまで、403 Forbidden レスポンスで拒否されます。クライアントに権限を付与するには、アイデンティティープロバイダーの設定ページの Permissions タブに移動します。

図12.8 アイデンティティープロバイダーの権限

アイデンティティープロバイダー交換のパーミッション
View larger image
アイデンティティープロバイダー交換のパーミッション

手順

  1. Permissions Enabled を On に切り替えます。

    図12.9 アイデンティティープロバイダーの権限

    アイデンティティープロバイダー交換のパーミッションセット
    View larger image
    アイデンティティープロバイダー交換のパーミッションセット

    ページには、token-exchange のリンクが表示されます。

  2. リンクをクリックして、パーミッションの定義を開始します。

    このセットアップページが表示されます。

    図12.10 アイデンティティープロバイダー交換のパーミッション設定

    アイデンティティープロバイダー交換のパーミッション設定
    View larger image
    アイデンティティープロバイダー交換のパーミッション設定
  3. 画面上部のブレッドクラムで Client details をクリックします。

  4. Policies タブをクリックして、クライアントポリシーを作成します。

    図12.11 クライアントポリシーの作成

    クライアントポリシーの作成
    View larger image
    クライアントポリシーの作成
  5. トークン交換を要求する認証されたクライアントである、開始クライアントを入力します。

  6. ID プロバイダーの token-exchange パーミッションに戻り、定義したクライアントポリシーを追加します。

    図12.12 クライアントポリシーの適用

    クライアントポリシーの適用
    View larger image
    クライアントポリシーの適用

これでクライアントを呼び出すパーミッションがある。これを正しく行わないと、エクスチェンジを作成しようとすると、403 Forbidden 応答が返されます。

12.2.3.2. リクエストの作成
リンクのコピー

クライアントが既存の内部トークンを外部に交換する場合には、requested_issuer パラメーターを指定します。このパラメーターは、設定済みのアイデンティティープロバイダーのエイリアスである必要があります。 

curl -X POST \
    -d "client_id=starting-client" \
    -d "client_secret=the client secret" \
    --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
    -d "subject_token=...." \
    --data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:access_token" \
    -d "requested_issuer=google" \
    http://localhost:8080/realms/myrealm/protocol/openid-connect/token
Copy to Clipboard Toggle word wrap

subject_token パラメーターは、ターゲットレルムのアクセストークンである必要があります。requested_token_type パラメーターは urn:ietf:params:oauth:token-type:access_token であるか、空欄のままにする必要があります。現時点では、他の要求されたトークンタイプはサポートされません。以下は、この呼び出しから返される正常な JSON レスポンスの例です。 

{
   "access_token" : "....",
   "expires_in" : 3600
   "account-link-url" : "https://...."
}
Copy to Clipboard Toggle word wrap

何らかの理由で外部アイデンティティープロバイダーがリンクされていない場合は、次の JSON ドキュメントを含む HTTP 400 レスポンスコードが返されます。 

{
   "error" : "....",
   "error_description" : "..."
   "account-link-url" : "https://...."
}
Copy to Clipboard Toggle word wrap

error クレームは、token_expired または not_linked のいずれかになります。クライアントが クライアント起点のアカウントリンク を実行できるように、account-link-url クレームが提供されます。ほとんど (あるいはすべて) のプロバイダーでは、ブラウザー OAuth プロトコルを使用したリンクが必要です。account-link-url では、単に redirect_uri クエリーパラメーターを追加し、ブラウザーに転送してリンクを実行できます。

12.2.4. 外部トークンから内部トークンへの交換
リンクのコピー

内部トークンの外部 ID プロバイダーが作成した外部トークンを信頼し、交換できます。これはレルム間をブリッジしたり、ソーシャルプロバイダーからのトークンを信頼したりするために使用できます。新しいユーザーが存在しない場合はレルムにインポートされるという点で、ID プロバイダーのブラウザーログインと同様に機能します。

注記

外部トークン交換に関する現在の制限として、外部トークンが既存のユーザーにマップされている場合、既存のユーザーが外部 ID プロバイダーへのアカウントリンクをすでに持っていない限り、交換が許可されない点があります。

交換が完了すると、レルム内にユーザーセッションが作成され、requested_token_type パラメーターの値に応じてアクセストークンおよび更新トークンが送信されます。この新しいユーザーセッションは、タイムアウトするまで、またはこの新しいアクセストークンを渡すレルムのログアウトエンドポイントを呼び出すまで、アクティブなままである点に注意してください。

これらのタイプの変更には、管理コンソールで設定済みのアイデンティティープロバイダーが必要でした。

注記

SAML アイデンティティープロバイダーは現時点ではサポートされていません。Twitter トークンも交換できません。

12.2.4.1. 交換のための権限付与
リンクのコピー

外部トークン交換を行う前に、呼び出し元のクライアントに交換を行うためのパーミッションを与えます。このパーミッションは、内部から外部へのパーミッションが付与される 方法と同じ方法で付与されます。

呼び出し以外のクライアントを参照する値を持つ audience パラメーターを指定する場合、audience パラメーターに固有のターゲットクライアントに交換するための呼び出しクライアントのパーミッションも付与する必要があります。これを行う方法は、このセクションで すでに説明 されています。

12.2.4.2. リクエストの作成
リンクのコピー

subject_token_type は、urn:ietf:params:oauth:token-type:access_token または urn:ietf:params:oauth:token-type:jwt のいずれかである必要があります。タイプが urn:ietf:params:oauth:token-type:access_token の場合は、subject_issuer パラメーターを指定する必要があります。これは設定された ID プロバイダーのエイリアスです。タイプが urn:ietf:params:oauth:token-type:jwt の場合、プロバイダーは JWT 内の iss (発行者) クレームを介して照合されます。このクレームは、プロバイダーのエイリアスであるか、プロバイダーの設定内に登録された発行者である必要があります。

検証のために、トークンがアクセストークンである場合、プロバイダーのユーザー情報サービスが呼び出されてトークンが検証されます。呼び出しに成功すると、アクセストークンが有効であることを意味します。サブジェクトトークンが JWT であり、プロバイダーで署名検証が有効になっている場合は、それが試行されます。それ以外の場合は、デフォルトでユーザー情報サービスも呼び出してトークンを検証します。

デフォルトでは、作成された内部トークンは、呼び出し元のクライアントを使用して、呼び出し元のクライアント用に定義されたプロトコルマッパーを使用してトークンの内容を判別します。または、audience パラメーターを使用して別のターゲットクライアントを指定することもできます。 

curl -X POST \
    -d "client_id=starting-client" \
    -d "client_secret=the client secret" \
    --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
    -d "subject_token=...." \
    -d "subject_issuer=myOidcProvider" \
    --data-urlencode "subject_token_type=urn:ietf:params:oauth:token-type:access_token" \
    -d "audience=target-client" \
    http://localhost:8080/realms/myrealm/protocol/openid-connect/token
Copy to Clipboard Toggle word wrap

requested_token_type パラメーターがリフレッシュトークンタイプである場合、応答にはアクセストークン、リフレッシュトークン、および有効期限が含まれます。以下は、この呼び出しから返される JSON 応答の例です。 

{
   "access_token" : "....",
   "refresh_token" : "....",
   "expires_in" : 3600
}
Copy to Clipboard Toggle word wrap

12.2.5. 権限借用
リンクのコピー

内部トークンと外部トークン交換の場合、クライアントは、ユーザーに代わって別のユーザーになりすますように要求できます。たとえば、サポートエンジニアが問題をデバッグできるように、ユーザーになりすます必要のある管理アプリケーションがある場合などです。

注記

ここで説明するなりすましのシナリオは impersonation concept of the token exchange specification とは異なります。仕様では、トークンサブジェクトになりすまして、別のサブジェクトとして動作させるサポートはありません。つまり、この仕様は、「ユーザーのなりすまし」ではなく「クライアントのなりすまし」です。

12.2.5.1. 交換のための権限付与
リンクのコピー

サブジェクトトークンが表すユーザーには、他のユーザーの権限を借用するための権限が必要です。この権限を有効にする方法は、サーバー管理ガイド を参照してください。これは、ロールまたは粒度の細かい管理者権限を介して実行できます。

12.2.5.2. リクエストの作成
リンクのコピー

requested_subject パラメーターを追加で指定しない限り、他の章の説明どおりに要求を行います。このパラメーターの値は、ユーザー名またはユーザー ID である必要があります。 

curl -X POST \
    -d "client_id=starting-client" \
    -d "client_secret=the client secret" \
    --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
    -d "subject_token=...." \
    --data-urlencode "requested_token_type=urn:ietf:params:oauth:token-type:access_token" \
    -d "audience=target-client" \
    -d "requested_subject=wburke" \
    http://localhost:8080/realms/myrealm/protocol/openid-connect/token
Copy to Clipboard Toggle word wrap

12.2.6. ダイレクトの Naked Impersonation
リンクのコピー

subject_token を指定せずに内部トークン交換要求を行うことができます。これは、クライアントがレルム内の任意のユーザーになりすますことができるため、クライアントに多くの信頼を置くことから、ダイレクトの Naked Impersonation と呼ばれます。交換するサブジェクトトークンを取得できないアプリケーションをブリッジするために、これが必要になる場合があります。たとえば、LDAP と直接ログインを実行するレガシーアプリケーションを統合している場合があります。この場合、レガシーアプリケーションはユーザー自身を認証できますが、トークンを取得することはできません。

警告

クライアントにダイレクトの Naked Impersonation を有効にすることは非常に危険です。クライアントの認証情報が盗まれた場合、そのクライアントは、システム内の任意のユーザーになりすますことができます。

12.2.6.1. 交換のための権限付与
リンクのコピー

audience パラメーターを指定すると、呼び出し元のクライアントにはクライアントへの交換パーミッションが必要です。これを設定する方法は、この章の前半で説明しています。

さらに、呼び出し元のクライアントには、ユーザーになりすますためのアクセス許可を付与する必要があります。

手順

  1. メニューの Users をクリックします。

  2. Permissions タブをクリックします。

    図12.13 ユーザー権限

    ユーザー権限
    View larger image
    ユーザー権限

  3. Permissions Enabled を On に切り替えます。

    図12.14 アイデンティティープロバイダーの権限

    ユーザーのなりすましパーミッションセット
    View larger image
    ユーザーのなりすましパーミッションセット

    ページには、impersonate リンクが表示されます。

  4. そのリンクをクリックして、パーミッションの定義を開始します。

    このセットアップページが表示されます。

    図12.15 ユーザーのなりすましパーミッションの設定

    ユーザーのなりすましパーミッションの設定
    View larger image
    ユーザーのなりすましパーミッションの設定
  5. 画面上部のブレッドクラムで Client details をクリックします。
  6. このパーミッションのポリシーを定義します。

  7. Policies タブに移動し、クライアントポリシーを作成します。

    図12.16 クライアントポリシーの作成

    クライアントポリシーの作成
    View larger image
    クライアントポリシーの作成
  8. トークン交換を要求する認証されたクライアントである、開始クライアントを入力します。

  9. ユーザーの impersonation パーミッションに戻り、定義したクライアントポリシーを追加します。

    図12.17 クライアントポリシーの適用

    クライアントポリシーの適用
    View larger image
    クライアントポリシーの適用

クライアントには、ユーザーの権限を借用できるパーミッションがあります。これを正しく行わないと、このタイプの交換を行おうとすると、403 Forbidden 応答が返されます。

注記

パブリッククライアントは、ダイレクトの Naked Impersonation を行うことはできません。

12.2.6.2. リクエストの作成
リンクのコピー

要求を行うには、requested_subject パラメーターを指定します。これは、有効なユーザーのユーザー名またはユーザー ID である必要があります。必要に応じて、audience パラメーターを指定することもできます。 

curl -X POST \
    -d "client_id=starting-client" \
    -d "client_secret=the client secret" \
    --data-urlencode "grant_type=urn:ietf:params:oauth:grant-type:token-exchange" \
    -d "requested_subject=wburke" \
    http://localhost:8080/realms/myrealm/protocol/openid-connect/token
Copy to Clipboard Toggle word wrap

12.2.7. サービスアカウントでアクセス許可モデルを展開
リンクのコピー

クライアントに交換のパーミッションを与える場合、必ずしもすべてのクライアントに対してそれらのパーミッションを手動で有効にしません。クライアントにサービスアカウントが関連付けられている場合、ロールを使用してパーミッションをグループ化し、クライアントのサービスアカウントにロールを割り当てることで交換パーミッションを割り当てることができます。たとえば、naked-exchange ロールと、そのロールを持つサービスアカウントが、そのままの交換を実行できるように定義することができます。

12.2.8. 交換の脆弱性
リンクのコピー

トークン交換を許可し始める際に、認識し、注意しなければならないさまざまなことがあります。

1 つ目はパブリッククライアントです。パブリッククライアントは、交換を実行するためのクライアント認証情報を持っていないか、これを必要としません。有効なトークンを持っていれば、誰でもパブリッククライアントに なりすまし て、そのパブリッククライアントが許可されている処理を実行できてしまいます。レルムが管理するクライントで信頼できないクライアントが存在する場合、パブリッククライアントはパーミッションモデルに脆弱性を開放する可能性があります。この理由により、ダイレクトの Naked 交換は、パブリッククライアントを許可せず、呼び出し元のクライアントがパブリックの場合にエラーを表示して中止します。

Facebook や Google などが提供するソーシャルトークンをレルムトークンと交換することができます。これらのソーシャル Web サイトで、偽のアカウントを作成することは難しくないため、交換トークンで許可されていることには注意し、慎重に対応してください。デフォルトの Role、Group、およびアイデンティティープロバイダーマッパーを使用して、外部のソーシャルユーザーに割り当てられた属性とロールを制御します。

ダイレクトの Naked の交換は非常に危険です。クライアントの認証情報をリークしない呼び出し元のクライアントに多大な信頼を置いています。これらの認証情報がリークされる場合、盗む側はシステム内の誰かになりすますことができます。これは、既存のトークンを持つ機密クライアントと直接対照的です。認証には、アクセストークンとクライアント認証情報の 2 つの要素があり、1 人のユーザーのみを処理します。したがって、ダイレクトの Naked の交換は控えめに使用してください。

トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat