Should security concerns be present in the domain model?

Question

I'm working on a Winforms project (.NET 4) that is based loosely on MVVM. For security, the application authenticates against Active Directory and then uses role based security to determine access permissions to different parts of the program. Security is implemented with the PrincipalPermissionAttribute in most places, like so:

<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 specific Sub is in a ViewModel. The PrincipalPermissionAttribute is checking to see if the current user (Thread.CurrentPrincipal) is in the Manager role.

Which leads to my question: Should security checks (such as above) be done in the Domain Model?

I have two conflicting views when thinking about it myself:

1) Keep the domain model ignorant of as many other concerns as you can to reduce complexity and dependency. (Keep security out, perhaps implemented in ViewModel).

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

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

Answer 1

There are 2 kinds of security.

One which is purely technical - something like "all traffic should go through https" or "only specific service should touch database" or "only specific process should be able to touch file system/registry".

Second which is tied up with domain. Something like "only user with role Secretary can access payment history" or "unauthorized users should not be able to access accounting stuff".

First one should be decoupled from domain. Second one should live inside domain.

Answer 2

Personally, I find this concern seems to belong in the service layer. Presumably, the application will persist through the service layer to one degree or another in order to reach the domain, and you could easily have a non-domain service to verify the user's role prior to the commit.

The reason that I would do it in this fashion is based on the theory that the closer you get to the core of the domain, the more expensive the call stack has become. Preventing abuse / misuse of the domain at a higher level means better responsiveness and cohesiveness.

Additionally, assume that the requirement changes, whereas someone in another role can now do the same operation. Maintaining these all in the service layer means that you are also not changing code that should be churning less often. At least in what I have done, the positive takeaway from this is that the closer to the core you get, the less likely code is to change. This means that you also reduce the change of your change to "ripple" to other areas that you did not intend.

On a broader concern, and nothing personal, I do not like the idea of putting data access of any sort in the ViewModel. The ViewModel is intended to be a representation of the model, specific to an implementation. These objects should be, ideally, as lightweight as possible. If a change is made to a product, for example, the change would go through the service, then to the repository, where it could be registered with the unit of work, awaiting to be committed.