現実の世界では、なぜメソッドレベルのセキュリティを実装する必要があるのですか？
ユーザーがユーザーインターフェイスにアクセスする（したがって、メソッドに直接アクセスできない）Webアプリケーションまたはデスクトップアプリケーションがあります。
それでは、アクセスメソッドは、ここで直接どこに現れますか？
編集：私は春のセキュリティで実験しているので、この質問をし、メソッドにアクセスするためのユーザーの承認を見ています。
何かのようなもの ：
@ROLE_ADMIN
public void update() {
//update
}
回答:
適切に設計されたアプリケーションでは、バックエンドとフロントエンドは切断されます。バックエンドセキュリティシステムは、特定のフロントエンドがセキュリティを正しく処理することを想定できないため、それ自体を処理する必要があります。
コントローラーのアクションへのロールベースのアクセスについて話していると思います。つまり、MVCアーキテクチャでは、Controllerクラスの各メソッドは個別のアクションです。私が使用したほとんどのMVCフレームワークでは、メソッドレベルとクラスレベルの両方で特権を割り当てることができます。つまり、クラスレベルで属性/注釈を適用でき、そのコントローラーのすべてのアクションに対応するロールが必要になります。
ロールベースのアクセスのよりきめ細かい制御に関しては、次のことを考慮してください。
好むと好まざるとにかかわらず、Ruby on Railsが数年前に電波を放ったとき、ほぼすべてのMVCフレームワークが基本的な設計アプローチをコピーしました。以前は、アクションは個別のクラスでしたが、アクションロジックは小さく、焦点が絞られる傾向があるため、クラスのオーバーヘッド全体が過剰になります。コントローラのメソッドをページのアクションにマッピングすることは、実際には非常に理にかなっています。多くの人がどの役割がどの機能を実行できるかをきめ細かく制御する必要があることを知ってください。
Mike Wiesnerは、SpringSourceのプレゼンテーションであるSpring Security 3 / 3.1で、Tomcatや他の多くのサーブレットコンテナに、ユニコードでエンコードされたときに「../」を正しく認識できないバグがあることを思い出させました。単純な等価テストはJavaで失敗しますが、ファイルシステムの上位ディレクトリに変換されます。
セキュリティは難しく、複数のレベルのセキュリティがあり、回避の試みをブロックする可能性が向上します。メソッドレベルのセキュリティはクラス内で直接コード化されているため、AOP拡張後、メソッドを呼び出すときは、常にセキュリティチェックを前に呼び出します。
ここで、パブリック、プライベート、および保護されたメソッドについて話していると思いますか？
もしそうなら、それらはセキュリティの目的のために存在しません。これらは、ソフトウェアを適切にモジュール化することを容易にするために存在します。（彼らがそれで成功するかどうかは、私が他の人に任せる議論です。しかし、それは彼らの目的のビジョンです。）
ライブラリを配信すると、後で別のバージョンのライブラリを配信し、プライベートとしてマークされたものを必要なだけ変更することができます。対照的に、もし私がそれらのものをプライベートとマークしていなかったら、誰かがどこかに直接アクセスしている可能性があるので、ソフトウェアの内部を変更することはできません。確かに、理論的には、文書化されたAPIを使用しないのは彼らのせいです。しかし、クライアントは、私のソフトウェアのアップグレードがソフトウェアを壊したという私のせいだと感じます。彼らは言い訳を望んでおらず、それを直したいのです。しかし、最初にアクセスを許可しない場合、私のAPIはAPIとして意図されたパブリックメソッドであり、問題は回避されます。
あなたが話している可能性のある2番目にありそうなことは、Javaのセキュリティモデルです。あなたがそれについて話しているなら、それが存在する理由は、Javaの元々のビジョンは、サードパーティのプログラム（ブラウザなど）の内部で対話的に動作するために、おそらく信頼できないアプレットを送信する人々に関係していたからです したがって、セキュリティモデルは、悪意のあるアプレットからユーザーを保護することを目的としていました。したがって、心配して保護するセキュリティ上の脅威は、ロードされる可能性のある他のソフトウェアと対話しようとする信頼できないアプレットです。