Adding authentication and filtering in the service layer

Question

I am currently developing a simple web-based application that consists of various layers:

Model Layer

Performs simple CRUD operations and provides access to the databes. Implements functions such as get_invoice(), create_invoice(), edit_invoice() and so on.

Service Layer

Consolidates operations such as pay_invoice(), cancel_invoice(), and so on. The service layer is meant to be used by the various presentation layers in single, concrete actions. To do this, it may use more than a single model to accomplish something.

Presentation Layer

Comprised of controllers and views, renders the results and generates forms. The catch here is that there may be more than one presentation interface-- the application boundary lies at the service layer:

• Web-based UI
• API
• CLI (command line)
• iOS app

The question

The app must control who can access what at all times. To do that, I am adding security checks and authentication directly in the service layer. That way, a call to pay_invoice() will always check if the given user is allowed to perform that operation.

Is this correct? Should I be requiring every call to the service layer to be associated to a user ID and a set of permissions?

This seems straightforward for write operations like paying invoices. However, how do I go about implementing read operations? For example, a user might not have access to all invoices, but some background tasks might need that info from the service layer.

Another example is that a user should not have access to a full list of other users, but might need to have a dropdown list with just names (to assign a task, for instance).

It is worth noting that the app also provides public access to some data, like the login page or viewing an invoice PDF (no session yet). What happens in those cases? Should I create some sort of guest access to feed the service layer with?

In summary:

• Is it correct to require a valid user at the service layer?
• Would I need to add another layer in front that separates operations from user-based actions?
• How should public access queries be treated?

Any specific reading on this is appreciated-- I haven't found much.

Answer 1

Is it correct to require a valid user at the service layer?

It's correct to require valid user (and to authenticate it) in every operation that requires an authorized user.
The service layer that you describe here do sound like it provides API to operations which are sensitive and should be performed by an authorized user. (paying, cancelling an invoice etc.)

---

Would I need to add another layer in front that separates operations from user-based actions?

The background task that you mention can be solved in a direct manner (i.e. if the background task doesn't need to pass through the service layer and can directly access db), but it may introduce problems down the road.
Restricted access to the names shall be solved by an authorization mechanism (i.e. a user with certain permissions can do X).
If the operations (background tasks you mentioned) need to pass through the service layer, I suggest that you handle it in the same authorization process (the background tasks will have certain permissions which will be enforced as in users).

---

How should public access queries be treated?

As a user with the least permissions you choose to define.