内部ユーザーのフローの例

下図は、内部ユーザーの認証情報と権限情報のフローを示しています。色は以下のように使用されます。

  • オレンジ：認証情報
  • 青：エンドポイントのアクセス権情報
  • 緑：リソースのアクセス権情報
  • 赤：プロキシユーザーとセッションユーザーの情報

いくつかの値を使用して、複数の種類のアクセスを決定します。これらの値は最初（1 つの種類のアクセスに適用されていない場合）は黒で表示されてから、1 つ以上の特定の色（特定の種類のアクセスに対してプロセスのその時点で使用されていることを値が反映する）で表示されます。

以下の例では、API 呼び出しが Andy Applegate 担当者によってトリガされています。ブラウザベースのアプリケーションを使用している内部ユーザーです。


内部ユーザーの認証フロー
  1. 担当者が API 呼び出しをトリガすると、呼び出し元アプリケーションは最初に Guidewire Hub に JWT を要求します。JWT を入手するプロセスを開始するために、呼び出し元アプリケーションはそのクライアント ID（00ubx7m33sHP1tsew7b4）、IdP の ID（acmeIdP_ID）、そのアプリケーションのリソースアクセス戦略（cc.username）、および追加のデプロイ情報（tenant.acme、project.default、planet_class.prod）を送信します。
  2. ユーザーを認証するために、Guidewire Hub は、ユーザー名（aapplegate@acme.com）とパスワード（aPassword）を、何らかの種類のログイン画面で取得します。そして、この情報を適切な IDP に送信します。IDP は、ユーザーを認証し、そのユーザー名（aapplegate@acme.com）を含む SAML 応答を提供します。
  3. Guidewire Hub が、コードを呼び出し元アプリケーションに送信します。呼び出し元アプリケーションは、このコードを使用して JWT を要求します。
  4. Guidewire Hub が JWT を生成して呼び出し元アプリケーションに送信します。クライアント ID（cid）、リソースアクセス戦略（cc_username）と追加のデプロイ情報を指定する scp トークンクレーム、およびユーザーのリソースアクセス ID（aapplegate@acme.com）を指定する cc_username トークンが、この JWT に含まれています。
  5. 呼び出し元アプリケーションは、JWT とともに API 要求を ClaimCenter に送信します。
  6. ClaimCenter によって、エンドポイントのアクセス権が決定されます。
    1. ClaimCenter は、JWT 内のユーザー名（aapplegate@acme.com）を使用して、このユーザーが持っているユーザーの役割についてクエリを実行します。Adjuster の役割が 1 つ返されます。
    2. 返された役割に基づいて、Adjuster.role.yaml の API 役割ファイルが使用されて、エンドポイントのアクセス権が定義されます。
  7. 次に、ClaimCenter によって、リソースアクセス戦略が決定されます。そして、JWT（cc_username）内のリソースアクセス戦略値に基づいて、internal access.yaml ファイルでの定義に従ってリソースアクセス権が付与されます（* ClaimCenter は internal_ext-1.0.access.yaml から始まりますが、このファイルは別の access.yaml ファイルを参照します。それらの名前は internal で始まります）。
  8. プロキシユーザーのアクセス権は内部ユーザーには関係ありません。
  9. ClaimCenter によって要求が処理されます。
    1. セッションユーザーは、内部ユーザーの aapplegate@acme.com です。
    2. エンドポイントのアクセス権は Adjuster.role.yaml によって定義されます。
    3. リソースのアクセス権は、aapplegate@acme.com のリソースアクセス ID を使用して internal access.yaml によって定義されます。
  10. ClaimCenter によって、最初の呼び出しに対する応答が渡されます。