RBAC の DB スキーマを作成しようとしていますが、「部署」と「役職」を作成できるようにしたいと考えています。役職は、部門の一般的な特権を拡張します。役職と部門の両方を保持する単一の「ロール」テーブルを作成する必要がありますか? それとも、役職、部署、役割の 3 つのテーブルを作成し、役職と部署のテーブルが役割テーブルへの外部キーを持つようにする必要がありますか? 皆様のご協力をよろしくお願いいたします。乾杯。
7246 次
2 に答える
20
カスタム RBAC 実装を試したときの私の経験は次のとおりです。
あなたは RBAC の文献をたくさん読み、それを理解していると思っています。それから先に進み、それを実装しようとしますが、まったく理解していないことに気づきます。最終的には、プロジェクトを進めていくうちに理解できるようになります。
質問に基づいて、RBAC を適用するビジネス ドメインを既に知っています。しかし、ここでは実際のビジネス オブジェクトについては忘れてください。RBAC の実装は汎用的である必要があります。つまり、Role、User、Permission、Operation などのテーブルで構成される DB スキーマがあることを意味します。次に、そのようなテーブルにマップされるオブジェクトがあります (1 対 1 の関係)。
この RBAC 実装があれば、言及した「Deparment」など、事実上すべてのビジネス ドメインにモデル化できます。
すべてが完璧ではないことを覚えておいてください...カスタム機能を追加したり、パフォーマンスを向上させたりするために、実際のRBACの文献を強化/変更/派生させました.
私はしばらくこれに取り組んでいないので、次の点で正しいことを願っています。
- ユーザー: インスタンスが作成され、バッキング テーブルに保存されます。
役割: インスタンスが作成され、そのバッキング テーブルに保存されます。役割がユーザーに割り当てられます。
権限: 基本的に、権限はオブジェクトに対する操作の組み合わせです。権限はロールに割り当てられます。
操作: 操作とは、単純に任意のものです。CRUD (作成、読み取り、更新、削除) である場合もあれば、「印刷」、「検索」、または人間 (またはシステム) がオブジェクト (またはオブジェクトのグループ) に対して実行できるものである場合もあります。
- オブジェクト: これは基本的に、ビジネス ドメインを構成するすべてのオブジェクトです。
さらに強力にするために、制約を実装して、膨大な量のさまざまな制限を適用することができます。
このフレームワークを使用すると、次をマッピングできるはずです。
- ユーザーを部門に割り当てることができるユーザー
- 部門から削除できるユーザー
- 部門に所属できるユーザーの数
- 部門に所属できるユーザーの種類 (割り当てられた役割に基づく)
- どのロールが部門に対してどの操作を実行できるか (作成、読み取り、更新、削除)
- 等。
于 2011-09-30T20:05:02.573 に答える
4
規格？そのようなものは存在しないので、これは答えられない質問です。RBAC は常に要件に基づいてカスタマイズされます。
次のリソースを参照してください。
于 2011-09-07T06:06:00.380 に答える