2

コンテクスト

  1. 売り手がアイテムをリストするコマースマーケット
  2. オペレーションItem::setPriceがあります
  3. アイテムの販売者またはカスタマーサービス担当者は、アイテムの価格を変更できます。
  4. ＃3のセキュリティチェックは、セキュリティチェックの対象範囲を最大化するために、アイテムのデータアクセス層の近くに実装されます。

多くの人がセキュリティを直交する懸念として話すのが好きですが、特にインスタンスレベルのセキュリティについて考えるとき、それはドメインモデルに容赦なく結びついているので、私は（現在？）それに参加していません。肝心なのは、私は実際、＃3のセキュリティ不変条件をコードで明示的に記述することを好みます（コードを介して、またはSpring Security ELアノテーションによって）。このようなセキュリティ不変条件は、ビジネスロジックの一部であると私は考えています。開発者の顔にもセキュリティが必要です。それは彼らの責任IMOと直交していません。

私は次のように書くかもしれません：

@PreAuthorize("hasRole('CSR_ITEM_WRITER') or #item.seller.id == principal.id')
public void setPrice(Item item, Money price) { ... }

これは、セキュリティモデルの進化に関して、ある程度の柔軟性の欠如を生み出すことを私は理解しています（しかし、それを間違えることの意味を考えると、それはそんなに悪いことですか？）

また、CS担当者が売り手になる必要があるアプローチについても説明しました。これには一定のクリーンさがあります（つまり、ユースケースではなく、ドメインを中心としたセキュリティモデルに焦点を当てています）。（NBは、誰かが別の人に代わって行動していることを検出するために十分な監査が実施されます）

意見？

4

2 に答える 2

0

私はあなたがそれを正確に正しくやっていると思います。セキュリティが直交する懸念事項であると言うとき、何に直交するのでしょうか? これがビジネス ロジックの一部であるべきだというあなたの意見は 110% 正しいです。

REP と SELLER の分離を維持します。どちらもユニークな役割です。この特定のケースではたまたま重複しています。

このコンテキストでのセキュリティの重要性のレベルを考えると、オプションに関連付けられた役割が与えられた場合に適切な結果を示す単体テストの嵐を書くことを期待しています。

于 2012-05-01T18:49:18.797 に答える
0

あなたがしていることは良い考えだと思います（私は現在似たようなことをしています）。

単純な注釈よりもいくつかの利点があるため、Spring Security の PermissionEvaluator コンポーネントを確認することをお勧めします (こちらを参照)。

  1. はるかにグローバルであるため、セキュリティメカニズムを簡単に変更できます
  2. セキュリティ評価は、監査ログ/監視/...
  3. Evaluator の実装は単体テストできます (アノテーションが機能するには実行中の Spring コンテキストが必要なため、統合テストでのみテストできます)

これまでのところ、このアイデアの直接的な欠点は見つかりませんでした。

于 2012-05-01T22:17:55.727 に答える