CIAM 102：承認とロールベースのアクセス制御

背景#

前の記事で、認証（AuthN）と承認（AuthZ）の概念、およびいくつかの頭痛を引き起こす用語：Identity、Organization、Tenantなどを紹介しました。

組織とテナントは、アイデンティティをグループ化するのに便利ですが、完全な民主主義をもたらします：このシステムではすべての人がすべてを行うことができます。ユートピアがまだ謎のままなので、アクセスのガバナンス、つまり承認（AuthZ）を見てみましょう。

なぜ私たちは承認が必要なのでしょうか？#

Notionは素晴らしい例です。所有している各ページについて、プライベートに保つ、つまり自分だけがアクセスできるようにするか、友人と共有するか、あるいは公開するかを選択できます。

また、オンライン書店の場合、すべての人がすべての本を表示できるようにしたいが、顧客は自分の注文だけを表示し、売り手は自分の店の本だけを管理するようにしたいと思います。

AuthZとAuthNは、複雑なビジネスモデルの必須コンポーネントです。これらは通常、一緒に行われます。 AuthZはユーザーのアクセスを確認し、AuthNはアイデンティティを認証します。どちらも安全なシステムには必要です。

基本的な権限付与モデル#

最も一般的なAuthZモデルの1つを紹介します：IDENTITYがACTIONをRESOURCE上で実行する場合、ACCEPTまたはDENYです。

例えばNotionの場合、モデルは下記の通りです。「PERSONがPAGE上でVIEWを行います」。

ページがプライベートの場合、次のようになります:

• PAGE上でVIEWを行った場合、ACCEPTを受け取ります。
• その他のすべての人は、あなたのPAGE上でVIEWを行ったときにDENYを受け取るはずです。

業界のコンセンサスに基づいて、承認技術が幅広く開発されました。例えばロールベースのアクセス制御（RBAC）、属性ベースのアクセス制御（ABAC）などです。今日は、NIST RBACモデルのLevel 1：Flat RBACに焦点を当てます。

ロールベースのアクセス制御#

書店の例を拡張してみましょう。たくさんの顧客がいるとしますが、売り手は1人だけです。

• 顧客は、本を閲覧し注文することができ、また自身の注文を閲覧することもできます。
• 売り手は、本を閲覧し、作成し、削除し、顧客の注文を管理できます。

リソースの定義#

Logtoでは、リソース（つまりAPIリソース）は通常、エンティティやアイテムのセットを表します。これは、その指標として有効なURLを使用する必要があるからです。したがって、次の二つのリソースを定義します：

• 本：https://api.bookstore.io/books
• 注文：https://api.bookstore.io/orders

URL形式を強制する1つの利点は、それがあなたのAPIサービスの実際のアドレスにマッピングできることです。これにより、システムの他のコンポーネントと統合する際の読みやすさと認識能力が向上します。

権限の定義#

リソースの概念を導入したので、Logtoでは、権限はリソースに属しなければならないと規定しています。逆に、リソースには権限を設けることができます。

リソースにいくつかの権限を追加しましょう：

• 本：read、create、delete
• 注文：read、read:self、create:self、delete

許可の名前に要件はありませんが、以下の規則があります：

ここで<action>は許可を説明するために必要であり、:<target>は一般的な対象を説明するために無視できます。つまり、リソース内のすべてのエンティティやアイテムに対するものです。例えば：

• リソースBooksの許可readは、任意の本を読むアクションを意味します。
• リソースOrders内の create:self許可は、現在のユーザーが所属する注文を作成するアクションを意味します。

ロールの定義#

簡単に言えば、ロールは一連の権限のグループです。 customerとsellerという二つのロールを作成し、それらに以下のように権限を割り当ててみましょう：

許可-ロールの割り当ては多対多の関係です。

ユーザーにロールを割り当てる#

ロール-許可の割り当てと同様に、ユーザー-ロールの割り当ても多対多の関係です。したがって、1つのユーザーに複数のロールを割り当てることができ、1つのロールを複数のユーザーに割り当てることができます。

つなげる#

以下は、LogtoのLevel 1 RBACモデルの完全な関係図です：

RBACモデルでは、許可は常に「正」です。つまり、承認の判断はシンプルです：ユーザーが許可を持っていれば、受け入れます。そうでなければ、拒否します。

Aliceがsellerのロールを持ち、BobとCarolがcustomerのロールを持っているとします。まず、自然言語でアクションを説明し、それらを標準的な承認形式に変換します：IDENTITYがACTIONをRESOURCE上で行いますし、最終的な結論を出します。

• Aliceが新しい本を発売したい。
  • ユーザーAliceがBooks（https://api.bookstore.io/books）というリソース上でcreateを実行します。
  • Aliceがsellerの役割によってBooksのcreate権限が割り当てられているので、結果は✅ ACCEPTです。
• Aliceが売上が期待通りであるかを確認するためにすべての注文を表示したい。
  • ユーザーAliceがOrders（https://api.bookstore.io/orders）というリソース上でreadを実行します。
  • Aliceがsellerの役割によりOrdersのread権限が割り当てられているため、結果は✅ ACCEPTです。
• Bobが購入したい本があるかどうかを確認するために、本のリストを参照したい。
  • ユーザーBobがBooks（https://api.bookstore.io/books）というリソース上でreadを実行します。
  • Bobがcustomerの役割によりBooksのread権限が割り当てられているため、結果は✅ ACCEPTです。
• BobがCarolの注文を見たい。
  • 誰か他の人の注文なので、Ordersのread:self許可はここでは機能しません。
  • ユーザーBobがOrders（https://api.bookstore.io/order）というリソース上でreadを実行します。
  • BobはOrdersのread権限を持っていないので、結果は❌ DENYです。

他のRBACレベル#

NIST RBACモデルには4つのレベルがあります：

• Flat RBAC
• Hierarchical RBAC
• Constrained RBAC
• Symmetric RBAC

興味がある場合は、詳細についてpaperをご覧ください。

Logtoは現在、Level 1の実装を提供しており、コミュニティからのフィードバックに基づいて高いレベルに進行する予定です。もし高いレベルがあなたのニーズに適していると思われる場合は、遠慮せずにお知らせください！

実際には#

理論だけでなく、予想通りの動作をさせるために完了させる必要がある大量の技術作業もまだあります：

• クライアントと認証サーバーの開発
• RBACのためのデータベース設計
• 異なるサービス間の検証
• セキュリティとオープンスタンダードの準拠
• ロール、権限、リソースの管理と割り当て

パニックにならないでください。これを考慮に入れて、すべてをカバーするための即時サポートを追加しました。 RBACをLogtoで使用する方法については🔐 RBAC recipeをご覧ください。

最後に#

RBACは、ほとんどの場合の強力なアクセス管理モデルですが、万能薬はありません。まだいくつかの質問があります：

• 高いレベルのRBACが必要ですか？
• RBACは他の承認モデルとどのように比較されますか？
• 異なる組織間の承認モデルをどのように定義しますか？