ACLを実装するためのベストプラクティスとは
エンドユーザーに対して非表示にする必要がある特定のメニュー項目を含むWebサイトがあります。
WebサイトのPHP=フロントエンドとJavaとSpringがバックエンドにあり、VMインフラストラクチャ。ただし、完全なテクノロジースタックはレガシーシステムであり、完全に文書化されていないため、完全には理解されていません。
アクセス制御に基づいてサイトと機能を保護する必要があります-ユーザーはグループにマップされ、グループはさまざまなメニュー項目（機能）にアクセスできます。また、管理者が機能とグループのマッピングを変更するためのインターフェースを提供する必要があります。また、さまざまな読み取り/書き込みメソッドアクセスのレベルを細かく制御する必要があります。
ACLが必要だと思います。そのような要件のベストプラクティス設計とは何ですか？
オプションと質問：
- DB-マイナスの問題は次のとおりです。古いスタイルで、独自のID管理機能を作成すると、すべての欠点と複雑さが伴います。
- LDAP-否定的な問題：繰り返しになりますが、私自身のID管理システムですが、おそらくDBよりも単純ですが、グループへの機能レベルのマッピングがどのように機能するのかわかりません。 LDAPプロバイダーは、特定の機能へのグループのマッピングを提供しますか（つまり、メニュー項目「アカウント」が与えられた場合-私は、ファイナンスのみがアカウントメニューを表示できるようにしたい）
- OpenAMおよびIdentity Managementを外部化する同様のソリューション–それは機能しますか？私はこれについて読んでいます–理解している認証ですが、理解していない細かいレベルの認証です。データソースとして構成されたLDAP製品が必要なようですが、OpenAMは同じであるため、上記のオプション2に比べて何を提供していますか？ OpenAMを使用すると、アイデンティティサービスを構成したように見えますが、コンテナーレベルでセキュリティを確保できます。つまり、Webサーバーとアプリサーバーですが、独自のログインページを提供します。現在のログインページと統合するようにスタイルシートにアクセスするように構成することは可能だと思いますが、これらのタイプの製品のいずれかでそれが可能であることを確認するためにそれを行った人はいますか？また、これは私のACL要件ですか？これは最良の設計ですか？LDAPやアプリの構成と比較して、セットアップはどれほど複雑ですか？
さらに質問：
- LDAPソリューションが最も推奨されますか？
- Apache LDAPのオープンソース製品について何か提案はありますか？何か良い/簡単に管理されていますか？グループへの関数の操作に可能なインターフェイスはありますか？ -LDAPは、グループへの関数/メソッドの細粒度レベルへのマッピングを許可しますか、それともアプリケーションで行われるものですか？特にこの部分は紛らわしいです。誰かがこれについて良いリソースを提供できれば、それは良いことです。
外部化された承認が必要です。クレームベースの承認（Microsoft固有）またはより広範な属性ベースのアクセス制御（ABAC）。
ABACは最近NISTによって定義されたものであり、そのレポートをダウンロードできます ここ 。
あなたの質問では、LDAPとグループを指しています。次に、機能をグループ/ロールに関連付ける必要があることを説明します。 LDAP、ロール、およびグループは、属性を表します。他のソース（データベースなど）から取得することもできます。不足しているのは、承認ロジック、つまりグループと関数の間のマッピングです。
ABACでは、そのロジックは承認ポリシーとして表現されます。 OASISには、XACML（eXtensible Access Control Markup Language）と呼ばれる標準があります。 XACMLでは、属性を使用して、どのアクセスを許可または拒否するかを定義します。
例えば：
役割マネージャーとグループFinanceを持つユーザーは、financeメニューを表示できます。
私はこれをIdentity Managementに分類しません。これはアクセス管理の質問です。アクセス管理ソリューションを外部化することをお勧めします。間違いなく、LDAPをストアとして使用しないソリューションについては知りません。
きめの細かいアクセス制御は、同じページまたはURL内に表示される要素へのアクセスを定義します。クエリ文字列を無視してページレベル、つまりhtml、jsp、phpページでのみサポートする粗い粒度のアクセス制御ソリューションとは異なり、細かい粒度のアクセス制御をサポートする製品では、クエリ文字列パラメータを持つURLを「アクセス管理」できます。パラメータまたはその他のボタン、ページ内のリンク。
1つの解決策は（アクセス管理ソリューションがきめ細かいアクセス制御を提供しないと仮定します-多くはそうではありません）、アクセス管理製品とカスタムコードを組み合わせて、きめ細かいアクセス制御を実装することです。アクセス管理製品でカスタムグループ/属性を定義します。これらのカスタム定義には、トラバース、読み取り、書き込みアクセスが必要です。したがって、たとえば一部のボタン/リンクは、同じhttp URLの管理者にのみ表示されます。また、カスタムデータベースで同じ値を定義し（必要な場合）、それらをユーザーの権限/タイプとカスタムグループにマップします。
ユーザーがWebサイトにログインするときに、ユーザーのアクセス権をhttpヘッダーとしてWebサイトに渡します。これらのヘッダーを読み取り、これらの値を解析し、ユーザータイプと権限に基づいて、ユーザーのボタン/リンクを表示します。例えばヘッダーに属性としてRが含まれ、ユーザータイプが管理者でない場合、Rの基準を満たすがマネージャーの基準を満たさないボタンは表示されません。これはデータベースで検索できます。
上記のソリューションは、きめの細かいアクセス制御をサポートするアクセス管理ソリューションを取得できた場合は関係ありませんが、コストが問題になる場合は、上記のソリューションを簡単に実装できるはずです。