Why do we need method level security?

Question

In the real world , why do we need to implement method level security ?

We either have a web application or a desktop application , where the user accesses the user interface (and therefore directly cannot access the method) .

So where does accessing methods directly come into picture here ?

edit : I ask this question because I am experimenting with spring security , and I see authorizing users for accessing methods .

something like :

 @ROLE_ADMIN
public void update() {
      //update
}

Answer 1

In a properly designed application the backend and frontend are disconnected. The backend security system can't assume any specific frontend will correctly handle security, so it has to handle it itself.

Answer 2

I assume you are talking about role based access to actions in a controller. I.e. in an MVC architecture each method on a Controller class is a separate action. Most MVC frameworks I've used allow me to assign privileges at both the method level and the class level. That would mean I can apply an attribute/annotation at the class level and the corresponding role would be required for every action in that controller.

In respects to more fine grained control for role based access consider this:

• It's convenient to group all actions around a resource together. I.e. your Create/Read/Update/Delete (CRUD) actions for articles, accounts, etc. This makes REST style APIs easier to write and maintain.
• Many systems have different credentials/roles required for Create/Update/Delete actions than they do for Read actions.
• If all user account actions are in one controller, you want to allow anyone to log in, but only certain people to create new accounts or assign roles.

Like it or not, when Ruby on Rails hit the airwaves a few years ago, just about every MVC framework copied its fundamental design approach. It used to be that actions were separate classes, but action logic tends to be small and focused so a full class overhead is overkill. Mapping a method on a controller to the action for a page actually made a lot of sense. Just know that many people need fine-grained control over which roles can perform what functions.

Answer 3

Method level security is useful for two main reasons:

• as another layer of security (in addition to other layers)

• in cases where it's more convenient or logical to have permissions in method level consider a case where different users can perform the same "direct" actions (so client security isn't relevant). but in some cases their action may trigger a behavior you wish to limit - in this case method level security may be a relevant solution.

Answer 4

Mike Wiesner reminded in this SpringSource presentation, Introduction to Spring Security 3/3.1, brought the example that Tomcat, and many other Servlets containers had a bug that failed to properly recognize "../", when encoded in unicode, in a way that a simple equals test would fail in Java, but would translate to the upper directory in the filesystem.

Security is hard, multiple levels of security, will improve the chances to block circumvention attempts. Since method level security is directly coded inside the class, after the AOP augmentation, when you call the method, you'll always call the security check before.

Answer 5

I presume that you are talking about public, private and protected methods here?

If so, then they don't exist for the purpose of security. They exist for the purpose of making it easier o guarantee that software is properly modularized. (Whether they succeed in that is a debate I'll leave for others. That is, however, the vision of what they are for.)

Suppose that I deliver a library, then I am free to later deliver a different version of the library and change stuff marked as private as much as I want to. By contrast if I had not marked that stuff private, then I would be unable to change any internals of my software because someone, somewhere, is probably accessing it directly. Sure, in theory it is their fault for not using the documented API. But the client will perceive it as my fault that my software upgrade broke their software. They don't want excuses, they want it fixed. But if I don't let them have access to begin with, then my API is exactly the public methods that I intended to be my API and the problem is avoided.

The second most likely thing that you could be talking about is Java's security model. If you're talking about that, then the reason that it exists was that the original vision for Java involved people sending possibly untrusted applets to work interactively inside of third party programs (eg browsers). Therefore the security model was meant to give users some protection against malicious applets. Therefore the security threat to worry about and protect against is untrusted applets trying to interact with other software that might be loaded.