スタンドアロン型サービスに対する認証の概要

認証には、認証情報と権限が含まれています。サービスの認証情報は JWT 内に指定されており、これらの JWT からの情報がログに記録されます。

認証情報

サービスによって API 呼び出しが行われると、サービスによってクライアント ID およびシークレットが Guidewire Hub に送信されます。Guidewire Hub でクライアントシークレットが正しいことを確認して、サービスを認証します。これは、スタンドアロン型サービス、ユーザーコンテキスト付きサービス、およびサービスアカウントマッピング付きサービスの場合に当てはまります。

Guidewire Hub でのクライアント ID およびシークレットの登録方法の詳細については、Guidewire Hub への呼び出し元アプリケーションの登録を参照してください。

承認

スタンドアロン型サービスに対するエンドポイントアクセス権

エンドポイントのアクセス権では、呼び出し元で使用できるエンドポイントの動作のさまざまな側面を定義します。これには、以下が含まれます。

  • 呼び出し元が使用できるエンドポイントとリソースの種類。
  • 呼び出し元が使用可能なエンドポイントで呼び出せる操作。
  • 呼び出し元が要求ペイロードで指定できたり応答ペイロードで取得できるフィールド。

エンドポイントアクセス権は API 役割によって制御されます。API 役割は、エンドポイント、操作、およびフィールドのリストであり、API 呼び出しで一連の呼び出し元が使用できます。API 役割は、許可リストとして機能します。デフォルトでは、呼び出し元はエンドポイントのアクセス権を持っていません。呼び出し元が 1 つ以上の API 役割と関連付けられている場合、それらの API 役割それぞれの許可リストに含まれているエンドポイント、操作、およびフィールドへのアクセス権を取得します。

理論的には、スタンドアロン型サービスは、複数の API 役割と関連付けることができます。通常、保険会社はサービスごとに 1 つの API 役割を作成し、その役割はそのサービスによってのみ使用されます。

スタンドアロン型サービス呼び出しでは、そのサービスに割り当てられている API 役割が 1 つ以上、システム API によって確認されます。それらの役割で指定されているエンドポイント、操作、およびフィールドへのアクセス権を呼び出しは付与されます。例えば、ACME External Document Manager サービスが、以下のエンドポイントアクセス権を持つ以下の API 役割を持っているとします。

  • acme_externaldocumentmanager
    • GET /documents
    • POST /documents

次に、ACME External Document Manager サービスがスタンドアロン型サービスを行うとします。その呼び出しは、GET /documents および POST /documents へのアクセス権を付与されます。ただし、DELETE /documents エンドポイントがある場合、その呼び出しはアクセス権を付与されません。acme_externaldocumentmanager の役割で指定されていないからです。

API 役割のコンフィギュレーション方法の詳細については、エンドポイントアクセス権を参照してください。

スタンドアロン型サービスに対するリソースアクセス権

リソースのアクセス権では、特定の種類のリソースに対して呼び出し元がアクセスできるインスタンスを定義します。例えば、保険契約者、引受担当者、担当者、およびサービス業者が使用できる GET /claims エンドポイントがあるとします。これらの呼び出し元はすべて、種類が claim のリソースにアクセスするためにエンドポイントを使用できますが、呼び出し元のいずれもすべてのクレームにはアクセスできません。次に例を示します。

  • 保険契約者は、保持する保険契約と関連するクレームのみを表示できます。
  • 引受担当者は、割り当てられた保険契約のクレームのみを表示できます。
  • 担当者は、割り当てられたクレームのみを表示できます。
  • サービス業者は、サービス要求が割り当てられたクレームのみを表示できます。

リソースアクセス戦略は一連のロジックであり、呼び出し元がアクセスできるリソースを特定します。ベースコンフィギュレーションには、スタンドアロン型サービスに対するリソースアクセス戦略が含まれています。ただし、これらの戦略には、リソースアクセス ID が含まれず、どのような方法でもサービスは制限されません。一度、サービスに一連のエンドポイントへのアクセス権が付与されると、そのサービスはそれらのエンドポイントで使用できるどのリソースにもアクセスできます。これらのアプリケーションは、状況に適したリソースにのみアクセスするようにコンフィギュレーションされることが想定されています。

戦略名 この戦略を使用するペルソナ リソースアクセス ID の前提事項 アクセスが許可される対象
cc.​service サービス 該当なし すべてのリソース

リソースアクセスの動作方法の詳細については、リソースアクセス権を参照してください。

スタンドアロン型サービスに対するプロキシユーザーアクセス権

すべての Cloud API 呼び出しは、セッションのコンテキスト内で行われます。ClaimCenter データベース内にリストされているユーザーを、このセッションにアタッチする必要があります。 ClaimCenter は、この「セッションユーザー」をさまざまな方法で使用できます。

  • 呼び出しによってオブジェクトが作成または変更される場合、そのセッションユーザーがそのオブジェクトの CreateUser または UpdateUser として記録されます。
  • 呼び出しによって、権限制限チェックがトリガされる場合、そのセッションユーザーの権限制限が確認されます。
  • 特定のドメインレベルのシステム権限(アクティビティを所有する権限など)を呼び出し元が持っているかどうかのチェックを行う必要があるロジックが、呼び出しでトリガされることはほとんどありません。しかし、トリガされた場合、セッションユーザーのシステム権限が確認されます。

「プロキシユーザー」はセッションに割り当てられる内部ユーザーですが、外部ユーザーやサービスによって行われた API 呼び出しに対して割り当てられます。プロキシユーザーは、RestAuthenticationSourceCreatorPlugin プラグインによって割り当てられます。このプラグインによって、4 人のプロキシユーザーが指定されます。それらの 1 人であるプロキシサービスユーザーは、スタンドアロン型サービスによって行われる呼び出しに対して使用されます。

  • 呼び出しによってオブジェクトが作成または変更される場合、プロキシサービスユーザーがオブジェクトの CreateUser または UpdateUser として記録されます。
  • 呼び出しによって権限制限またはドメインレベルのシステム権限がトリガされる場合、そのプロキシサービスユーザーの制限または権限が確認されます。

プロキシユーザーに関する詳細については、プロキシユーザーアクセスを参照してください。

スタンドアロン型サービスの JWT

JSON Web Tokens(JWT)には、トークンクレームが含まれています(標準 JWT 用語では、これらは単に「クレーム」と呼ばれます。損害保険におけるクレームとの混同を避けるため、このドキュメントでは、JWT クレームを「トークンクレーム」と呼びます)。トークンクレームは、ベアラーの名前などトークンのベアラーに関してアサートされた情報です。ベアラートークン認証の場合、認証情報はトークンクレームに保存されます。

サービスによってスタンドアロン型サービス呼び出しが行われる場合、Cloud API 認証に固有の情報は JWT 内の一部のみです。以下のトークンクレームは JWT にあり、スタンドアロン型サービス呼び出しに対するもので、Cloud API 認証に関係します。

"sub": "<clientId>",
"cid": "<clientId>", 
"scp": [
  "cc.service",
  "scp.cc.<serviceAPIRole>"
]
  • sub は、トークンのサブジェクトです。これは、サービスのクライアント ID に設定されます。
  • cid はサービスのクライアント ID です。これも、サービスのクライアント ID に設定されます。
  • scp トークンクレームには、少なくとも以下のエントリがあります。
    • cc.service 値:呼び出し元がサービスであることを指定します。
    • 1 つ以上の API 役割のリスト:API 役割はサービスに関連付けられています。これらの役割には scp.cc. の接頭辞が付いています。

例えば、以下の JWT は、ACME の外部事故受付報告者サービスに対するものです(Cloud API の権限に関係ない情報は削除されています)。

{
    "sub": "acme_externalfnolreporter",
    "cid": "acme_externalfnolreporter",
    "scp": [
        "cc.service",
        "scp.cc.acme_externalfnolreporter"
    ]
}

次の点に注目します。

  • scp トークンクレームに基づいて、acme_externalfnolreporter という名前の役割の定義に従って、エンドポイントアクセス権がこの呼び出し元に付与されます。cc.service エントリのために、すべてのリソースへのアクセス権を提供するリソースアクセス戦略をこの呼び出し元は使用します。

ログ

呼び出しごとに、呼び出し元に関する情報がログに記録されます。以下の表に記載されているフィールドの情報は、ログに記録された値の取得元と呼び出し元に関する情報です。

フィールド
sub JWT からの sub トークンクレームの値
clientId JWT からの cid トークンクレームの値
user 空の文字列