スタンドアロン型サービスのフローの例

下図は、スタンドアロン型サービスの認証情報と権限情報のフローを示しています。色は以下のように使用されます。

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

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

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


スタンドアロン型サービスの認証フロー
  1. FNOLReporter が API 呼び出しをトリガすると、最初に Guidewire Hub に JWT を要求します。JWT に対する要求には、クライアント ID（0oaqt9pl1vZK1kybt0h7）、シークレット（aSecret）、アプリケーションの API の役割（scp.cc.acme_fnolreporter）、アプリケーションのリソースアクセス戦略（cc.service）、および追加のデプロイ情報（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）、および追加のデプロイ情報が指定されます。
  4. サービスが、JWT とともに API 要求を ClaimCenter に送信します。
  5. ClaimCenter によって、エンドポイントのアクセス権が決定されます。JWT（scp.cc.acme_fnolreporter）にリストされた scp.cc. 値に基づいて、acme_fnolreporter.role.yaml の API 役割ファイルが使用され、エンドポイントアクセス権が定義されます。
  6. 次に、ClaimCenter によって、リソースアクセス戦略が決定されます。JWT（cc.service）内のリソースアクセス戦略値に基づいて、serviceUser access.yaml ファイルでの定義に従って、リソースアクセス権が付与されます（* ClaimCenter は serviceUser_ext-1.0.access.yaml から始まりますが、このファイルは別の access.yaml ファイルを参照します。それらの名前は serviceUser で始まります）。
  7. セッションに割り当てるプロキシユーザーを決定するために、ClaimCenter は RestAuthenticationSourceCreator プラグインを呼び出します。JWT では cc.service のリソースアクセス戦略が指定されています。それにより、プラグインは、サービス用プロキシユーザーの serviceuser を返します。
  8. ClaimCenter によって要求が処理されます。
    1. セッションユーザーは、プロキシサービスユーザーの serviceuser です。
    2. エンドポイントアクセス権は、acme_fnolreporter.role.yaml によって定義されます。
    3. リソースアクセス権は、serviceUser access.yaml によって定義されます。ベースコンフィギュレーションでは、serviceuser access.yaml ファイルによってすべてのリソースが使用できます。したがって、論理的に言えば、リソースアクセスの制限はありません。
  9. ClaimCenter によって、最初の呼び出しに対する応答が渡されます。