「Devilish」ACL-権利を検証するための私のオプション

私は自分のCMS（より正確には、私がCMSと呼んでいるもの）を行います。 プロジェクトは、ユーザー権利の検証レベルに達しました。 このようなシステムでは次のことが可能になります。

1. リソースのユーザー権限を確認する
2. グループにリソース権限を割り当てます
3. 親から親グループへの権利の継承
4. 親リソースルールはすべての子リソースに適用されます
5. 権利の継承（例：変更する権利には、読む権利が含まれます）

このような権利制度についての私のビジョンを説明しようと思います。

許可

最初に、私が固守する小さな用語。 許可は特定のアクションです。 権利は、ユーザーがアクションを実行する能力です。
デフォルトでは、システムには次の事前定義された権限のリストがあります。

名	説明
なし	権利なし
読む	読書
作成する	作成
更新する	変更
削除する	削除する
すべて	すべての権利

リスト内の許可は、最小から最大の順に表示されます（つまり、後続の各許可（行）には以前のすべての許可が含まれます）。 たとえば、ユーザーにcreateの権利が割り当てられている場合、そのユーザーにはを読む権利もあります 。 したがって、 すべての許可-すべての権利を与えます。 そして、許可なしはすべての権利の禁止です。

資源

リソースはlink / aaa / bbb / ccc /として設定されます。 さらに、たとえば/ aaa /のすべての権利セットは、すべての子リソースに適用されます： / aaa / bbb / 、 / aaa / bbb / ccc /など。 リソース/ aaa / bbb /リソース/ aaa /が親の場合、リソース/ aaa / bbb / ccc /は子です。

グループ

グループは、リソースへの権利の割り当て（ルールの割り当て）が行われるオブジェクトです。 すべてのグループに1つの親グループがあります。 このグループには、すべてのリソースに対するすべての権限があります。 通常、このようなグループはsuperadmin、god（god）と呼ばれます。 しかし、他のACLと異なるために-私はそのようなルートグループをディアブロ （悪魔）と呼びました。 したがって、私のシステムでは、すべての権利は「悪魔から」です。 したがって、悪魔のACLに関する記事のタイトル 。
各子会社グループは、権利のみを削減できます。 つまり 管理グループ（管理者）がリソース/ aaa / bbb / ccc /の作成権を持っている場合、ユーザーグループ（ユーザー）はaaa / bbb / ccc /リソースを削除する権利を取得できません-この場合、権利が増加します。削除許可が作成許可よりも高い方法。 また、ユーザーグループはリソース/ aaa / bbb /、/ aaa /、/の削除権を取得できません。これらはリソース/ aaa / bbb / ccc /の親リソースであるため、この場合は権限も増加します。 ユーザーがグループをリードできるようにし、ユーザーが表示したくないリソースにアクセスできることを恐れないようにするために、権限を減らす原則が必要です。ユーザーは自分が持っていない権限を自分に追加できないためです。
各グループには、1つのリソース（親リソースを含む）に対して1つのルールのみを含めることができます。 たとえば、リソース/ aaa / bbb / ccc /のルールがグループに設定されている場合、リソース/ aaa / bbb / ccc /、/ aaa / bbb /、/ aaa /、/に他のルールはありません。

テーブル

データストレージのテーブル。

検証機能：ユーザーはリソースに対する権限を持っていますか

例として、リソース/aaa/bbb/ccc/index.htmlに対するユーザーの作成許可を確認します。
最初に、グループツリーの写真を使用します。この上に、アルゴリズム（自分自身を含む）をよりよく理解するための例を示します。 グループNo. 1は、ディアブログループであり、すべてに対するすべての権利を持っています。 グループ12、13、15、10では、指定されたアクセス許可に必要なリソースに対してルールが設定されます。これにより、リソースが禁止されます。 グループ3、4、22では、≥以上のアクセス許可に必要なリソースに対してルールが設定されます。これにより、アクセスレベルは低下しますが、この例では依然として該当します。 つまり グループ1でリソースのアクセス許可がallに設定されている場合、グループ（たとえば）で3のアクセス許可が削除に設定されます。これは、この例で作成するアクセス許可セットよりも高くなります。

操作アルゴリズムは次のとおりです。

1. Usersテーブルに従って、このユーザーが属するグループのリスト（ aGroupsUsers ）をユーザーID（および識別子= 0-ゲスト識別子）で識別します。 この例では、これは次のグループのリストになります。
   
   ご覧のとおり、この例では、ユーザーはグループ2および子グループ23および13で定義されています。理論的には、ユーザーが親グループで定義されている場合、すべての子グループに適用されるため、グループ23および13でのユーザーの存在は冗長です。 ただし、実際にはこれは可能です（許可された各ユーザーが属する識別子0（ゲスト）のユーザーがいる場合のみ）。 それが私がそのような例を作った理由です。
