基本認証のフローの例

下図は、基本認証の認証情報と権限情報のフローを示しています。色は以下のように使用されます。

  • オレンジ：認証情報
  • 青：エンドポイントのアクセス権情報
  • 緑：リソースのアクセス権情報
  • 赤：プロキシユーザーとセッションユーザーの情報

いくつかの値を使用して、複数の種類のアクセスを決定します。これらの値は最初（1 つの種類のアクセスに適用されていない場合）は黒で表示されてから、1 つ以上の特定の色（特定の種類のアクセスに対してプロセスのその時点で使用されていることを値が反映する）で表示されます。

以下の例では、API 呼び出しが Andy Applegate 担当者によってトリガされます。担当者は、ブラウザベースのアプリケーションおよび基本認証を使用している内部ユーザーです。


基本認証の認証フロー
  1. 担当者が API 呼び出しをトリガすると、呼び出し元アプリケーションがその API 要求を ClaimCenter に送信します。Base64 でエンコードされたバージョンのユーザー名（aapplegate@acme.com）とパスワード（aPassword）がこの要求ヘッダーに含まれています。
  2. ClaimCenter によってユーザーが認証され、エンドポイントのアクセス権が決定されます。
    1. 要求ヘッダーでユーザー名（aapplegate@acme.com）を使用すると、ClaimCenter によってユーザーテーブルにクエリが実行されます。
    2. ClaimCenter によって、ユーザー名およびパスワードが一致していることが確認されて、ユーザーが認証されます。
    3. ClaimCenter によって、このユーザーが持つユーザー役割とともに応答が送信されます。Adjuster の役割が 1 つ返されます。
  3. 返された役割に基づいて、Adjuster.role.yaml の API 役割ファイルが使用されて、エンドポイントのアクセス権が定義されます。
  4. 次に、ClaimCenter によって、リソースアクセス戦略が決定されます。この呼び出しは基本認証を使用しているため、internal access.yaml ファイルに定義されているとおりのリソースアクセス権が ClaimCenter によって付与されます（* ClaimCenter は internal_ext-1.0.access.yaml から始まりますが、このファイルは別の access.yaml ファイルを参照します。それらの名前は internal で始まります）。
  5. プロキシユーザーのアクセス権は、基本認証には関係ありません。
  6. ClaimCenter によって要求が処理されます。
    1. セッションユーザーは、内部ユーザーの aapplegate@acme.com です。
    2. エンドポイントのアクセス権は Adjuster.role.yaml によって定義されます。
    3. リソースのアクセス権は、aapplegate@acme.com のリソースアクセス ID を使用して internal access.yaml によって定義されます。
  7. ClaimCenter によって、最初の呼び出しに対する応答が渡されます。