Spring security providing a level of service, a level of web service, or both?

Question

I have an API that I am viewing through REST, and I am discussing where to place permissions. I read that there is a best practice for providing a level of service because it does the job and you don’t know where it will be called, but I’m not sure what the best practices are for the WS layer.
I believe that I need to have a very thin authorization model at the service level and a very rough granular authorization model at the WS level in order to minimize the gap of the DRY principle, on the one hand, but still there are some concepts of deep protection.

Example:

For the Users resource, there is UserWS and a UserService . Admins can create / update / delete users, and users can read about other users.
Assuming UserWS bound to %root%/users , I define an intercept-url for this URL with ROLE_USER authority, which simply says that you must be a user in order to get there, but the service level itself will indicate specific privileges for the corresponding methods .

Other options:

• Put the same authorization requirements for both service and WS-
  Pro- You filter out attackers as early as possible (and save, for example, parameter conversion if you use spring mvc)
  Configuration configuration is a maintenance problem and is a prone error => security issue

• Put authorization requirements on WS- only
  Pro-Filter as soon as possible if you set off with WS
  Con- Service level can be used from different contexts.

• Name the authorization requirements only on the service. Pro-no duplication
  Con-Overhead, allowing a "roughly" inept request to arrive at the service level

It would be very helpful to get feedback on options.

Answer 1

Effei, Using the same security mechanism both at the WS level and at the service is considered repetitive - and this requires service at these two levels. The lack of security at the WS level is bad, because you are actually allowing someone to log into your system (even if you block them later - many people think this is bad). In short, I think you should mix these two - use a very crude mechanism at the WS level and a very strong one at the service level. The way you will not repeat yourself and will not support the code in both places (as it is not the same level of security); and you can filter out the undersized users as soon as possible, but still have a very high level of security where it should be placed.

Answer 2

I would say that if you have time, only the service level, if not.

It is always useful to protect the presentation and services, because if you ever provide your services to something other than a presentation (for example, you open a web service), you will have your security in place and already done.

Also, if someone finds a way around your presentation level (let's say you have levels and your services running on a remote machine), you will still have your security.