2. 許可の表に従って、許可識別子の2つのグループのリストを定義します。a ）which <指定b）which≥指定。 たとえば、作成を有効にするには、次のリストが形成されます。a ） aDeny = [なし、読み取り、更新] b） aAllow = [作成、削除、すべて]。
3. リソースをコンポーネントに分割します。つまり、 リソース自体に加えて、すべての親を決定します。 たとえば、リソース/aaa/bbb/ccc/index.htmlについては、/ aaa / bbb / ccc / index.html、/ aaa / bbb / ccc /、/ aaa / bbb /、/ aaa /、/のリストが取得されます。 そして、 Resourcesテーブルから、指定されたリソースのリストの識別子（ aResources ）を決定します 。
4. ルールテーブルと段落3の識別子のリストに従って、特定のリソースのルールが定義されているグループのリスト（ aGroupsRules ）（+親リソース）を選択します。 この場合、結果は次のようになります。
   
   実際には、ユーザーが属する子グループで定義されているルールがある場合があります。 そして、彼らはサンプルに落ちます。 ただし、この例では、そのようなグループは存在しないと想定しています-とにかく、結果には影響しません。
5. ユーザーが属するグループのリストを選択しました（段落1を参照）。 次に、保護者の権利を考慮して、設定したリソースに必要な権利について、これらすべてのグループを確認する必要があります。 つまり 次のグループブランチを確認する必要があります（グループブランチは、現在からルート（悪魔）までのグループのリストです）。
   
   • 23、12、6、2、1
   • 13、6、2、1
   • 2、1
   • 38、27、17、8、3、1
   • 18、9、4、1
   • 20、10、4、1
   • 32、22、11、5、1
   さらに、ブランチの1つで権利のチェック結果が肯定的である場合は、すでに権利があるため、残りをチェックする必要はありません。 検索中に、禁止ルールが設定されたグループに切り替えた場合、このブランチをオフのままにして次へ進むことができます。 以下は、権利を決定するためのアルゴリズムです。 アルゴリズムの最後で、fAccessGroup変数には、リソースへのユーザーアクセスの結果True / Falseが含まれます。
   
   この例では、検索はリソースにアクセスできるため、「2、1」ブランチで終了します。
   また、このアルゴリズムによれば、悪魔の許可を変更することはできません。彼は、ディアブロという名前のおかげで、常にすべての権利を持っています。
   

いくつかのメモ

• 純粋に理論的には、アクセス許可テーブルは特に必要ありません。アクセス許可を通常の配列に格納できるためです（これを行う予定です）。 権限識別子の代わりに、ルールテーブルに権限の技術名（なし、読み取り、作成、更新、削除、すべて）を書き込むことができます。 ただし、誰かがテーブルにアクセス許可を格納する方が簡単である可能性があるため、そのようなテーブルを引き続き指摘しました。
• デフォルトでは、識別子0（ゲスト）のユーザーがゲストグループに含まれている必要があります。 すべての新しいユーザーをユーザーグループに含める必要があります。
• 各モジュールは、リソースのルールを追加します（ただし、これはおそらく実装の特定の各ケースに既に適用されており、アクセス制御には適用されません）。
• 「それは[ほとんど]正確にXXXシステムに実装されているからです」というスタイルでコメントを書きたい人のために：XXXシステムでの実装は、私が自分で書いたシステム（自分で書いたORMまで）を実装しているので、私には適していません権利の確認私はそれになります。 そのため、権利システムが実装されているシステムへの言及も歓迎しますが、このシステムを無駄にしたわけではないことを示すことはありません。
• 誰かが私が見落としている問題を見つけたら-コメントに書いてください。 これは記事の3番目のバージョンです。記事を書いた結果、アルゴリズムにエラーが見つかったため、前の2つは拒否されました。
• 私は、悪魔が何にも権利を持たず、権利が増加する場合にオプションを検討しました。 この場合、禁止されたコンテンツへのアクセスを誰かに許可する可能性は低くなります。 ただし、このアプローチでは、ユーザーにグループに権利を割り当てる権利を与えると、ユーザーは自分にフルアクセスを割り当てることができます。 最後に、悪魔は全能になると決めました 。

関連リンクのリスト：

• ACL：完璧なソリューションを探しています
• DIY ACL。 シンプルなアクセス制御システムの開発と執筆の歴史
• アクセスリスト（ACL）によるアクセス制御

ps あなたが短所を置くなら、少なくとも書く-何のために 。