ルールベースのアクセス制御の単純な汎用実装がありますか？

Question

私はイントラネットサイトのアクセス制御を実装しています。会社に200人以上の従業員とほとんどすべての人のためのカスタム権限がない場合、どちらが簡単だろうか。それは狂気です、私は知っていますが、私はそれを変更することはできません。

私は自分のニーズに合った汎用的な実装を見つけようとしましたが、それを見つけることができなかったので、私は自分でそれをやりました。結局、私はかなり一般的な解決策を思いつきました。誰かが前にそれをやったに違いないと思いました！

私はそれをSTOP（Subject Task Object Permission）アクセス制御と呼びました。

.-------.  .-----------.  .-------. 
| users |1---*| STOPRules |*---1| tasks | 
`-------'  '-----------'  '-------' 

A STOPルールは以下の通りことができ

STOPRule { 
    Subject; 
    Task; 
    ObjectType; 
    Permission; 
    Relation; 
} 

オブジェクトの関係属性があります：私は次のような関係持っている。このフィールドは必須ではありません、所有者、作成者、revisorなどを、サポートします一般的なタスク。そこにいると、現在のユーザーとオブジェクトインスタンスの間の関係はデリゲートによって計算されます。現在のリレーションは、次に、ルール上の必要なリレーションと比較され、アクセスを許可または拒否されます。

私が十分明確でないかどうか教えてください。

二つの疑問が生じる。このようなオープンソース実装が

1. ありますか？

2. このパスの後に発生する問題はありますか？

編集：私は先に行って、実際にこのモデルを実装するために始めた。最初の問題は、ユースケースをサポートするために、サブジェクトとオブジェクトの関係が必要だったことです。今、私は、次のルールを保存することができます：

ジョン（サブジェクト）できの彼はクリエーター（関係）がある場合には（許可）編集（タスク）ため（オブジェクト）注文。

このモデルを使用して表現できなかった実際の使用例を教えてください。

Answer 1

実際には、特定のロールによってグループ化されたアクセス許可を持つ1つのテーブルがあり、一般的なアクセス許可をオーバーライドする拡張アクセス許可には別のテーブルが使用されます。ジョンだけが何かにアクセスできるようにした場合、どうしてもお互いの人ができないことに言及するのはなぜですか？上記のコメントの最後の例のように、権限を持つテーブルがありますか？レコードは次のようになります：1645 edit_some_field。次に、group_permissionsは1645 everyone falseのようになり、最後の例外テーブルは1645 (Jane Doe's ID) trueになります。

、のは、このフィールドを編集するアクセス権を持つ50人がいるとしましょう場合は、あなただけのようなグループテーブル内の別のグループを追加します。89 editors_of_field_X、89 (John Smith's ID) trueのようなテーブルgroup_membersに人のIDを置きます。そして最後のステップでは、上記のように、1人の権限でそれらを上書きすることができます。結論として、あなたは3層スキームを持つでしょう。全員 - グループ - 人。そして、その役割が果たす重要性がますます高くなります。たとえば、誰もが許可されていないが、あなたが属するグループが許可されている場合は、何かを編集することができます。

さらに、第三者レベルのアクセスを許可されていない場合は、再びグループ内で例外になります。これにより、後でグループを再利用できるようになり、わずかな変更だけが追加されます。

Answer 2

Johnが注文を作成し、Bobにそれを表示させたいとします。