2024年9月26日木曜日

AuthZENのAuthorization APIとは(3)

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

引き続きAuthZEN WGのAuthorization API 1.0のdraftを見ていきます。

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


今回はAPIが扱うデータモデルについてです。

5. Information Model

The information model for requests and responses include the following entities: Subject, Action, Resource, Context, and Decision. These are all defined below.

5.情報モデル

リクエストとレスポンスの情報モデルには、サブジェクト、アクション、リソース、コンテキスト、決定というエンティティが含まれます。これらはすべて以下で定義されています

前回の概要で述べた通り、Authorization APIはPEP(ポリシー実施ポイント)からの問い合わせを受けて認可に関する判定結果を返却するPDP(ポリシー決定ポイント)として機能します。そのため、対象となるサブジェクト(主体)、認可されるアクション(操作)、認可対象となるリソース、コンテキスト、決定結果を含むことになります。


5.1. Subject

A Subject is the user or robotic principal about whom the Authorization API is being invoked. The Subject may be requesting access at the time the Authorization API is invoked.

A Subject is a JSON ([RFC8259]) object that contains two REQUIRED keys, type and id, which have a value typed string, and an OPTIONAL key, properties, with a value of a JSON object.

type:

REQUIRED. A string value that specifies the type of the Subject.

id:

REQUIRED. A string value containing the unique identifier of the Subject, scoped to the type.

properties:

OPTIONAL. A JSON object containing any number of key-value pairs, which can be used to express additional properties of a Subject.

The following is a non-normative example of a Subject:

5.1.主体

サブジェクトとは、Authorization API が呼び出されるユーザーまたはロボット プリンシパルです。サブジェクトは、Authorization API が呼び出された時点でアクセスを要求している可能性があります

サブジェクトは、文字列の値を持つ2つの必須キー(typeとid)と、オプションとしてJSONオブジェクトの値を持つpropertiesを含むJSONオブジェクトです

type:

必須。Subjectstringのタイプを指定する値

id:

必須。stringにスコープ設定された、Subject の一意の識別子を含むtype。¶

properties:

オプション。任意の数のキーと値のペアを含む JSON オブジェクト。これを使用して、Subject の追加プロパティを表現することができます 

以下は、Subject の非規範的な例です: 

{
  "type": "user",
  "id": "alice@acmecorp.com"
}
Figure 1Example Subject


まぁ、単純に対象となる主体を表す部分ですね。ポイントはtype属性があり、この例のようにユーザを示す以外にも汎用的な用途とすることが想定されています。

5.1.1. Subject Properties

Many authorization systems are stateless, and expect the client (PEP) to pass in any properties or attributes that are expected to be used in the evaluation of the authorization policy. To satisfy this requirement, Subjects MAY include zero or more additional attributes as key-value pairs, under the properties object.

An attribute can be single-valued or multi-valued. It can be a primitive type (string, boolean, number) or a complex type such as a JSON object or JSON array.

The following is a non-normative example of a Subject which adds a string-valued department property:

5.1.1.主題のプロパティ

多くの認可システムはステートレスであり、認可ポリシーの評価で使用されることが予想されるプロパティまたは属性をクライアント (PEP) が渡すことを期待しています。この要件を満たすために、サブジェクトはpropertiesオブジェクトの下に 0 個以上の追加属性をキーと値のペアとして含めることができます

属性は単一値または複数値にすることができます。プリミティブ型 (文字列、ブール値、数値) または JSON オブジェクトや JSON 配列などの複合型にすることができます

以下は、文字列値のdepartmentプロパティを追加する Subject の非規範的な例です

{
  "type": "user",
  "id": "alice@acmecorp.com",
  "properties": {
    "department": "Sales"
  }
}
Figure 2Example Subject with Additional Property


PEPからのリクエストに応じて認可決定をするわけなので、そのために必要となる主体に関する情報が欲しいわけです。この例では部署属性をもらっているわけですね。まぁ、本当に難しいのはPEPとPDPでこのpropertiesの中身の値について標準化・同意をとっておくこと、そしてマスターデータが最新状態として同期されていることなのですが。

その意味で相互運用性を保つために幾つかのpropertiesはあらかじめ定義をしておこうとしています。

