サービスアカウントマッピング付きサービスに対するフローの例

下図は、サービスアカウントマッピング付きサービスの認証情報と権限情報のフローを示しています。色は以下のように使用されます。

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

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

以下の例では、API 呼び出しが Acme FNOLReporter によってトリガされています。


サービスアカウントマッピング付きサービスに対する認証フロー
  1. FNOLReporter が API 呼び出しをトリガすると、最初に Guidewire Hub に JWT を要求します。JWT の要求には、クライアント ID（0oaqt9pl1vZK1kybt0h7）、シークレット（aSecret）、および追加のデプロイ情報（tenant.acme、project.default、planet_class.prod）が含まれています。
  2. Guidewire Hub が、クライアント ID およびシークレットに基づいてサービスを認証します。
  3. Guidewire Hub が JWT を生成してサービスに送信します。この JWT には、クライアント ID（cid）および追加のデプロイ情報が含まれています。
  4. サービスが、JWT とともに API 要求を ClaimCenter に送信します。
  5. ClaimCenter によって、エンドポイントのアクセス権が決定されます。
    1. 最初に、クライアント ID（0oaqt9pl1vZK1kybt0h7）をサービスアカウント名（acmeFNOLuser）にマッピングする検索が、ClaimCenter によって実行されます。
    2. 次に、このアカウント名が持っているユーザー役割のクエリが、ClaimCenter によって実行されます。1 つの役割が返されます。acme_fnolreporter です。
    3. 返された役割に基づいて、acme_fnolreporter.role.yaml の API 役割ファイルを使用してエンドポイントアクセス権が決定されます。
  6. 次に、ClaimCenter によって、リソースアクセス戦略が決定されます。サービスアカウントの検索で有効なサービスアカウントが見つかった場合、internal access.yaml ファイルでの定義に従って、リソースアクセス権が ClaimCenter によって付与されます（* ClaimCenter は internal_ext-1.0.access.yaml から始まりますが、このファイルは別の access.yaml ファイルを参照します。それらの名前は internal で始まります）。
  7. サービスアカウントマッピング付きサービスにはプロキシユーザーアクセス権は関係がありません。
  8. ClaimCenter によって要求が処理されます。
    1. セッションユーザーは、サービスアカウントの acmeFNOLuser です。
    2. エンドポイントアクセス権は、acme_fnolreporter.role.yaml によって定義されます。
    3. リソースのアクセス権は、acmeFNOLuser のリソースアクセス ID を使用して internal access.yaml によって定義されます。
  9. ClaimCenter によって、最初の呼び出しに対する応答が渡されます。