8

I have an API which I'm exposing via REST and I'm deliberating about where to place the authorities restrictions.
I've read that there is a best practice about securing the service layer as it is the one doing the work and you don't know where it's going to get called but I'm not sure what's the best practice with respect to the WS layer.
One thought I have is that I need to have a very fine grained model of authorization on the service layer and a very coarse grained model of authorization on the WS layer as to minimize breaking the DRY principle on the one hand but still have some notion of defence in depth.

Example:

For the Users resource there is a UserWS and a UserService. Admins can create/update/delete users and Users can read about other users.
Assuming the UserWS is bound to %root%/users I will define an intercept-url for that url with the ROLE_USER authority which just says that you have to be a user to get there but the service layer itself will specify the specific authorities for the relevant methods.

Other options are:

  • Place the same authorization requirements on both the service and the WS-
    Pro- You'll filter out as early as possible intruders (and save for example the conversion of parameters if you're using spring mvc)
    Con- Duplication of configuration is a maintenance issue and is error prone => security issue

  • Place the authorization requirements only on the WS-
    Pro- Filter as soon as possible if comming from the WS
    Con- The service layer might be used from different contexts

  • Plate the authorization requirements only on the service-
    Pro- No Duplication
    Con- Overhead of allowing "bluntly" inept request to arrive to the service layer

Would really appreciate any feedback about the options

Ittai
  • 5,625
  • 14
  • 60
  • 97

2 Answers2

6

Ittai, Using the very same security mechanism at both the WS and Service layer is considered as repeating yourself - and it requires maintenance at these two levels. Not having any security at the WS layer is a bad thing - since you actually let anyone to get into your system ( even if you'll block them later on - many see that as a bad thing ). In short, I think that you should mix up these two - use a very rough mechanism at the WS layer and a very strong one at the service layer, That's how you wont repeat yourself and wont have to maintain the code in both places (as it not the SAME security level ); and you'll be able to filter out undersized users as soon as possible but still have a very high security level where it should be placed.

Noam
  • 3,049
  • 10
  • 34
  • 52
0

I'd say both if you have the time, only service layer if not.

Its always good to secure presentation and services because if you ever expose your services to something else other than the presentation (you expose a web service for instance), you'll have your security in place and already done.

Also if someone finds a way to bypass your presentation layer (say you have tiers and your services run on a remote machine), you'll still have your security in place.

Simeon
  • 7,582
  • 15
  • 64
  • 101
  • thanks for your answer, But like I said, if I just have the SAME authorities on both then it's duplication and is prone to errors (hence security liability). Assuming I annotate the service layer, what do you think I should place on the WS and why? Thanks – Ittai May 16 '12 at 08:53
  • IMHO you just need to have a single service that has the logic and have a UI delegate for that service and a WS delegate. This way you just need to annotate the concrete service. In general, if you don't want to have duplication you have to secure the component that holds the actual logic. – Simeon May 16 '12 at 09:10