カスタムRBAC実装を実験したときの私の経験は、次のとおりです。
-
あなたはRBACの文献をたくさん読んで、それを理解していると思います。次に、実際にはまったく理解していないことに気付くために、先に進んでそれを実装しようとします。最終的には、プロジェクトを進めるときに意味があります。
-
あなたの質問に基づいて、あなたはすでにRBACを適用したいビジネスドメインを知っています。しかし、今のところ実際のビジネスオブジェクトについては忘れてください。 RBACの実装は汎用である必要があります。つまり、役割、ユーザー、権限、操作などのテーブルで構成されるDBスキーマがあります。次に、そのようなテーブルにマップするオブジェクトが作成されます(1対1の関係)。
このRBACの実装が完了すると、前述の「部門」など、実質的にすべてのビジネスドメインにモデル化できます。
すべてが完璧というわけではないことを覚えておいてください...カスタム機能を追加したり、パフォーマンスを強化したりするために、実際のRBACの資料から拡張/変更/派生しました。
私はしばらくこれに取り組んでいないので、次の点で正しいことを願っています:
- ユーザー:インスタンスが作成され、そのバッキングテーブルに保存されます。
-
役割:インスタンスが作成され、そのバッキングテーブルに保存されます。役割はユーザーに割り当てられます。
-
パーミッション:パーミッションは基本的に、オブジェクトに対する操作の組み合わせです。権限は役割に割り当てられます。
-
操作:操作は単にあなたが望むものです。 CRUD(作成、読み取り、更新、削除)の場合もあれば、「印刷」、「検索」、または人間(またはシステム)がオブジェクト(またはオブジェクトのグループ)に対して実行できるものの場合もあります。
- オブジェクト:これは基本的に、ビジネスドメインを構成するすべてのオブジェクトです。
さらに強力にするために、制約を実装して、膨大な量のさまざまな制限を適用することができます。
このフレームワークを使用すると、次のようにマッピングできるはずです。
- ユーザーを部門に割り当てることができるのは誰か
- 部門からそれらを削除できるのは誰か
- 部門に入ることができるユーザーの数
- (割り当てられた役割に基づいて)どのような種類のユーザーが部門に所属できるか
- どのロールが部門に対してどの操作(作成、読み取り、更新、削除)を実行できるか
- その他