ロールベースのアクセス制御のDBスキーマ
私は現在、ここでローカルアソシエーションのメンバー管理を開発しており、現在データベーススキーマを開発しています。それを改善するためにあなたと共有したいと思います。また、役割ベースのアクセスモデル（RBAC）の他の例を示します。特にテーブル間で使用した関係について、建設的な批判をいただければ幸いです。
高解像度へのリンク： http://i.stack.imgur.com/WG3Vz.png
スキーマは次のとおりです。 
使い方：
既存のクライアント（実際にはアソシエーションのメンバー）を外部アプリケーションから管理アプリケーションにマッピングしています。 （クライアントテーブル）
関連付けは、Division、Subdivisionsなどで構成されます（intern_structuresテーブル）。すべてのクライアントは、複数のディビジョン、サブディビジョン、セクションなどのメンバーになることができます。
すべてのクライアントは、社長、アクチュアリー、会計などのようなメンバーシップ（部門など）で1つまたは複数の役割を持つことができ、各役割には、役割の所有者が自分の部門、下位部門、セクションなどで他の人に適用できる特定の特権があります。 。
資格情報は、アプリケーションの特定のアクションに関連付けられています。資格情報の所有者は、自分のスコープ内の他のメンバーに対してこのアクションを実行できます。複数の「スタンドアロン」アプリケーションが存在する可能性がありますが、それらはすべて同じ認証/承認システムを共有します。
アプリケーションは、モジュール/サブモジュール/アクションなどで構成されています。例として、「個人情報」モジュールがあります。このモジュールには「画像」というサブモジュールが含まれており、この画像に「表示、削除、編集」アクションを適用できます。ただし、削除しようとしている写真の人物が、適切な役割を持っている部門/セクションにいない限り、写真を削除することはできません。
内部構造とアプリケーション構造は両方ともツリーであり、隣接リストおよびネストされたセットとして実装されます。隣接リストは整合性を保証し、ネストされたセットにより、ツリーをすばやくトラバースできます。
例外は、誰かに特定の資格情報を直接与えることができることです（client_credentials）。これは、自分の部門/セクションにいない誰かに対して特定のアクションを実行する必要がある場合に必要です。
したがって、誰かが複数の部門/セクションのメンバーになり、メンバーであるすべての部門/セクションで複数の役割を取得することができます。私は誰かが彼の複数の役割を通して持っているすべての資格情報をマージするつもりです。また、資格情報は常に正であるため、制限付きの資格情報は使用できません。
私が本当に気に入っているRBACシステムの別の例を紹介します。 Tony Marstonによるradicoreフレームワークをチェックしてください ここ 。
それがあなたのすべての要件を満たしているかどうかはわかりませんが、あなたの仕事を比較できる何かが役立つでしょう。
次のようなRBACマッピングはあまり見られないようです。
Operation = Any action, such as CRUD operations
Object = Reference to any object instance
Permission = Mapping of 'Operation' + 'Object'
すべての「資格情報」テーブルが何であるかわかりませんか？資格情報は通常、自分の身元を証明するためのプロパティ（つまり、ユーザー名/パスワード）を保持します。なぜ役割の資格情報を持っているのですか？