AuthZENのAuthorization APIとは（２）

こんにちは、富士榮です。

では、Authorization APIのImplementer's draftを見ていきましょう。

https://openid.net/specs/authorization-api-1_0-01.html

とりあえず前段部分を見ていきます。

Abstract

The Authorization API enables Policy Decision Points (PDPs) and Policy Enforcement Points (PEPs) to communicate authorization requests and decisions to each other without requiring knowledge of each other's inner workings. The Authorization API is served by the PDP and is called by the PEP. The Authorization API includes an Evaluation endpoint, which provides specific access decisions. Other endpoints may be added in the future for other scenarios, including searching for subjects or resources.

概要

Authorization API により、ポリシー決定ポイント (PDP) とポリシー適用ポイント (PEP) は、互いの内部動作を知らなくても、認​​可要求と決定を相互に通信できます。Authorization API は PDP によって提供され、PEP によって呼び出されます。Authorization API には、特定のアクセス決定を提供する評価エンドポイントが含まれています。将来的には、サブジェクトやリソースの検索など、他のシナリオ用に他のエンドポイントが追加される可能性があります。

前回書いた通り、Authorization APIはPDP（ポリシー決定ポイント）によって提供されるAPIです。要するにPEP（ポリシー適用ポイント）からの問い合わせに応じて、認可ポリシーを返却する、というAPIですね。本格的に繊細な認可制御をしようとするとリソースやサブジェクトの情報も必要になるので、将来的にはその辺りまで見ていくことになるのかもしれませんね。

1. Introduction

Computational services often implement access control within their components by separating Policy Decision Points (PDPs) from Policy Enforcement Points (PEPs). PDPs and PEPs are defined in XACML and NIST's ABAC SP 800-162. Communication between PDPs and PEPs follows similar patterns across different software and services that require or provide authorization information. The Authorization API described in this document enables different providers to offer PDP and PEP capabilities without having to bind themselves to one particular implementation of a PDP or PEP.

1.はじめに

計算サービスでは、ポリシー決定ポイント (PDP) とポリシー適用ポイント (PEP) を分離することで、コンポーネント内にアクセス制御を実装することがよくあります。PDP と PEP は、XACMLと NIST の ABAC SP 800-162定義されています。PDP と PEP 間の通信は、認可情報を必要とする、または認可情報を提供するさまざまなソフトウェアやサービスで同様のパターンに従います。このドキュメントで説明するAuthorization API を使用すると、さまざまなプロバイダーが、特定の PDP または PEP の実装に縛られることなく、PDP および PEP 機能を提供できます

基本的にはPDP APIの標準化をしていきますよ、ってことですね。

2. Model

The Authorization API is a transport-agnostic API published by the PDP, to which the PEP acts as a client. Possible bindings of this specification, such as HTTPS or gRPC, are described in Transport.

Authorization for the Authorization API itself is out of scope for this document, since authorization for APIs is well-documented elsewhere. For example, the Authorization API's HTTPS binding MAY support authorization using an Authorization header, using a basic or bearer token. Support for OAuth 2.0 ([RFC6749]) is RECOMMENDED.

2.モデル

Authorization API は PDP によって公開されたトランスポートに依存しない API であり、PEP はクライアントとして機能します。HTTPS や gRPC など、この仕様の可能なバインディングについては、トランスポートで説明されています

Authorization API 自体の認可は、API の認可については他の場所で十分に文書化されているため、このドキュメントの範囲外です。たとえば、Authorization API の HTTPS バインディングは、ヘッダーAuthorization、basicまたはトークンを使用した認可をサポートする場合があります。OAuth 2.0 ( [ RFC6749 ] )bearerのサポートが推奨されます

Authorization API自体はトランスポートアグノスティックな設計になっているようです。この辺りは他のAPIと同じく汎用的な思想です。またAuthorization API自体の認可という一瞬混乱する話が出てきますが、PDPサービスを提供するAPIとしてのAuthorization APIと、そのAPIへの認可（OAuth的な意味での認可）をするのはOAuthを使いましょうね、という話です。やっぱりOAuthの「認可」という言葉はここでも混乱を招きますね。クライアントであるPEPへのアクセス権限の付与（委譲）、っていう文脈での「認可」ですね。 

3. Features

The core feature of the Authorization API is the Access Evaluation API, which enables a PEP to find out if a specific request can be permitted to access a specific resource. The following are non-normative examples:

• Can Alice view document #123?
• Can Alice view document #123 at 16:30 on Tuesday, June 11, 2024?
• Can a manager print?

3.特徴

Authorization API のコア機能はアクセス評価 API であり、これにより PEP は特定のリクエストが特定のリソースへのアクセスを許可されるかどうかを確認できます。以下は非規範的な例です: 

• アリスは文書 #123 を閲覧できますか? 
• アリスは2024年6月11日火曜日の16:30に文書#123を閲覧できますか? 
• マネージャーは印刷できますか? 

このAPIの特徴はPEPからの問い合わせに対してアクセス評価を行い結果を返却するというところにありそうですね。

4. API Version

This document describes the API version 1. Any updates to this API through subsequent revisions of this document or other documents MAY augment this API, but MUST NOT modify the API described here. Augmentation MAY include additional API methods or additional parameters to existing API methods, additional authorization mechanisms, or additional optional headers in API requests. All API methods for version 1 MUST be immediately preceded by the relative URL path /v1/.

4. APIバージョン

このドキュメントでは、API バージョン 1 について説明します。このドキュメントまたは他のドキュメントの今後の改訂によるこの API の更新では、この API を拡張できますが、ここで説明する API を変更してはなりません。拡張には、追加の API メソッド、既存の API メソッドへの追加のパラメーター、追加の認証メカニズム、または API リクエスト内の追加のオプション ヘッダーが含まれる場合があります。バージョン 1 のすべての API メソッドの直前には、相対 URL パスがなければなりませ/v1/。

まぁ、ここは互換性のためのバージョニングの話なので、このAPIに限った話じゃありませんので省略。

次からデータモデルの話に入っていくのでまずはここまでです。