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

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

認証情報

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

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

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

承認

外部ユーザーに対するエンドポイントアクセス権

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

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

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

外部のユーザーがシステム API 呼び出しを実行すると、呼び出しに JWT が含まれています。1 つ以上の API 役割からなるリストが JWT に含まれています。ユーザーに付与されるエンドポイントアクセス権は、すべての API 役割に対するアクセス権であり、当該 API 役割の名前に対応する役割は JWT にリストされます。例えば、Ray Newton さんは保険契約者であるとします。Ray Newton さんがシステム API 呼び出しをトリガします。JWT によって Insured の役割が識別されます。Insured という名前の API 役割で定義されたエンドポイントアクセス権を Ray Newton さんは付与されます。

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

外部ユーザーのためのリソースのアクセス権

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

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

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


戦略名	この戦略を使用するペルソナ	リソースアクセス ID の前提事項	アクセスが許可される対象
`cc_policyNumbers`	アカウント名義人と保険契約者	保険証券番号の配列	いずれかの保険契約に関連付けられているクレームに関連する情報
`cc_gwabuid`	クレームサービス提供者	サービス提供者の連絡先の ABUID（アドレス帳の一意の識別子）	このユーザーにサービス提供者が割り当てられたクレームに関連する情報

外部ユーザーがシステム API 呼び出しを実行すると、ClaimCenter がリソースアクセストークンのクレームを確認します。

リソースアクセストークンが cc_policyNumbers である場合、リソースアクセス ID は保険証券番号のリストとして扱われます。それらの保険証券番号のすべてに基づいたすべてのクレームへのアクセス権をユーザーは付与されます。
リソースアクセストークンが cc_gwabuid である場合、リソースアクセス ID は、アドレス帳の識別子として扱われます。サービス提供者の少なくとも 1 つが ID を持つすべてのクレームへのアクセス権をユーザーは付与されます。

JWT が複数のリソースアクセス戦略トークンを持っていないことが Cloud API で必要です。

リソース戦略トークンが存在しない場合、呼び出し元には「デフォルト」リソースアクセス戦略が割り当てられます。このリソース戦略では、メタデータエンドポイントへのアクセス権のみが付与されます。
複数のリソース戦略トークンが存在する場合、呼び出しは拒否されます。

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

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

呼び出し元がシステム API 呼び出しを行うと、エンドポイントやリソースのアクセス権に無関係であるチェックが、内部 ClaimCenter ロジックによってトリガされる場合があります。次に例を示します。

呼び出し元が、自分自身へのアクティビティの割り当てを試みることがあります。 ClaimCenter で必要なチェックでは、アクティビティを所有するのに十分な権限を呼び出し元が持っているかどうかを調べます。
呼び出し元が、2000 ドルの支払を試みる場合があります。ClaimCenter では、支払額が呼び出し元の権限制限を超えていないかどうかをチェックする必要があります。

外部ユーザーは ClaimCenter 運用データベースにリストされていないため、当該ユーザーに結び付けられたシステム権限や権限制限を持っていません。これらのチェックを行うために、システム API はプロキシユーザーを利用します。プロキシユーザーは、API 呼び出し実行時に外部ユーザーやサービスに割り当てられる内部ユーザーです。呼び出し元が十分なアクセス権を持っているかどうかを調べるチェックを、内部の ClaimCenter ロジックが行う必要が生じるたびに、プロキシユーザーが確認されます。

プロキシユーザーのアクセス権の動作方法の詳細については、プロキシユーザーアクセスを参照してください。

外部ユーザーの JWT

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

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

groups：外部ユーザーに割り当てる API 役割。
- このトークンクレームでは、gwa.<planetclass>.<xc>. という接頭辞がグループ名に付きます。<planetclass> は prod、preprod、lower のいずれかに設定され、<xc> はアプリケーションコード（cc や pc など）に設定されます。
scp：リソースアクセス ID に適用するリソースアクセス戦略
cc_policyNumbers：リソースアクセス ID（scp に cc_policyNumbers が含まれている場合）
cc_gwabuid：リソースアクセス ID（scp に cc_gwabuid が含まれている場合）

