Should security issues be present in the domain model?

Question

I am working on a Winforms project (.NET 4), which is based on MVVM freely. For security, the application authenticates itself in Active Directory, and then uses role-based security to determine access rights to various parts of the program. In most cases, security is implemented using the PrincipalPermissionAttribute principle:

<PrincipalPermissionAttribute(SecurityAction.Demand, Role:="Managers")> _ Public Sub Save() Implements IProductsViewModel.Save mUOW.Commit() End Sub 

As you can probably tell from the interface implementation, this particular Sub is in the ViewModel. The PrincipalPermissionAttribute function checks whether the current user (Thread.CurrentPrincipal) is in the Manager role.

Which leads to my question: should security checks (e.g. above) be performed in the domain model?

I have two conflicting opinions when I think about it myself:

1) Do not let the domain model ignore as many problems as you can reduce complexity and dependency. (Keep safe, possibly implemented in ViewModel).

2) The domain model is, in a way, a place where "the dollar stops here." If I implement security in a domain model, then I know that even if security in another slot fails, the domain model must catch it.

So what can I say, security in the domain model or not?

Answer 1

Personally, I think this problem seems to belong to the service layer. Presumably, the application will persist through the service level to one degree or another in order to reach the domain, and you could easily have a service other than the domain to verify the user's role before committing.

The reason I will do it this way is based on the theory that the closer you get to the core of the domain, the more expensive the call stack will be. Preventing higher-level domain abuse / misuse means better responsiveness and cohesion.

In addition, suppose the requirement is changed, while someone from a different role can now perform the same operation. Maintaining all these parameters in the service level means that you also do not change the code, which should be digested less frequently. At least in what I did, the positive departure from this is that the closer you get to the kernel, the less likely the code should change. This means that you also reduce the change in your change to “ripple” in other areas that you did not plan.

In a broader sense, and nothing personal, I do not like the idea of ​​entering data of any kind in the ViewModel. ViewModel is intended to represent an implementation-specific model. These objects should ideally be as light as possible. If, for example, a change is made to a product, this change will go through the service, and then to the repository, where it can be registered in the unit of work, pending completion.

Answer 2

There are 2 types of security.

One that is purely technical is something like "all traffic should go through https" or "only a specific service should relate to the database" or "only a specific process should be able to relate to the file system / registry".

The second that is associated with the domain. Something like "only a user with the role of Secretary can access the payment history" or "unauthorized users should not have access to accounting materials."

First you need to separate from the domain. The second should live inside the domain.