サービスアカウントマッピング付きサービスに対する認証の概要

サービスアカウントマッピング付きサービスに対するエンドポイントアクセス権

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

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

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

service-with-service-account-mapping 呼び出しでは、システム API によって、サービスが ClaimCenter データベース内のサービスアカウントにマッピングされます。次に、ClaimCenter によって、このサービスアカウントのユーザー役割について運用データベースに対してクエリが実行されます。サービスに付与されるエンドポイントアクセス権は、すべての API 役割に対するアクセス権であり、当該 API 役割の名前はサービスアカウントのユーザー役割の名前に対応します。

例えば、ACME 事故受付サービスが acmeFNOL という名前のサービスアカウントにマッピングされているとします。acmeFNOL アカウントは、ACME Adjuster と ACME Reinsurance Manager という 2 つのユーザーの役割を持っています。ACME 事故受付サービスがシステム API 呼び出しをトリガします。ClaimCenter によってサービスが acmeFNOL アカウントにマッピングされ、サービスアカウントのユーザー役割についてデータベースにクエリが実行されます。2 つのユーザー役割が返されます。ACME Adjuster と ACME Reinsurance Manager です。ClaimCenterによってその後、サービスにエンドポイントアクセス権が付与されます。それは、ACMEAdjuster と ACME Reinsurance Manager という名前の API 役割で定義されているアクセス権です。

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

サービスアカウントマッピング付きサービスに対するリソースアクセス権

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

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

リソースアクセス権は、2 つの機能によって制御されます。リソースアクセス ID とリソースアクセス戦略です。

リソースアクセス ID は、呼び出し元が誰であるかと呼び出し元の所有物を定義する文字列です。リソースアクセス ID を使用して、認証された呼び出し元が API 呼び出しを介してアクセスできるリソースを決定します。

• リソースアクセス ID は、「呼び出し元が誰なのか」を特定できます。例えば、サービス提供者のリソースアクセス ID は、提供者のアドレス帳 ID です。通常、関連付けられた連絡先 ID のリストでこの ID が含まれているすべてのクレームに、サービス提供者はアクセスできます。
• リソースアクセス ID は、「呼び出し元の所有物」を特定できます。例えば、保険契約者のリソースアクセス ID は、1 つ以上の保険証券番号のリストです。通常、それらの保険証券番号が付いたすべての保険契約に保険契約者はアクセスできます。

リソースアクセス戦略は、リソースアクセス ID の意味を特定する一連のロジックです。ベースコンフィギュレーションには、サービスアカウントに対する以下のリソースアクセス戦略が含まれています。

サービスが service-with-service-account-mapping 呼び出しを行うと、サービスはサービスアカウント名にマッピングされます。このアカウント名はリソースアクセス ID として使用され、そして cc_username 戦略が使用されます。ベースコンフィギュレーションのアクセス制御リスト（ACL）で定義されているように、ユーザーのアクセス権に可能な限り密接に一致するシステム API ロジックで、この戦略は構成されています。

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

サービスアカウントマッピング付きサービスに対するプロキシユーザーアクセス権

サービスアカウントマッピング付きサービスに対してプロキシユーザーアクセス権は適用できません。サービスアカウントは、セッションのためのユーザーとして使用されます。したがって、呼び出しがサービスからであっても、プロキシユーザーを割り当てる必要はありません。

サービスアカウントマッピング

サービスアカウントマッピングは名前／値のペアであり、サービスのクライアント ID を ClaimCenter データベース内のユーザーの名前にマッピングします。このユーザーを、サービスアカウントと呼びます。

サービス呼び出しを受信すると、Cloud API では、クライアント ID がサービスアカウントマッピングにリストされているかどうかをチェックします。

• クライアント ID が見つかった場合、呼び出しは、service-with-service-account-mapping 呼び出しとして扱われます。サービスアカウントがセッションユーザーになり、サービスアカウントに関連付けられたアクセス権によって、サービスで実行可能な内容が定義されます。
• クライアント ID が見つからない場合、呼び出しは、service-with-user-context 呼び出しまたはスタンドアロン型サービス呼び出しとして扱われます。

