ロールベースのアクセス制御 - db内のアクセス権リスト、またはコード内のアクセス権リスト（enumなど）は必要ですか？

Question

一般的な役割ベースのアクセス制御のいくつかの並べ替えを実装する際に、我々は以下のよく知られた概念を持っている：

• 役割
• ユーザー
• 許可

、ユーザーがロールに割り当てられますそれらの各々は、（リソースの操作/アクセスを実行するための）アクセス権のセットを有する。 ユーザーは、1つ以上のロール（権限のセットが割り当てられている）に割り当てられて操作を実行するための権限を取得します。

特定のアプリケーションでは、コードが実際にリソースへのアクセスが可能なさまざまな場所でアクセス許可を強制するため、アクセス許可はコンパイル時に定義されます。

考えられるアクセス許可/操作のセットが変更された場合 - コードに変更を加えて再コンパイルする必要があるため、データベース内の参照/参照テーブルを使用しても、 db adminは、アプリで使用されているすべての権限を一覧表示するために簡単なSQLクエリを実行できます。

私が見たほとんどのアプリケーションでは、アクセス許可のルックアップテーブルが作成され、-also-コードの列挙型にマップされます。

これを考えると、可能性のあるアクセス許可のリストを表すデータベーステーブルを実際に持っている理由はありますか（コードを掘り下げてデータベースを検索するのではなく、権限のリスト/列挙型）？

Answer 1

チェックリスト： 1）ウェブサイトがオンラインで、ダウンタイムなしに変更する必要がありますか？ 2）組み込みロール/メンバーシッププロバイダを使用しますか？ 3）属性（mvc [Authorize]など）などを使用したいですか？ 4）ユーザーがプログラムによって権限や役割を変更できるようにしたいですか？

上記のいずれかは、DBに情報を保存する必要があることを意味します。各ユーザー擬似クラスの権限を持つ

isadmin() 
{ 
    if (usernameArray.Contains[currentname]) 
     return true; 
    [...] 
} 

ispublisher() 
{ 
    if (isadmin()) return true; 
    [...] 
    } 

とテーブル：私はまた、相続のいくつかの種類を使用して、いくつかの静的メソッド、すなわちを作成することを好む小さい規模のアプリのために

。

更新：特定のアクセスのためのDBスキーマ：（* &が外部キーである、キーです）

Users: 
Username * 
[...] 


UserClasses (EG: admin...) 
ID * 
description 

AccessTypes (EG: can delete) 
ID * 
description 

UserClassesAssign 
classid *& 
username *& 

AccessPerClass 
accessid *& 
classid *& 

だから、いつでもあなたは「ユーザ名は」「CanDelete」にできるかどうかを確認したい、あなたがする必要がありますユーザー 'ユーザー名'が 'CanDelete'アクセスにリンクされているクラスにリンクされているかどうかを確認してください。これらのリンクはもちろんランタイム中に変更することができます。