ユーザーコンテキスト付きサービスのフローの例

下図は、ユーザーコンテキスト付きサービスの認証情報と権限情報のフローを示します。色は以下のように使用されます。

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

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

ユーザーコンテキスト付きサービス：内部ユーザー

以下の例では、内部ユーザーである Andy Applegate さんの代わりに Acme FNOLReporter サービスによって API 呼び出しがトリガされています。


内部ユーザーのコンテキスト付きサービスの認証フロー
  1. FNOLReporter が API 呼び出しをトリガすると、最初に Guidewire Hub に JWT を要求します。JWT の要求に含まれる内容は、クライアント ID（0oaqt9pl1vZK1kybt0h7）、シークレット（aSecret）、アプリケーションの API 役割（scp.cc.acme_fnolreporter）、アプリケーションのリソースアクセス戦略（cc.service）、呼び出しがユーザーのために行われる事実（cc.allowusercontext）、および追加のデプロイ情報（tenant.acme、project.default、planet_class.prod）です。
  2. Guidewire Hub が、クライアント ID およびシークレットに基づいてサービスを認証します。また、要求で渡された API 役割とリソースアクセス戦略が、Guidewire Hub でのサービス登録時に指定した内容と一致することも確認します。
  3. Guidewire Hub が JWT を生成してサービスに送信します。この JWT に含まれる内容は、クライアント ID（cid）と scp トークンクレームです。これにより、API 役割（scp.cc.acme_fnolreporter）、リソースアクセス戦略（cc.service）、cc.allowusercontext 値（ユーザー情報が追加のユーザーコンテキストヘッダーに指定されていることを示す）、および追加のデプロイ情報が指定されます。
  4. サービスによって、API 要求が ClaimCenter に、JWT およびユーザーコンテキストヘッダーとともに送信されます。ユーザーコンテキストヘッダーによって、ユーザー（aapplegate@acme.com）、ユーザーのリソースアクセス戦略（cc_username）、およびリソースアクセス ID（aapplegate@acme.com）が特定されます。
  5. ClaimCenter が、サービスレベルとユーザーレベルの両方のエンドポイントアクセス権を決定する必要があります。最初はサービスレベルです。JWT（scp.cc.acme_fnolreporter）の API 役割値に基づいて、acme_fnolreporter.role.yaml の API 役割ファイルが使用され、サービスレベルのアクセス権が定義されます。
  6. 次に、ClaimCenter によってユーザーレベルのエンドポイントアクセス権が決定されます。
    1. ユーザーコンテキストヘッダー（aapplegate@acme.com）のユーザー名を使用して、このユーザーが持っているユーザー役割について ClaimCenter がクエリを実行します。Adjuster の役割が 1 つ返されます。
    2. 返された役割に基づいて、Adjuster.role.yaml の API 役割ファイルが使用されて、ユーザーレベルのアクセス権が定義されます。
  7. ClaimCenter は、サービスレベルとユーザーレベルのリソースアクセス権を決定する必要もあります。サービスレベルのリソースアクセス戦略から始めます。JWT（cc.service）内のリソースアクセス戦略値に基づいて、serviceUser access.yaml ファイルでの定義に従ってサービスレベルのリソースアクセス権が付与されます（* ClaimCenter は serviceUser_ext-1.0.access.yaml から始まりますが、このファイルは別の access.yaml ファイルを参照します。それらの名前は serviceUser で始まります）。
  8. ClaimCenter によって、ユーザーレベルのリソースアクセス戦略が決定されます。ユーザーコンテキストヘッダー（cc_username）内のリソースアクセス戦略値に基づいて、internal access.yaml ファイルでの定義に従ってユーザーレベルのリソースアクセス権が付与されます（* ClaimCenter は internal_ext-1.0.access.yaml から始まりますが、このファイルは別の access.yaml ファイルを参照します。それらの名前は internal で始まります）。
  9. ユーザーが内部ユーザーである場合、プロキシユーザーアクセス権は、ユーザーコンテキスト付きサービスには関係がありません。
  10. ClaimCenter によって要求が処理されます。
    1. セッションユーザーは、内部ユーザーの aapplegate@acme.com です。
    2. エンドポイントアクセス権で共通する部分のエンドポイントと操作は、サービスレベル（acme_fnolreporter.role.yaml）とユーザーレベル（Adjuster.role.yaml）で付与されると定義されます。エンドポイント、操作、およびフィールドを呼び出しで使用できるためには、両方のレベルでリストされている必要があります。
    3. リソースアクセス権で共通する部分のリソースは、サービスでアクセスできるリソース（serviceUser access.yaml で定義される）と、ユーザーが使用できるリソース（internal access.yaml で aapplegate@acme.com のリソースアクセス ID を使用して定義される）です。ベースコンフィギュレーションでは、serviceuser access.yaml ファイルによってすべてのリソースが使用できます。そのため、論理的に言えば、サービスレベルのリソースアクセス権では制限は指定されません。呼び出しでは、ユーザーレベルのリソースアクセス権で使用できる限り、どのリソースにもアクセスできます。
  11. ClaimCenter によって、最初の呼び出しに対する応答が渡されます。

