サービスに対する認証オプション
Cloud API では、サービスはいくつかの方法で認証を実行できます。
スタンドアロン型サービス
サービスはスタンドアロン型サービスとして認証できます。この場合、サービスはそれ自体として呼び出しを実行します。特定の個人として呼び出しを実行しませんし、特定の個人の代わりに呼び出しを実行しません。サービスは、ClaimCenter に保存されているサービスアカウントを使用して呼び出しを実行することはありません。
ClaimCenter で単一の内部ユーザーが指定されますが、すべてのスタンドアロン型サービス呼び出し用の「プロキシサービスユーザー」として指定されます。このプロキシサービスユーザーは、スタンドアロン型サービスセッションにアタッチされます。呼び出しによってオブジェクトが作成または変更される場合、このプロキシサービスユーザーがレコードのユーザーとして記録されます。
このアプローチの主な長所は、サービスレベルのみで認証情報と権限情報を管理する必要があることです。ユーザーアカウント、ユーザー権限、または追加のマッピングを作成したり管理する必要はありません。
主な短所は、すべてのスタンドアロン型サービス呼び出しが単一のプロキシサービスユーザーを共有することです。スタンドアロン型サービス呼び出しによってオブジェクトが作成または変更されるとき、呼び出しを行ったサービスを識別できない可能性があります。
ユーザーコンテキスト付きサービス
サービスを、ユーザーコンテキストで認証できます。この場合、サービスはそれ自体に関する情報を提示します。特定のユーザーに関する情報を提供する GW-User-Context ヘッダーもこの呼び出しに含まれています。ユーザーは必ずしも ClaimCenter データベース内に存在しているとは限りません。この呼び出しで実行できるのは、サービス自体が実行できてユーザー自身が実行できることのみです。
指定ユーザーは、内部ユーザー(ClaimCenter データベースにリストされているユーザー)の場合があります。その場合、その内部ユーザーはセッションにアタッチされます。呼び出しによってオブジェクトが作成または変更される場合、その内部ユーザーがレコードのユーザーとして記録されます。
指定ユーザーは、外部ユーザー(ClaimCenter データベースにリストされていないユーザー)の場合があります。 ClaimCenter で「プロキシ外部ユーザー」として単一の内部ユーザーが指定されますが、外部ユーザーを参照するすべてのユーザーコンテキスト付きサービス呼び出し用に指定されます。指定ユーザーが外部ユーザーの場合、外部プロキシユーザーがセッションにアタッチされます。呼び出しによってオブジェクトが作成または変更される場合、外部プロキシユーザーがレコードのユーザーとして記録されます。
このアプローチの主な長所は、単一のサービスがさまざまなユーザーの代わりに呼び出しを送信できることです。サービスレベルでは、サービスレベルアクセスを指定できます。ただし、関連ユーザーごとにさらにアクセスを制御できます。
主な短所は 2 つあります。第 1 に、サービスレベルとユーザーレベルという 2 つのレベルでアクセス情報を管理する必要があります。第 2 に、サービスがそのヘッダー内にどのユーザーでも指定できることです。特定サービスが特定セットのユーザーを使用するように制限する方法はありません。
サービスアカウントマッピング付きサービス
サービスを、サービスアカウントマッピングで認証できます。この場合、サービスは自動的に「サービスアカウント」にマッピングされます。マッピング情報は、環境内の別の場所で指定されます。サービスアカウントは、ClaimCenter データベース内のユーザーアカウントであり、人間ではなくサービスによる使用のみが意図されています。
このアプローチの主な長所は、呼び出しの権限と監査が、ClaimCenter データベースにリストされているサービスアカウントに結び付けられていることです。サービスごとに異なるサービスアカウントを作成して、各サービスが使用できる権限を細かく制御できます。
主な短所は、外部のアプリケーションによって行われた呼び出しに対して ClaimCenter でサービスアカウントを作成して管理する必要があることです。また、各サービスをそのサービスアカウントにマッピングするマッピング情報を管理する必要もあります。
さまざまなアプローチの比較
以下の表に、各アプローチの比較を示します。
| スタンドアロン型サービス | ユーザーコンテキスト付きサービス | サービスアカウントマッピング付きサービス | |
|---|---|---|---|
| 呼び出しによるサービス関連情報の提供可否 | JWT 内で提供される。 | JWT 内で提供される。 | JWT 内で提供される。 |
| 呼び出し時にユーザーアカウントが ClaimCenter データベースに存在する必要性 | 不要 |
関連付けられたユーザーが内部ユーザーの場合は、必要。 関連付けられたユーザーが外部ユーザーの場合は、不要。 |
必要(このユーザーアカウントは「サービスアカウント」である)。 |
| 呼び出しにおけるユーザー関連情報やユーザーアカウント関連情報の有無 | なし | あり:GW-User-Context ヘッダー内。 |
なし:呼び出しでサービスのクライアント ID を提供するが、クライアント ID からサービスアカウントへのマッピングは別の場所に保存されている。 |
| 呼び出しでアクセスできるエンドポイント | サービスの API 役割が使用できるエンドポイント。 | サービスの API 役割とユーザーの API 役割の両方が使用できるエンドポイント。 | サービスアカウントが使用できるエンドポイント。 |
| 呼び出しでアクセスできるリソース | すべてのリソース(ベースコンフィギュレーションの場合)。 | サービスとユーザーの両方が使用できるリソース。 | サービスアカウントが使用できるリソース。 |
| セッションユーザーの設定先 | プロキシサービスユーザー。 |
関連付けられたユーザーが内部ユーザーの場合は、内部ユーザー。 関連付けられたユーザーが外部ユーザーの場合は、プロキシ外部ユーザー。 |
サービスアカウント。 |
このトピックでは、サービスアカウントマッピング付きサービスに対する認証に焦点を当てます。
- スタンドアロン型サービスに対する認証の詳細については、OAuth2 クライアント認証情報のフロー:スタンドアロン型サービスを参照してください。
- ユーザーコンテキスト付きサービスに対する認証の詳細については、OAuth2 クライアント認証情報のフロー:ユーザーコンテキスト付きサービスを参照してください。