ユーザはロールを通してパーミッションと関連付けられます。簡単に言えば、ユーザーはいくつかのロールを持ち、それぞれのロールはいくつかのパーミッションを持ちます。このようにして、"ユーザ-ロール-パーミッション "権限モデルが構築されます。このモデルでは、一般にユーザとロール、ロールとパーミッションの関係は多対多の関係になります。
ロールとは何ですか？それは、ある数のパーミッションの集合体、パーミッションの担い手として理解することができます。例えば、フォーラムシステムでは、"スーパー管理者 "と "モデレーター "がロールです。モデレーターはフォーラムの投稿を管理したり、フォーラムのユーザーを管理したりすることができます。これらのパーミッションをユーザに与えるには、ユーザに直接パーミッションを与えるのではなく、"モデレーター "というロールを与えます。
ユーザー数が非常に多い場合、システムの各ユーザーを一人ずつ認証するのは面倒です。この場合、ユーザーをグループ化し、各ユーザーグループに複数のユーザーを入れる必要があります。ユーザーを認可するだけでなく、ユーザーのグループを認可することも可能です。この方法では、ユーザはすべての権限、つまりユーザ個人の権限を持ち、ユーザのユーザグループはその合計の権限を持ちます。
アプリケーションにおいてパーミッションは何を表しますか？機能モジュールの操作、アップロードされたファイルの削除もしくは修正、メニューへのアクセス、もしくはページ上のボタンもしくはイメージの可視性のコントロールはすべてパーミッションのカテゴリに属します。いくつかのパーミッションのデザインは、機能的なオペレーションをクラスとして、ファイル、メニュー、ページの要素を別のクラスとして、"ユーザー - ロール - パーミッション - リソース "の権限モデルを構成します。データテーブルをモデリングするとき、機能操作とリソースは統一された方法で管理することができます。
権限テーブルには "権限タイプ "というカラムがあり、"MENU "はメニューのアクセス権、"OPERATION "は機能モジュールの操作権、"FILE "はファイルの変更権、"ELEMENT "はページ要素の表示制御を意味します。例えば、"MENU "はメニューのアクセス権、"OPERATION "は機能モジュールの操作権、"FILE "はファイルの変更権、"ELEMENT "はページ要素の表示制御を意味します。
この設計には2つの利点があります。第一に、権限操作とリソースを区別する必要がありません。第二に、拡張が簡単です。システムが新しいものの権限を制御したい場合、新しい関連テーブル "permissions XX associated table "を作成し、このタイプの権限文字列の権限を決定するだけです。
ここで重要なことは、パーミッション・テーブルはパーミッション・メニュー関連付けテーブルと、パーミッション・メニュー関連付けテーブルはメニュー・テーブルと1対1のリレーションシップを持っているということです。つまり、メニューを追加するたびに、これら3つのテーブルに同時にレコードを挿入しなければなりません。この方法では、許可メニュー関連テーブルを必要としないので、許可テーブルとメニューテーブルが直接関連付けられている、この時点で、我々は、メニューのIDを保存するために許可テーブル内の新しい列を追加する必要があります "許可タイプ "とIDを介して許可テーブルは、レコードのどのタイプのタイプを区別するために。
ここまでで、RBAC許可モデルの拡張モデルの完全な設計図は以下のようになります：
システムの規模が大きくなるにつれて、管理を容易にするために、ロールグループを導入してロールを分類して管理することができます。例：電力網システムの権利管理モジュールは、ロールが地区事務所にぶら下がっており、地区事務所は、ここでロールグループとして扱うことができ、それは権利の配布に参加しません。また、ために上記のメインテーブルの管理を容易にし、自分自身を見つけるには、メニューツリー、ファンクションツリーなどのツリー構造を使用することができます、もちろん、これらは権利の割り当てに参加する必要はありません。
上記は基本的なRBACモデルの拡張であり、具体的な設計はプロジェクトのビジネスニーズに応じて調整する必要があります。
ユーザーグループを設計する必要がありますか。
ユーザ・グループを設計するには、ユーザにユーザ・グループを追加し、ユーザ・グループにパーミッションを追加する必要がありますが、これは個々のユーザに直接パーミッションを追加するのと同様であると主張されてきました。しかし、既存のユーザにパーミッションを与える必要がある場合、ユーザグループデザインパターンを使用すれば、各ユーザにパーミッションを与えるのではなく、ユーザグループに直接パーミッションを与えることができます。また、ユーザーグループの利用は、ユーザー間の階層関係を反映する構造でもあるので、ユーザーグループの利用は必要だと思います。