例えば、以下の JWT は外部ユーザーに対するもので、そのユーザーは保険契約者であり、2 つの保険契約（54-123456 と 54-273411）があります。（システム API の権限に関係ない情報は削除されています）。

{
    "groups" : [
        "gwa.prod.cc.Insured"
    ],
    "scp": [
        "cc_policyNumbers"
    ],
    "cc_policyNumbers": [
        "54-123456",
        "54-273411"
    ]
}

次の点に注目します。

groups トークンクレームに基づいて、Insured という役割で定義されているエンドポイントアクセス権がこの呼び出し元に付与されます。
scp トークンクレームに基づいて、この呼び出し元のリソースアクセス ID は保険証券番号として解釈されます。
cc_policyNumbers トークンクレームに基づいて、保険契約 54-123456 または保険契約 54-273411 のクレームに関連する情報へのアクセス権が、この呼び出し元に付与されます。

2 番目の例として、以下の JWT は業者である外部ユーザーに対するものです。業者の Guidewire アドレス帳で一意の識別子は cc:demo_4532 です（システム API の権限に関係ない情報は削除されています）。

{
    "groups" : [
        "gwa.prod.cc.ServiceRequestSpecialist"
    ],
    "scp": [
        "cc_gwabuid"
    ],
    "cc_gwabuid": [
        "cc:demo_4532"
    ]
}

次の点に注目します。

groups トークンクレームに基づいて、ServiceRequestSpecialist という名前の役割の定義に従ってエンドポイントアクセス権がこの呼び出し元に付与されます。
scp トークンクレームに基づいて、この呼び出し元のリソースアクセス ID が Guidewire アドレス帳で一意の識別子として解釈されます。
cc_gwabuid トークンクレームに基づいて、この呼び出し元に付与されるアクセス権は、クレーム関連情報へのアクセス権であり、クレームではサービス提供者の 1 つが連絡先の ID として cc:demo_4532 を持ちます。

ログ

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


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

クレーム連絡先とインシデントに対する権限

ベースコンフィギュレーションでは、外部ユーザーは自分の保険契約に関係するクレームのクレーム連絡先とインシデント情報で表示と編集ができます。しかし、このユーザーが表示と編集ができるのは、Insured の役割で保険契約に関係しているクレーム連絡先のみです。また、このユーザーが表示と編集ができるのは、Insured の役割で保険契約に関係しているクレーム連絡先に関係するインシデントのみです。このユーザーは以下のいずれも表示できません。

保険契約に関係しないクレーム連絡先（第三者のクレーム連絡先や業者など）に関する情報。
保険契約に関係するが当該 Insured 役割がないクレーム連絡先（代理店業者など）に関する情報。
Insured のクレーム連絡先に関連しないインシデント（第三者のインシデントなど）に関する情報。

例えば、Ray Newton さんが事故のクレームを提出するとします。事故は、Ray Newton さん自身と別の運転者（David Preston さん）が関係しています。Ray Newton さんの車両は、Sam さん経営の自動車修理サービス会社で修理します。クレームには、2 台の車両のインシデント（1 つは Ray Newton さんの車両、1 つは David Preston さんの車両）が含まれています。

Ray Newton さんは以下の操作を実行できます。
- 自分自身に関する情報を表示すること。このクレーム連絡先は Insured の役割で保険契約に関係しています。
- 自分自身の車両インシデントに関する情報を表示すること。このインシデントは、自分自身に関連しており、Insured の役割でその保険契約に関係しています。
- 新しいクレーム連絡先および新しいインシデントを作成すること。
Ray Newton さんは以下の操作を実行できません。
- David Preston さんに関する情報を表示または編集すること。
- Sam さん経営の会社に関する情報を表示または編集すること。
- David Preston さんの車両インシデントに関する情報を表示または編集すること。
- 自分が作成したクレーム連絡先（Insured の役割で保険契約に関係していないもの）に関する情報を表示または編集すること。
- 自分が作成したインシデントに関する情報（保険契約で Insured であるクレーム連絡先に関係していない情報）を表示または編集すること。