5.1.1.1. IP Address

The IP Address of the Subject, identified by an ip_address field, whose value is a textual representation of an IP Address, as defined in Textual Conventions for Internet Network Addresses [RFC4001].

The following is a non-normative example of a subject which adds the ip_address property:

5.1.1.1. IPアドレス

サブジェクトのIPアドレス。フィールドによって識別され、その値は[ RFC4001 ]で定義されているIPアドレステキスト表現です。

以下は、ip_addressプロパティを追加するサブジェクトの非規範的な例です: 

{
  "type": "user",
  "id": "alice@acmecorp.com",
  "properties": {
    "department": "Sales",
    "ip_address": "172.217.22.14"
  }
}
Figure 3: Example Subject with IP Address

最初の例がIPアドレスになっているのはよくわかりませんが、ゼロトラストの文脈におけるコンテキストを表現するためにはどのネットワークからの認可要求なのか、は想定されるべき要件だと思います。

5.1.1.2. Device ID

The Device Identifier of the Subject, identified by a device_id field, whose value is a string representation of the device identifier.

The following is a non-normative example of a subject which adds the device_id property:

5.1.1.2.デバイスID

サブジェクトのデバイス識別子。device_idフィールドによって識別され、その値はデバイス識別子の文字列表現です

以下は、device_idプロパティを追加するサブジェクトの非規範的な例です: 

{
  "type": "user",
  "id": "alice@acmecorp.com",
  "properties": {
    "department": "Sales",
    "ip_address": "172.217.22.14",
    "device_id": "8:65:ee:17:7e:0b"
  }
}
Figure 4: Example Subject with Device ID

やっぱりゼロトラストをかなり意識した作りになっている感じがしますね。

次はリソースの話です。

5.2. Resource

A Resource is the target of an access request. It is a JSON ([RFC8259]) object that is constructed similar to a Subject entity. It has the follow keys:

type:

REQUIRED. A string value that specifies the type of the Resource.

id:

REQUIRED. A string value containing the unique identifier of the Resource, scoped to the type.

properties:

OPTIONAL. A JSON object containing any number of key-value pairs, which can be used to express additional properties of a Resource.

5.2.リソース

リソースはアクセス要求の対象です。これは、Subject エンティティと同様に構築された JSON オブジェクトです。次のキーがあります: 

type:

必須。stringリソースのタイプを指定する値

id:

必須。stringリソースの一意の識別子を含む値type。

properties:

オプション。任意の数のキーと値のペアを含む JSON オブジェクト。これを使用して、リソースの追加プロパティを表現することができます

こちらもサブジェクトと同じような構造ですね。

5.2.1. Examples (non-normative)

The following is a non-normative example of a Resource with a type and a simple id:

5.2.1.例(非規範的)

type以下は、と単純なを持つリソースの非規範的な例ですid: 

{
  "type": "book",
  "id": "123"
}
Figure 5Example Resource

5.1のサブジェクトのところとExampleの章立て構造が異なるので若干読みづらさを感じますが、この辺りは今後のUpdateに期待というところです。

The following is a non-normative example of a Resource containing a library_record property, that is itself a JSON object:

library_record以下は、それ自体が JSON オブジェクトであるプロパティを含むリソースの非規範的な例です

{
  "type": "book",
  "id": "123",
  "properties": {
    "library_record":{
      "title": "AuthZEN in Action",
      "isbn": "978-0593383322"
    }
  }
}
Figure 6Example Resource with Additional Property

認可対象となるリソースの表現についてもpropertiesで細かく制御ができるようになっています。ただ、ここでいきなり本のサンプル??って思うところもあるのでゼロトラスト文脈でサンプルは統一した方がわかりやすいんじゃないかな?とは思いました。

5.3. Action

An Action is the type of access that the requester intends to perform.

Action is a JSON ([RFC8259]) object that contains a REQUIRED name key with a string value, and an OPTIONAL properties key with a JSON object value.

name:

REQUIRED. The name of the Action.

properties:

OPTIONAL. A JSON object containing any number of key-value pairs, which can be used to express additional properties of an Action.

The following is a non-normative example of an action:

5.3.アクション

アクションは、リクエスト者が実行しようとしているアクセスのタイプです

