4

私は春のセキュリティを学んでいますが、その柔軟性に混乱しています。

タグでルールを定義することでURLを保護できることはわかっていますが、メソッドを保護できる@secureアノテーションがあることがわかりました。次に、ドメイン（またはPOJO）による読み取り/更新を保護するための他の注釈があります

したがって、URLを保護するためのルールを作成する以外に、一般的なアクセス許可/役割/ユーザーのWebアプリケーションを開発する場合、メソッドを保護するために@secureアノテーションを使用する必要がありますか？

ej。

  1. ユーザーは制限付きURLを入力します
  2. アプリケーションはログインを要求します
  3. アプリケーションは、ロールがURLにアクセスできるかどうかを確認します
  4. ユーザーは「新規追加」オプションを選択します
  5. そのユーザーがメソッド「addNew（）」を呼び出す権限を持っているかどうかをもう一度確認してください。

または、ステップ4または5のいずれかが冗長です。

私の英語についてごめんなさい

4

2 に答える 2

5

たとえば、HttpSecurityの流暢なAPIを見るとわかるように、URLレベルのセキュリティは非常に豊富です。ただし、Springセキュリティでメソッドレベルのセキュリティを使用する理由は少なくとも2つあります。

  1. Jonathan Wが指摘しているように、セキュリティで保護されたロジックには、http以外のコネクタタイプを介してアクセスできる場合があります。たとえば、ロジックはEJBを介して公開される場合があります。

  2. REST APIの場合、同じURIが異なる許可ルールを持つ異なるhttpメソッドをサポートする場合があります。たとえば/myapi/order/{id}、GETとDELETEを受け入れる場合があり、DELETEはスーパーバイザーロールを持つユーザーのみが使用できる場合があります。URLセキュリティを介してそのルールを指定することはできませんが、たとえば@Secured("Supervisor")DELETEを処理するメソッドを使用するなど、メソッドセキュリティを介して指定することはできます。

于 2016-09-01T20:38:36.010 に答える
2

これが覚えておくべき最も重要なことです。ユーザーは、生のHTTPGETまたはPOSTを介してWebアプリケーションに何でも送信できると想定する必要があります。これは「クライアントを絶対に信用しない」とも呼ばれます。したがって、上記の手順4と5は冗長ではありません。たとえば、ステップ5に到達した場合、ステップ3が発生したことを確認することはできません。

とはいえ、ユーザーがURLだけで何をしようとしているのかを正確に区別でき、別のアクセスチャネル（キューやRMIなど）を介してメソッドを保護する必要がない場合は、保護するだけで解決できます。 URL。ただし、これに関係なく、メソッドレベルのセキュリティを設定することは悪い考えではありません...いくつかの理由があります。まず、ロジックが実行されている場所で期待される役割を文書化します。これは、開発時に行われた仮定を理解するのに役立ち、将来の拡張を行うのに役立ちます。次に、将来のアクセスチャネルを介したセキュリティが誤って侵害されないようにすることができます。

于 2012-05-31T03:49:36.483 に答える