2024年9月28日土曜日

AuthZENのAuthorization APIとは(5)

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

AuthZEN WGが策定しているAuthorization API 1.0 draftを引き続き見ていきます。

最後はTransportです。

7. Transport

This specification defines an HTTPS binding which MUST be implemented by a compliant PDP.
Additional transport bindings (e.g. gRPC) MAY be defined in the future in the form of profiles, and MAY be implemented by a PDP.

7.トランスポート

この仕様は、準拠した PDP によって実装されなければならない HTTPS バインディングを定義します
追加のトランスポートバインディング (例: gRPC) は、将来プロファイルの形式で定義され、PDP によって実装される可能性があります

設計思想としてTransport Agnosticにしているのはいいことだと思います。今回は手始めにHTTPSバインディングからスタートしますが、将来的にgRPCなどへもバインドされる可能性はありますね。むしろIoT文脈なども考えるならOver BLEとかも出てくるかもしれません。

7.1. HTTPS Binding
7.1.1. HTTPS Access Evaluation Request

The Access Evaluation Request is an HTTPS request with content-type of application/json. Its body is a JSON object that contains the Access Evaluation Request, as defined in Section 6.1.

The following is a non-normative example of the HTTPS binding of the Access Evaluation Request:

7.1. HTTPSバインディング
7.1.1. HTTPSアクセス評価リクエスト

content-type、のHTTPS リクエストです。その本体は、セクション 6.1application/jsonで定義されているアクセス評価リクエストを含む JSON オブジェクトです。

以下は、アクセス評価リクエストの HTTPS バインディングの非規範的な例です: 

POST /access/v1/evaluation HTTP/1.1
Host: pdp.mycompany.com
Authorization: Bearer <myoauthtoken>
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "subject": {
    "type": "user",
    "id": "alice@acmecorp.com"
  },
  "resource": {
    "type": "todo",
    "id": "1",
  },
  "action": {
    "name": "can_read"
  },
  "context": {
    "time": "1985-10-26T01:22-07:00"
  }
}
Figure 14: Example of an HTTPS Access Evaluation Request

まずはリクエストをOver HTTPSで実装する例です。

まぁ、POSTでしょうね。アクセストークンでの保護も重要なポイントです。別途Security Considerationでも今後議論されると思いますが、ここではPEPからのリクエストに対する攻撃(盗聴、置き換えや改ざんなど)が一番の考慮事項になると思います。単純にSubjectのロールやResourceなどを置き換えてしまうことでアクセス制御をバイパスできてしまうとまずいわけです。(現状のSecurity Considerationはまだ薄っぺらいのでもうちょっと詰めないとダメな気がしています。一応Sender Constraintについては触れられてはいますが)

7.1.2. Access Evaluation HTTPS Response

The success response to an Access Evaluation Request is an Access Evaluation Response. It is an HTTPS response with a status code of 200, and content-type of application/json. Its body is a JSON object that contains the Access Evaluation Response, as defined in Section 6.2.

Following is a non-normative example of an HTTPS Access Evaluation Response:

7.1.2.アクセス評価 HTTPS レスポンス

アクセス評価リクエストに対する成功応答は、アクセス評価応答です。statusが200でcontent-typeはapplication/jsonのHTTPS応答です。ボディはセクション 6.2で定義されているアクセス評価応答を含む JSON オブジェクトです。

以下は、HTTPS アクセス評価応答の非規範的な例です: 

HTTP/1.1 OK
Content-type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716

{
  "decision": true
}
Figure 15: Example of an HTTPS Access Evaluation Response

ここは前回書いた通りtrue/falseだけでいいのか問題は置いておいて、普通かと。

7.1.3. Error Responses

The following error responses are common to all methods of the Authorization API. The error response is indicated by an HTTPS status code (Section 15 of [RFC9110]) that indicates error.

The following errors are indicated by the status codes defined below:

7.1.3.エラー応答

以下のエラー応答は、Authorization API のすべてのメソッドに共通です。エラー応答は、RFC9110セクション15に定義されているHTTPS ステータス コード によって識別されます。

以下のエラーは、以下に定義されているステータス コードによって示されます

