1

I have an enterprise system that is represented by a domain model, part of the requirement that the system should limit access to some of the features based on privileges of the logged in user.

Should I put these privileges validation inside my domain model? but there will be a problem that it doesn't know which user is logged in, how should I pass it to it?

Or

Should I put privileges validation at the level of presentation in the web application itself?

Sisyphus
  • 369
  • 2
  • 13
  • Duplicate of https://softwareengineering.stackexchange.com/questions/349062/authorization-checks-without-littering-them-in-code – David Brossard May 12 '18 at 15:13

1 Answers1

1

Should I put these privileges validation inside my domain model?

No. You should divide the method on the domain model suitably to allow the granularity of control you require. Then limit access to those methods with standard role based authentication.

eg: (psudocode based on c# mvc)

public class OrderController : Controller
{
    //this is for users
    [Authorize(Role="User")]
    public void DeleteMyOrder(string id)
    {
        orderService.DeleteMyOrder(id);
    }

    //this is for admins
    [Authorize(Role="Admin")]
    public void DeleteAnyOrder(string id)
    {
        orderService.DeleteAnyOrder(id)
    }
}
Ewan
  • 70,664
  • 5
  • 76
  • 161
  • 1
    But this way my domain model will depend on `AuthorizeAttribute` which is an MVC feature which will affect its protability, don't you think? – Sisyphus May 11 '18 at 11:33
  • I was perhaps oversimplifying my example, let me edit... – Ewan May 11 '18 at 11:33
  • So you do support the second option I have put in my original posting, which is to control access at level of presentation instead of business layer, I personally like it, it is easier to implement, but I feel it is wrong, since I will have to repeat this authorization code for each presentation layer that will use my business layer.... Am I being over idealistic? – Sisyphus May 11 '18 at 11:38
  • I wouldn't say that this is presentation layer, its security on a business layer. The key thing is its not in your business _LOGIC_ or rather it IS, but the way its represented, ie split into different methods, allows you to use standard third party role based security. – Ewan May 11 '18 at 11:42
  • for example, you could put the same role check, within the controller method, or within the order service. but if you did, by the time that code comes to execute you are already running your code. so if you made a mistake then you have allowed an attacker to bypass security. – Ewan May 11 '18 at 11:43
  • Security is a traversal. It does not belong to any specific "layer". It's a layer by itself. It goes from any actions users are (no)allowed to perform on the UI, all through the whole system up to the very end ( the access to the datastore). Moreover, security has its own layers. Ewan has been simplistic, but he's not wrong. – Laiv May 11 '18 at 14:11