你如何编织认证，角色和安全性到您的DDD？ [英] How do you weave Authentication, Roles and Security into your DDD?

问题描述

如何实现在C＃领域驱动设计的项目角色和安全？我们有一些争论肆虐是否应通过调用应用程序（ASP.NET MVC）或域模型本身（模型实体和服务）来实现。有人认为，它应该是在网站本身，因为这也正是验证已经存在。但是，这意味着你必须每次与核心业务系统集成的时间重新实现安全性。

How do you implement Roles and Security in your C# Domain Driven Design projects? We have some debate raging on whether it should be implemented by the calling application (ASP.NET MVC) or in the Domain Model itself (model entities and services). Some argue that it should be in the web site itself since that's where the authentication already exists. But that means you have to re-implement security every time you integrate with the core business systems.

作为一个例子：的管理员应该能够做到pretty很多系统中的任何操作，如编辑和删除记录（即他们可以删除用户的订单）。在另一方面，一个用户只能够编辑和删除自己的记录（即他们可以添加/从购物车中删除项目）。

As an example: an Admin should be able to do pretty much any action in the system such as edit and deleting records (i.e. they can delete an user's order). An User on the other hand should only be able to edit and delete their own records (i.e. they can add/remove items from their shopping cart).

顺便说一句，这里是涵盖有关DDD和放大器7不同场景的主题一个很好的论文;安全性：

By the way, here is a nice thesis on the topic which covers 7 different scenarios regarding DDD & Security:

保障领域驱动设计

• 第4章安全服务设计方案
  
  
  • 4.1方案1：安保作为常规服务
  
  
  • 4.2方案2：安全嵌入UI
  
  
  • 4.3方案3：安保​​封装领域模型
  
  
  • 4.4方案4：安保作为UI
  网关
  
  • 4.5方案5：安保作为UI
  适配器
  
  • 4.6方案6：安全服务通过AOP与适配器集成
  
  
  • 4.7方案7：安保用AOP集成
  
  

  我个人偏向使用AOP PostSharp，但没有做太多与它之前，我犹豫要采取的飞跃。

  I would personally lean towards AOP using PostSharp, but not having done much with it before, I'm hesitant to take the leap.

  推荐答案

  不要忘了运行时已经内置了一个抽象的安全/用户系统 - 主要的（见本的现有的应答 - 注意， GenericIdentity 只是一个选项，它是pretty琐碎写你自己的）。

  Don't forget that the runtime already has an abstracted security/user system built in - the principal (see this existing answer - note that GenericIdentity is just one option; it is pretty trivial to write your own).

  您的UI可以处理创建和基于特定的实现（分配主要的确，这个都ASP.NET和WCF为此自动，或为的WinForms / WPF可以使用窗同​​一性，或（经由web服务）同样的ASP.NET登录）。

  Your UI can handle creating and assigning the principal based on the specific implementation (indeed, IIRC ASP.NET and WCF do this automatically, or for winforms/wpf you can use the windows identity, or (via a web-service) the same ASP.NET login).

  您的业务逻辑，那么就检查 Thread.CurrentPrincipal中;从这个你可以得到名，身份验证方法，并为您的角色（而无需知道角色是如何实现的）。

  Your business logic then just checks Thread.CurrentPrincipal; from this you can get the name, the authentication method, and check for roles (without needing to know how roles are implemented).

  运行时也提供了内置的检查：

  The runtime also provides inbuilt checks:

      [PrincipalPermission(SecurityAction.Demand, Role = Roles.Admin)]
      public void Foo() {...}
  

  （其中 Roles.Admin 是一个字符串常量你的角色的名字）这将自动检查访问，抛出一个 SecurityException异常如果不是在作用。您还可以通过code。检查（有用的，如果角色不固定在编译时）。

  (where Roles.Admin is a string constant of your role name) This will check access automatically, throwing a SecurityException if not in the role. You can also check via code (useful if the role isn't fixed at compile time).

  显然，你的UI应该检查的角色（禁用/隐藏功能），但是这是好事，有业务code的执行的而无需知道用户界面的角色。

  Obviously your UI should check roles (to disable/hide functionality), but it is good to have the business code enforce the roles without needing to know about the UI.

  （添加）

  我要指出， GenericIdentity 是非常方便的单元测试。当然，你的可能的角色自己的安全API，没有人会阻止你...

  I should mention that GenericIdentity is handy for unit tests. Of course, you could role your own security API, and nobody will stop you...

  这篇关于你如何编织认证，角色和安全性到您的DDD？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！