ユーザーコンテキスト付きサービス：外部ユーザー

以下の例では、外部ユーザーである Ray Newton さんの代わりに Acme FNOLReporter サービスによって API 呼び出しがトリガされています。


外部ユーザーのコンテキスト付きサービスの認証フロー
  1. FNOLReporter が API 呼び出しをトリガすると、最初に Guidewire Hub に JWT を要求します。JWT の要求に含まれる内容は、クライアント ID（0oaqt9pl1vZK1kybt0h7）、シークレット（aSecret）、アプリケーションの API 役割（scp.cc.acme_fnolreporter）、アプリケーションのリソースアクセス戦略（cc.service）、呼び出しがユーザーのために行われる事実（cc.allowusercontext）、および追加のデプロイ情報（tenant.acme、project.default、planet_class.prod）です。
  2. Guidewire Hub が、クライアント ID およびシークレットに基づいてサービスを認証します。また、要求で渡された API 役割とリソースアクセス戦略が、Guidewire Hub でのサービス登録時に指定した内容と一致することも確認します。
  3. Guidewire Hub が JWT を生成してサービスに送信します。この JWT に含まれる内容は、クライアント ID（cid）と scp トークンクレームです。これにより、API 役割（scp.cc.acme_fnolreporter）、リソースアクセス戦略（cc.service）、cc.allowusercontext 値（ユーザー情報が追加のユーザーコンテキストヘッダーに指定されていることを示す）、および追加のデプロイ情報が指定されます。
  4. サービスによって、API 要求が ClaimCenter に、JWT およびユーザーコンテキストヘッダーとともに送信されます。ユーザーコンテキストヘッダーによって、ユーザー（rnewton@email.com）、ユーザーのリソースアクセス戦略（cc_policyNumbers）、およびリソースアクセス ID（PA-123456）が特定されます。
  5. ClaimCenter が、サービスレベルとユーザーレベルの両方のエンドポイントアクセス権を決定する必要があります。最初はサービスレベルです。JWT（scp.cc.acme_fnolreporter）の API 役割値に基づいて、acme_fnolreporter.role.yaml の API 役割ファイルが使用され、サービスレベルのアクセス権が定義されます。
  6. 次に、ClaimCenter によってユーザーレベルのエンドポイントアクセス権が決定されます。ユーザーコンテキストヘッダー（gwa.prod.cc.Insured）で groups トークンクレームの内容に基づいて、Insured.role.yaml の API 役割ファイルが使用されてユーザーレベルのアクセス権が定義されます。
  7. ClaimCenter は、サービスレベルとユーザーレベルののリソースアクセス権を決定する必要もあります。サービスレベルのリソースアクセス戦略から始めます。JWT（cc.service）のリソースアクセス戦略値に基づいて、serviceUser access.yaml ファイルでの定義に従って ClaimCenter によってサービスレベルのリソースアクセス権が付与されます（* ClaimCenter は serviceUser_ext-1.0.access.yaml から始まりますが、このファイルは別の access.yaml ファイルを参照します。それらの名前は serviceUser で始まります）。
  8. 次に、ClaimCenter によって、リソースアクセス戦略が決定されます。ユーザーコンテキストヘッダー（cc_policyNumbers）内のリソースアクセス戦略値に基づいて、policyNumbers access.yaml ファイルでの定義に従ってユーザーレベルのリソースアクセス権が付与されます（* ClaimCenter は policyNumbers_ext-1.0.access.yaml から始まりますが、このファイルは別の access.yaml ファイルを参照します。それらの名前は policyNumbers で始まります）。
  9. セッションに割り当てるプロキシユーザーを決定するために、ClaimCenter は RestAuthenticationSourceCreator プラグインを呼び出します。ユーザーコンテキストヘッダーでは cc_policyNumbers のリソースアクセス戦略が指定されます。それにより、プラグインは、外部ユーザー用プロキシユーザーの extuser を返します。
  10. ClaimCenter によって要求が処理されます。
    1. セッションユーザーは、プロキシ外部ユーザーの extuser です。
    2. エンドポイントアクセス権で共通する部分のエンドポイントと操作は、サービスレベル（acme_fnolreporter.role.yaml）とユーザーレベル（Insured.role.yaml）で付与されると定義されます。エンドポイント、操作、およびフィールドを呼び出しで使用できるためには、両方のレベルでリストされている必要があります。
    3. リソースアクセス権で共通する部分のリソースは、サービスでアクセスできるリソース（serviceUser access.yaml で定義される）と、ユーザーが使用できるリソース（policyNumbers access.yaml で PA-123456 のリソースアクセス ID を使用して定義される）です。ベースコンフィギュレーションでは、serviceuser access.yaml ファイルによってすべてのリソースが使用できます。そのため、論理的に言えば、サービスレベルのリソースアクセス権では制限は指定されません。呼び出しでは、ユーザーレベルのリソースアクセス権で使用できる限り、どのリソースにもアクセスできます。
  11. ClaimCenter によって、最初の呼び出しに対する応答が渡されます。