3

ACL を保護されたリソースに接続する最良の方法は何ですか?

1) 保護されたリソースはその ACL への参照を保持する必要がありますか?

interface AclHolder {
    Acl getAcl();
}

これは簡単ですが、オブジェクトがデータベースに存在する場合、アクセス権をチェックする前にオブジェクトを構築する必要があります。

2) Spring Security は、完全修飾クラス名とオブジェクト ID を持つメカニズムを使用して、ACL を外部にアタッチおよび取得します。特定の基準では複数の ACL を選択できないため、n+1 選択の問題が発生する可能性があります。リファクタリング中にクラス名が変更されると、このシステムが壊れる可能性があります。

3) もう 1 つの方法は、保護されたリソースへの参照を ACL 内に格納することです。遅延ロードを使用すると、保護されたリソースをデータベースからロードせずに ACL をチェックできます。

class Acl<T> {
    @Lazy public T protectedResource;
    // acl methods ...
}

4) 各オブジェクトはセキュリティ記述子を持つことができます (Windows のように):

class SecurityDescriptor<T> {
  public Acl acl;
  @Lazy public T protectedResource;
  // ...
}

何が良いですか？

暫定的な解決策:ドメイン オブジェクトは AclHolder インターフェイスを実装でき、ドメイン オブジェクトに影響を与えずに ACL をアタッチすることもできるため、AclHolder インターフェイスを実装します。

4

1 に答える 1

0

スプリングセキュリティACLの実装にはキャッシュが組み込まれており、キャッシュがウォームアップされると、スプリングセキュリティアノテーションを使用して実装を強制する場合、ACLを取得する方法は主に特定のオブジェクトインスタンスに対して行われます。したがって、実際にはn+1の問題は発生しません。さらに、jdbcベースです。
ドメインオブジェクトのクラス名の変更は問題になる可能性がありますが、ここでもacl_classテーブルにはクラスIDが格納されており、本番システムのメジャーリリース間でそのレベルのリファクタリングが行われるため、管理するには適度に小さくする必要があります。Spring-security acl実装は、邪魔にならない方法で迅速なacl実装を行うための合理的な選択です（つまり、ドメインモデルは、主にアプリケーション層の懸念事項であるセキュリティに依存しません）。

于 2013-02-15T17:30:06.243 に答える