域模型中是否应该存在安全问题？
我正在开发一个松散地基于 MVVM 的 Winforms 项目（.NET 4）。为了安全起见，应用程序根据 Active Directory 进行身份验证，然后使用基于角色的安全性来确定对程序不同部分的访问权限。在大多数地方，安全性是通过 PrimaryPermissionAttribute 实现的，如下所示：
<PrincipalPermissionAttribute(SecurityAction.Demand, Role:="Managers")> _
Public Sub Save() Implements IProductsViewModel.Save
mUOW.Commit()
End Sub
正如您可能从 Interface 实现中看出的那样，这个特定的 Sub 位于 ViewModel 中。 PrimaryPermissionAttribute 正在检查当前用户 (Thread.CurrentPrincipal) 是否属于 Manager 角色。
这引出了我的问题：安全检查（例如上面的）是否应该在域模型中进行？
当我自己思考时，我有两个相互矛盾的观点：
1）让领域模型尽可能忽略其他问题，以减少复杂性和依赖性。 （将安全性排除在外，可能在 ViewModel 中实现）。
2) 在某种程度上，领域模型是“责任到此为止”的地方。如果我在域模型中实现安全性，那么我知道即使另一层的安全性失败，域模型也应该捕获它。
那么，域模型中的安全性如何呢？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
有两种安全性。
一个纯粹是技术性的 - 比如“所有流量都应该通过 https”或“只有特定服务应该接触数据库”或“只有特定进程应该能够接触文件系统/注册表”。
第二个与领域相关。诸如“只有具有秘书角色的用户才能访问付款历史记录”或“未经授权的用户不应访问会计资料”之类的内容。
第一个应该与域解耦。第二个应该位于域内。
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.
就我个人而言，我发现这个问题似乎属于服务层。据推测，应用程序将在某种程度上通过服务层持续存在，以便到达域，并且您可以轻松地使用非域服务来在提交之前验证用户的角色。
我以这种方式执行此操作的原因是基于这样的理论：越接近域的核心，调用堆栈就变得越昂贵。在更高级别上防止域的滥用/误用意味着更好的响应能力和凝聚力。
此外，假设需求发生变化，而另一个角色的某人现在可以执行相同的操作。在服务层中维护所有这些意味着您也不会更改应该不那么频繁地改动的代码。至少在我所做的事情中，积极的一点是，你越接近核心，代码改变的可能性就越小。这意味着你也减少了你的改变“涟漪”到你不想要的其他领域的变化。
出于更广泛的考虑，而不是针对个人，我不喜欢将任何类型的数据访问放入 ViewModel 中的想法。 ViewModel 旨在作为特定于实现的模型的表示。理想情况下，这些物体应该尽可能轻。例如，如果对产品进行更改，则更改将通过服务，然后到达存储库，在存储库中可以将其注册到工作单元，等待提交。
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.
这里有很好的答案。我想这取决于您的权限系统的粒度级别。假设我们正在设计一个“任务管理系统”，并且希望用户限制“项目”级别的可见性。
Great answers here. I guess it depends on the level of granularity your permission system has. Let's say we are designing a "Task Management System" and we want users to limit visiblity on a "Project" level.