在MVC + DDD + Repository Pattern项目中应用安全性的内容是什么？

Question

I have the broad requirement for a flexible, reasonably granular security system, allowing us to customize what a given role or user is allowed to do within the system.

Facing this requirement, I must choose what objects, classes, or items within the architecture the security should use as its building block - eg. if a role us granted access to X, then what is X? An entity, a controller action, an item in a custom list of objects etc.

Options I am considering:

1) Grant by CRUD action on Entities (eg. a user could be granted Create/Read/Update access to the Account entity, and Read access to the Invoice entity, etc)

2) Grant by CRUD action on Entities , with RU actions to individual Entity Properties (eg. access to update specific fields) - could be simplified with "property groups" identified by attributes on the entities

3) Grant by Repository & Repository Function (eg. permitted to call to AccountsRepository.Get(...) or AccountsRepository.GetList(...) etc)

4) Grant by MVC Controller + Action (eg. permitted to access /Accounts/Index or /Accounts/Update/X etc)

5) Grant by a custom list of "Security Objects" which can be tied to arbitrary things within the architecture

Option (5) gives the most flexibility but least generic implementation. Option (4) is attractive as the security items will closely reflect the user interface, but means that the Domain is not securing access and security would not be applied in non-web interfaces.

What is your opinion & experience designing a security pattern in MVC + DDD + Repository pattern?

Answer 1

Designing authorization is the same regardless of DDD, REpository, MVC, CQRS ,[insert whatever trend of the day].

You want the security check to be done when an action (not related to controller action) happens. You check if the user has the right to do a certain action within a specific context. In your case it's really is a controller action and the easiest way is via an ActionFilter (which i think can be reused with the WebApi as well).

The Domain model business concepts, behavior and use cases, the repository deals with persistence, let the security be its own layer which will care about users, rights and contexts.

Even in the use case mentioned by Hippoom, it's still a security layer concerns which will have its very own security rules, similary to a validation layer which validates input data according to some predefined rules.

Answer 2

The most common security mechanism only requires role and resource. In this case, Option (4) seems to be the most common solution I've seen, therefore there should be a few mature secutiry frameworks on your platform.

The security things are inevitablly mixed into the domain model if the security granularity is on the domain objects. I think it is usually unnecessary.

On the other hand, some security requirment need business context, for example, an operator cannot manipulate a trade more than $1000 while his supervisor can. Honeslty, I have no expierence on how to implement this, but I personally prefer building the security implementation in another bounded context from the core domain.

Answer 3

I think this is one of the kind of questions a security framework designer ask himself when is thinking about what facilities he can offer in the filed of the Authorization problem.

I'd suggest you to look at the design or implementation of actual security frameworks available for your platform.

I know only the Java-based Spring Security and Apache Shiro.

They usually come with facilities for every authorization requirements and, as for your question, they can offer you a solution at all levels of granularity:

• Resource level (when you are not interested on which object instance apply the security check);
• Instance level (you control access to a specific instance of an object);
• Attribute level (you control access to a specific field of a specific instance of an object).