例えば、以下のサービスアカウントマッピングが存在するとします。

0oaqt9pl1vZK1kybt0h7 というクライアント ID を持つサービスから呼び出しを受信したとします。このクライアント ID はサービスアカウントマッピングに存在しています。したがって、この呼び出しは service-with-service-account-mapping 呼び出しとして扱われます。この呼び出しは、acmeDocuments というユーザー名を持つサービスアカウントと関連付けられています。

同様に、0oa33344455566677788 というクライアント ID を持つサービスから呼び出しを受信したとします。このクライアント ID はサービスアカウントマッピングに存在していません。したがって、その呼び出しは、service-with-user-context 呼び出しまたはスタンドアロン型サービス呼び出しとして扱われます。

各サービスが単一のクライアント ID を持っています。したがって、特定のサービスについては、すべての呼び出しが service-with-service-account-mapping 呼び出しとして扱われるか、いずれの呼び出しも service-with-service-account-mapping 呼び出しとして扱われないかのいずれかになります。クライアント ID がサービスアカウントマッピングに存在する場合、前者になります。存在しない場合は、後者になります。

サービスアカウントマッピングの保存

サービスアカウントマッピングは、さまざまな場所に保存できます。すべてのサービス呼び出しに対して、Cloud API はすべての場所を確認します。Cloud API は、最初に見つかったマッピングを使用します。したがって、クライアント ID が複数の場所でマッピングされている場合、最初のマッピングのみが使用されます。クライアント ID がこれらの場所のいずれでもリストされていない場合、Cloud API は、その呼び出しを service-with-user-context 呼び出しまたはスタンドアロン型サービスとして扱います。

技術的な視点からは、サービスアカウントマッピングは、これらの場所のすべてに範囲を拡大できます。ただし、保険会社は、1 つの場所を使用すると、サービスアカウントマッピングの管理が容易になる可能性があります。

サービスアカウントマッピングの保存Guidewire Cloud Console

Cloud API が確認する次の場所は、Guidewire Cloud Console（GCC）コンフィギュレーション変数です。保険会社は、GCC ユーザーインターフェイスを介して自分自身で変更できます。

GCC コンフィギュレーション変数のサービスマッピングエントリでは、以下の構文が使用されます。

PLUGIN_AUTHENTICATIONVERIFIER_SUBJECTMAPPINGS_<sub>=<username>

上記の内容に関する説明を以下に示します。

• <sub> は JWT の sub トークンクレームの値（クライアント ID に設定される）です。
• <username> は、サービスアカウントのユーザー名です。

GCC コンフィギュレーション変数に対する変更をデプロイするには、サーバーを再起動する必要があります。

サービスアカウントマッピングの保存：config.properties

次に Cloud API によって確認される場所は、config.properties ファイルです。このファイルのエントリは、以下の構文を使用します。

plugin.PLUGIN_AUTHENTICATIONVERIFIER_SUBJECTMAPPINGS_<sub>=<username>

上記の内容に関する説明を以下に示します。

• <sub> は JWT の sub トークンクレームの値（クライアント ID に設定される）です。
• <username> は、サービスアカウントのユーザー名です。

config.properties ファイルに対する変更をデプロイするには、サーバーを再起動する必要があります。

開発インスタンスでは、サービスアカウントマッピングの保存先として config.properties が適していることがあります。ただし、実稼働インスタンスでは、サービスアカウントマッピングの保存先として config.properties はお勧めしません。

サービスアカウント

サービスアカウントは、Cloud API 呼び出しを行う 1 つの外部サービスによってのみ使用されることを意図しています。通常、サービスアカウント名は、サービスを反映し（acmeDocuments など）、人間のアカウント名（aapplegate など）とは似ていません。

サービスアカウントは、サービスに適した権限を持っている必要があります。

サービスアカウントはユーザーのアクティビティのために使用しないことをお勧めします。つまり、ユーザーがサービスアカウントを使用して ClaimCenter にログオンしないようにしてください。