Should my service layer work for any user, or restrict itself to the currently authenticated user?

Question

This is a fundamental design question about the service layer in my application, which forms the core application functionality. Pretty much every remote call reaches a service sooner or later.

Now I am wondering if

• every service method should have a User argument, for which the operation should be performed
• or if the service should always query the security implementation, which User is currently logged in, and operate on that user

This is basically a flexibility vs security decision, I guess.. What would you do?

Answer 1

I think you should decide which methods will need a user argument and which will need a logged in user. You'll get the following method types as a result for this:

1.) Type1: Method is best to have a User argument.

2.) Type2: Method is best to not have a User argument.

3.) Type3: A combination of 1.) and 2.)

The solution of 1.) and 2.) is simple, because they are trivial cases.

The solution of 3.) is to overload the method to have a version of 1.) type and another version of 2.) type.

Answer 2

I try to look at security as an aspect. User argument is required for things other than authentication as well. But, I think control should reach the service layer's more important methods only if the user has been authenticated by some other filter. You can't have every method in the service layer querying the security module before proceeding.

Answer 3

There is also a DoS aspect to consider.

One approach is to offer (depending on your context) a publicly available instance / entry point to the services, on a well throttled set-up; and a less restricted instance to an internal trusted environment.

In a similar vein, if you identify where traffic originates you can (or should) be able to provide better QoS to trusted parties.

So, I would possibly keep the core system (the services you write) fairly open / flexible, and handle some of the security related stuff elsewhere (probably in the underlying platform).

Just because you write one set of services doesn't mean you can only expose those in one place and all at the same time (to the same clients).