0

spring ACL を使用して、件名に対するいくつかのアクションのアクセス許可を構成できます。私のアプリケーションでは、サブジェクトへのアクセス権をカスタマイズする必要はほとんどありません。だから私はデフォルトの依存関係のためにACLを埋める必要はありませんが、ACLが空の場合は特別な指示が必要です.

たとえば、

branch1
|-doc1
|-doc2
|-doc3
branch2
|-doc1
|-doc2
|-doc3

user1 belongs to branch1
user2 belongs to branch2

デフォルトの実装では、 user1はbranch1のすべてのドキュメントにアクセスできる必要があります(ACL が空の場合)。user2 -> branch2 . 場合によっては、user1 に特別なアクセスが必要になります。彼はbranch2.doc3にアクセスする必要があり、 branch1.doc2に対する制限が必要です!

ACL 推奨事項と同様の方法でソリューションを実装しようとすると、対応するブランチの各ドキュメントに各ユーザーのアクセス許可を追加する必要があります。この方法は、正規化 && 許可のために非常に醜いです。したがって、相互参照のみに使用される ACL ロジックと、デフォルトのアクセス許可により、すべてのユーザーが同じブランチ内の各ドキュメントにアクセスできるようにするソリューションを実装したいと考えています...

デフォルトでは、@PostAuthorizeや@PreAuthorizeなどのメソッド アノテーションをhasRole、hasPermissionなどのチェックと共に使用できますが、パーミッションによる制限がロールよりも強い条件を構築したり、リレーション ユーザー ブランチに基づいてリクエストにフィルターを適用したりすることはできません。

このアイデアは実装できるはずですが、対応する説明や実装方法のトリックの例が見つかりませんでした...

4

1 に答える 1

0

最初に推奨事項を作成します。

私のアプリケーションでは、サブジェクトへのアクセス権をカスタマイズする必要はほとんどありません。だから私はデフォルトの依存関係のためにACLを埋める必要はありませんが、ACLが空の場合は特別な指示が必要です.

これが良いアイデアかどうかはわかりません (してはいけないと言っているのではなく、注意を促しているだけです)。これには特別なロジック (これらの人はこの方法で承認され、それらの人はその方法で承認される) が必要となり、アプリが複雑になります。あなたが気付いていない可能性のある Spring Security ACL について説明し、別のアプローチを提供します。

親 ACL の概念を使用して、求めているものを解決できます。ドキュメントから：

ACL_OBJECT_IDENTITY は、システム内の一意のドメイン オブジェクト インスタンスごとに情報を格納します。列には [...] 親、ドメイン オブジェクト インスタンスの所有者を表す ACL_SID テーブルへの外部キー、および ACL エントリが任意の親 ACL から継承できるかどうかが含まれます。ACL パーミッションを格納するドメイン オブジェクト インスタンスごとに 1 つの行があります。

このように、branch2は acl をbranch2.doc3持つことができ、 から継承する acl を持つことができますbranch2。

これを使用して、親をチェーンし、デフォルトの ACL を持つルート オブジェクトを持つことができます。つまり、すべてのブランチには、デフォルトの ACL を持つルート オブジェクトの親があります。

このアプローチを使用する利点は、複雑さが増すにつれて簡単に拡張できることです。それでも単一の方法を適用し、任意の複雑なロジックを使用して ACL を定義できます。

于 2016-09-13T13:07:48.433 に答える