役割ベースのアクセス制御を設計する方法は？

役割ベースのアクセス制御モデルに従って、システムでユーザーができることまたはできないことを制限しようとしています。

これまでのところ、次のエンティティがあります。

users-システムを使用する人。ここにユーザー名とパスワードがあります。 roles-ユーザーが持つことができる役割のコレクション。マネージャー、管理者などのリソースのような もの-ユーザーが操作できるもの。契約、ユーザー、契約草案などの 操作のように -ユーザーがリソースでできること。作成、読み取り、更新、削除など。

さて、このような関係があるダイアグラムでは、ここで疑問が浮上します。

操作（0 .. *）は リソース（0 .. *）に対して実行され、permissionsという名前のテーブルを生成し、操作とリソースを保存します。

許可テーブルは次のようになります（1行）： ID： 1、操作： create、リソース： contract。

どの意味許可する作成の契約を。

一部のリソースにはすべての種類の操作が含まれていない可能性があると感じているため、このようにしました。たとえば、契約を登録する場合、ユーザーはファイルをアップロードできますが、この操作はプロバイダーの登録には使用できません。

そのため、管理者がロールにアクセス許可を付与するときに、システムに登録されたすべての単一操作のリソースのリストはありません。

各リソースには、自分で実行できる独自の操作のコレクションがあると思います。

何かが理解できない場合は明確にすることができます。

これは、rbacを実装する正しい方法ですか？

編集

つまり、操作とリソースを持つアクセス許可テーブルを使用することで、リソースを操作に関連付けるために2つの余分なテーブルがあります。また、私はちょうど行っている可能性のリソースが持っている権限の許可テーブルが権限を格納します。

しかし、その場合、管理者がリソースを割り当てたときに、一部のリソースには存在しないアクセス許可が表示されていた可能性があります。

だから私は、データベース設計の観点から、1つの列操作と別のリソースを持つこのテーブル権限が正しいかどうか知りたいですか？この状態が続くと問題が発生しますか？

あなたのデザインは私にかなり近いようです。いくつかの提案。

users-システムを使用する人。ここにユーザー名とパスワードがあります。

いいよ

roles-ユーザーが持つことができる役割のコレクション。マネージャー、管理者などのようなもの

も元気。ただし、どのユーザーがどのロールを持っているかを示す「UserRoles」エンティティ/テーブルも必要です。特定のユーザーが2つ以上のロールを持つ可能性があります。

リソース-ユーザーが操作できるもの。契約、ユーザー、契約ドラフトなど。

セマンティクスの問題かもしれません。ユーザーがリソースを直接操作するとは思わない。役割はします。したがって、ユーザー->ユーザーロール->ロール->操作->リソース

操作-ユーザーがリソースで実行できること。作成、読み取り、更新、削除など。

うん、「ユーザー」の代わりに「役割」を除く

許可テーブルは次のようになります（1行）：ID：1、操作：create、リソース：contract。これは、契約を作成する許可を意味します。

うーん。これには2つの方法があります。説明した権限テーブルを使用できますが、RolePermissionsどのロールにどの権限があるかを示す追加のテーブル/エンティティも必要になります。しかし、それが必要かどうかはわかりません。

より簡単な方法は、ロールID、操作ID、リソースIDの列/属性を持つパーミッションテーブル/エンティティです。このように、操作xリソースの組み合わせは、ロールに割り当てられた許可にロードされるのではなく、ロールに直接割り当てられます。1つのエンティティを削除します。許可される許可の組み合わせと許可されない許可の組み合わせを事前に定義する場合を除き、役割に依存しない許可テーブルを別に用意する必要はありません。

RBACを使用または実装しません。代わりに、ABACを使用します。説明させてください...

• RBACまたは役割ベースのアクセス制御は、ユーザー管理と役割の割り当てに関するものです。RBACでは、アリスはマネージャーであると言うことができます。それとともに静的な許可を定義できます。たとえば、マネージャーはローンを承認できます。そのため、アリスからマネージャーへのリンクがあり、許可として融資を承認します。それを可能にするシステムはたくさんあるので、独自のテーブルを実装する必要はありません。LDAPでも、RBACの限られたセットをサポートしています。比較的小さなロールと権限のセットがある限り、それは問題ありません。しかし、あなたの場合のように特定の許可を考慮したい場合はどうでしょうか？表示、削除、挿入しますか？関係を考慮したい場合はどうしますか？
• ABACまたは属性ベースのアクセス制御は、ポリシー駆動型のきめの細かい承認に関するものです。ABACを使用すると、RBACで定義されているロールを使用して、ポリシーを記述できます。
  • 管理者は部門内のドキュメントを表示できます
  • 従業員は自分が所有するドキュメントを編集できます

あなたの質問では、基本的に情報モデルを定義しました。オブジェクトとその属性（ユーザー（名前、パスワード、部門など）など）。オブジェクト（たとえば、契約）など。

したがって、ABACでは、アプリケーションコード/ロジックを承認ロジックから完全に分離し、その後、属性を使用してポリシーとして保存します。権限自体はポリシーに直接保存されます（上記の例を参照）。ABAC展開アーキテクチャは次のようになります

ポイントは、ABACアプローチを採用する場合、ABACのポリシーを記述し（XACMLまたはALFAで-そのためのツールがたくさんあります）、RBACをカスタムコード化またはカスタム実装したり、アクセス制御を再度行ったりする必要はありません。