アクションは、値を持つ必須のキーと、JSON オブジェクト値を持つオプションのキーを含むJSON オブジェクトです

name:

必須。アクションの名前

properties:

オプション。任意の数のキーと値のペアを含む JSON オブジェクト。アクションの追加プロパティを表現するために使用できます

以下はアクションの非規範的な例です:  

{
  "name": "can_read"
}
Figure 7Example Action


まぁ、単純にどんなアクションが許可されるのか?という表現ですね。

ここも値の標準化が肝要なところですので、ある程度決めうちで標準化しようとしています。

5.3.1. Common Action Values

Since many services follow a Create-Read-Update-Delete convention, a set of common Actions are defined. That said, an Action may be specific to the application being accessed or shared across applications but not listed in the common Actions below.

The following common Actions are defined:

  • can_access: A generic Action that could mean any type of access. This is useful if the policy or application is not interested in different decisions for different types of Actions.
  • can_create: The Action to create a new entity, which MAY be defined by the resource field in the request.
  • can_read: The Action to read the content. Based on the Resource being accessed, this could mean a list functionality or reading an individual Resource's contents.
  • can_update: The Action to update the content of an existing Resource. This represents a partial update or an entire replacement of an entity that MAY be identified by the Resource in the request.
  • can_delete: The Action to delete a Resource. The specific entity MAY be identified by the Resource in the request.

PDP Policies MAY incorporate common Action names to provide different decisions based on the Action.

5.3.1.共通アクション値

多くのサービスは作成、読み取り、更新、削除の規則に従うため、一連の共通アクションが定義されています。ただし、アクションはアクセスされるアプリケーションに固有のものである場合や、アプリケーション間で共有される場合もありますが、以下の共通アクションにはリストされていません

以下の共通アクションが定義されています: 

  • can_access: あらゆるタイプのアクセスを意味する可能性のある汎用アクション。これは、ポリシーまたはアプリケーションが、異なるタイプのアクションに対して異なる決定を行う必要がない場合に便利です
  • can_create: 新しいエンティティを作成するアクション。resourceリクエスト内のフィールドによって定義される場合があります
  • can_read: コンテンツを読み取るアクション。アクセスされるリソースに基づいて、これはリスト機能または個々のリソースのコンテンツの読み取りを意味する場合があります
  • can_update: 既存のリソースのコンテンツを更新するアクション。これは、リクエスト内のリソースによって識別される可能性のあるエンティティの部分的な更新または全体の置き換えを表します
  • can_delete: リソースを削除するアクション。特定のエンティティは、リクエスト内のリソースによって識別される場合があります

PDP ポリシーには、アクションに基づいて異なる決定を提供するために共通のアクション名が組み込まれる場合があります 

共通の値として手始めにCRUD(Create/Read/Update/Delete)を中心に設計をしているようですが、PEPからのリクエスト方法にも依存しそうです。単にアクセス権を教えて、と言われたらcan_readという回答になる可能性はありますが、更新可能?っと聞かれたらtrue/falseで回答した方が特にエッジの機器を考えると軽量で済む気もします。

この辺りはフィードバックしてもいいのかもしれません。

5.4. Context

The Context object is a set of attributes that represent environmental or contextual data about the request such as time of day. It is a JSON ([RFC8259]) object.

The following is a non-normative example of a Context:

 5.4.コンテキスト

Context オブジェクトは、時刻などのリクエストに関する環境またはコンテキストデータを表す属性のセットです。これは JSON オブジェクトです

以下はコンテキストの非規範的な例です: 

{
  "time": "1985-10-26T01:22-07:00"
}
Figure 8Example Context

うーん、ABACを考えるとコンテキストは非常に重要なんですが、5.1でサブジェクトのpropertiesとして設定する部分とコンテキストに指定する部分の切り分けが難しくなってしまっているような気がします。IPアドレスやデバイスIDなどは上記の例の時間と合わせて動的に変化しうる環境属性と言える場合もあるので、コンテキストに入れた方が良いのではないかと個人的には思います。

この辺もフィードバックかもしれません。


ということで、今回はデータモデルの部分について読んでいきました。この後はAPIそのものについて見ていきます。





 

0 件のコメント: