内部ユーザーに対する認証の概要

認証には、認証情報と権限が含まれています。内部ユーザーの認証情報（ベアラートークン認証を使用）は JWT 内に指定されており、これらの JWT からの情報がログに記録されます。

認証情報

内部ユーザーの認証情報は、ユーザー名とパスワードで構成されています。この情報は、IdP に保存されています。

内部ユーザーが API 呼び出しを行うと、呼び出し元アプリケーションがユーザーの認証情報を Guidewire Hub に送信します。Guidewire Hub は、この情報を適切な IDP に連携します。IDP は、パスワードが正しいことを確認してユーザーを認証します。

IDP のコンフィギュレーション方法の詳細については、IDP のコンフィギュレーションを参照してください。

承認

内部ユーザーのエンドポイントアクセス権

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

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

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

内部ユーザーが（基本認証またはベアラートークン認証のいずれかを使用して）システム API 呼び出しを行う場合、ClaimCenter がこの内部ユーザーのユーザー役割について運用データベースにクエリを実行します。ユーザーに付与されるエンドポイントアクセス権は、すべての API 役割に対するアクセス権であり、当該 API 役割の名前はユーザーのユーザー役割の名前に対応します。

例えば、Andy Applegate さんは内部ユーザーであり、2 つのユーザー役割（Adjuster と Reinsurance Manager）を持つと仮定します。Andy Applegate さんがシステム API 呼び出しをトリガします。API 呼び出しを受信すると、ClaimCenter は Andy Applegate さんのユーザー役割についてデータベースにクエリを実行します。Adjuster と Reinsurance Manager の 2 つのユーザー役割が返されます。 ClaimCenter によって、API 役割（名前は Adjuster と Reinsurance Manager）で定義されたエンドポイントアクセス権が、Andy Applegate さんに付与されます。

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

内部ユーザーのリソースアクセス権

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

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

リソースアクセス戦略は一連のロジックであり、リソースアクセス ID の意味を特定します。ベースコンフィギュレーションには、内部ユーザーに対する以下のリソースアクセス戦略が含まれています。

戦略名 この戦略を使用するペルソナ リソースアクセス ID の前提事項 アクセスが許可される対象
cc_username 内部ユーザー ClaimCenter ユーザー名 当該内部ユーザーが関連付けられたアクセス制御リスト（ACL）に基づいて ClaimCenter で内部ユーザーが表示できる情報。

内部ユーザーがシステム API 呼び出しを実行すると、JWT にはそのユーザーのユーザー名が含まれます。そのユーザー名は、リソースアクセス ID として使用されます。cc_username または pc_username の戦略が自動的に使用されます。ベースコンフィギュレーションのアクセス制御リスト（ACL）で定義されているように、ユーザーのアクセス権に可能な限り密接に一致するシステム API ロジックで、この戦略は構成されています。

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

内部ユーザーのプロキシユーザーアクセス権

プロキシユーザーのアクセス権は内部ユーザーには適用されません。

内部ユーザーの JWT

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

内部ユーザーの JWT には、以下のトークンクレームを含めることができます。

  • scp：リソースアクセス ID に適用するリソースアクセス戦略（内部ユーザーの場合、これは cc_username に設定されます）
  • cc_username：リソースアクセス ID（これはユーザーのユーザー名です）

例えば、以下の JWT はユーザー名が aapplegate の内部ユーザーに対するものです（システム API の権限に関係ない情報は削除されています）。

{
    "scp": [
        "cc_username"
    ],
    "cc_username": "aapplegate"
}

次の点に注目します。

  • scp トークンクレームに基づいて、呼び出し元のリソースアクセス ID はユーザー名として解釈されます。
  • cc_username トークンクレームに基づいて、この呼び出し元が持つアクセス権は、aapplegate ユーザーがアクセスできるものに関連する情報へのアクセス権です。

ログ

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

フィールド 値
sub JWT からの sub トークンクレームの値
clientId JWT からの cid トークンクレームの値
user 内部ユーザーのユーザー名