Table 1HTTPS Error status codes
CodeDescriptionHTTPS Body Content
400Bad RequestAn error message string
401UnauthorizedAn error message string
403ForbiddenAn error message string
500Internal errorAn error message string

Note: HTTPS errors are returned by the PDP to indicate an error condition relating to the request or its processing, and are unrelated to the outcome of an authorization decision, which is always returned with a 200 status code and a response payload.

To make this concrete: * a 401 HTTPS status code indicates that the caller (policy enforcement point) did not properly authenticate to the PDP - for example, by omitting a required Authorization header, or using an invalid access token. * the PDP indicates to the caller that the authorization request is denied by sending a response with a 200 HTTPS status code, along with a payload of { "decision": false }.

注: HTTPS エラーは、リクエストまたはその処理に関連するエラー状態を示すために PDP によって返され、200ステータス コードと応答ペイロードとともに常に返される承認決定の結果とは無関係です

具体的には、次のようになります。 * 401HTTPS ステータス コードは、呼び出し元 (ポリシー適用ポイント) が PDP に対して適切に認証しなかったことを示します (必要なヘッダーを省略した、無効なアクセス トークンを使用したなど)。 * PDP は、 HTTPS ステータス コード200とペイロード{ "decision": false }を含むAuthorization応答を送信することで、呼び出し元に認可要求が拒否されたことを示します

注釈にもある通り、あくまでリクエストに対するHTTPSのステータスを示すレスポンスなので、認可決定に関するtrue/falseとは関係ないことに注意です。

7.1.4. Request Identification

All requests to the API MAY have request identifiers to uniquely identify them. The API client (PEP) is responsible for generating the request identifier. If present, the request identifier SHALL be provided using the HTTPS Header X-Request-ID. The value of this header is an arbitrary string. The following non-normative example describes this header:

7.1.4.リクエストの識別

API へのすべてのリクエストには、リクエストを一意に識別するためのリクエスト識別子が含まれる場合があります。API クライアント (PEP) は、リクエスト識別子を生成する責任があります。存在する場合、リクエスト識別子は HTTPS ヘッダーを使用して提供される必要がありますX-Request-ID。このヘッダーの値は任意の文字列です。次の非規範的な例は、このヘッダーについて説明しています: 

POST /access/v1/evaluation HTTP/1.1
Authorization: Bearer mF_9.B5f-4.1JqM
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716
Figure 16: Example HTTPS request with a Request Id Header

実装する際は、ここに記載されているリクエストの識別が結構重要なんじゃないかと思います。先に書いた通り、アクセス許可する・しないの非常に重要な決定を含む話なので、しっかりとステータスを管理しておく責任がPEP/PDPの両方にあると思います。

7.1.5. Request Identification in a Response

A PDP responding to an Authorization API request that contains an X-Request-ID header MUST include a request identifier in the response. The request identifier is specified in the HTTPS Response header: X-Request-ID. If the PEP specified a request identifier in the request, the PDP MUST include the same identifier in the response to that request.

The following is a non-normative example of an HTTPS Response with this header:

7.1.5.レスポンスにおけるリクエストの識別

ヘッダーを含む Authorization API リクエストに応答する PDP はX-Request-ID、レスポンスにリクエスト識別子を含める必要があります。リクエスト識別子は、HTTPS レスポンス ヘッダー(X-Request-ID)で指定されます。PEP がリクエストにリクエスト識別子を指定した場合、PDP はそのリクエストへのレスポンスに同じ識別子を含める必要があります

以下は、このヘッダーを含む HTTPS レスポンスの非標準的な例です: 

HTTP/1.1 OK
Content-type: application/json
X-Request-ID: bfe9eb29-ab87-4ca3-be83-a1d5d8305716
Figure 17Example HTTPS response with a Request Id Header

先に書いた通り、ちゃんとリクエストとレスポンスが紐づいていることを管理することは重要ですね。


ということで現時点のdraftはこんなところです。

非常にシンプルな仕様になっているので実装も簡単だと思いますが、今後のポイントは以下にしてActionやResourceを標準化していくのか、そして実装をどこまで増やすか、というところにかかってくると思います。メガSaaSな人たちが実装してくれるといいんですけどね。

まぁ、引き続き様子は気にしていきたいと思います。


0 件のコメント:

コメントを投稿