使用服务层自定义身份验证？答案

【问题标题】：Custom authentication with service layer?使用服务层自定义身份验证？
【发布时间】：2010-01-19 08:29:03
【问题描述】：

我有一个包含 3 个“层”的应用程序，第一个“数据层”，第二个“业务层”，第三个是 asp.net mvc 站点。我正在尝试以正确的方式添加表单身份验证。

我应该以某种方式将其配置为使用业务层吗？获取/添加/更新作为身份验证一部分的用户？

我应该在哪个项目中添加用户验证？

【问题讨论】：

【解决方案1】：

身份验证应该始终发生在应用程序边界，因为使用相同域模型的不同应用程序可能有不同的身份验证需求。如果您决定将域模型公开为 Web 服务，那么表单身份验证可能不是最好的身份验证机制。

在 ASP.NET MVC 中，您可以使用 Visual Studio 中的默认项目模板轻松实现用户名/密码身份验证，但是一旦用户通过身份验证，您应该设置 Thread.CurrentPrincipal。

一般来说，IPrincipal 是在 .NET 中建模用户上下文的标准基础。例如，HttpContext.User 是一个 IPrincipal。

在您的域模型和数据访问模块中，您可以使用 Thread.CurrentPrincipal 来实现授权逻辑。这使您可以独立地改变身份验证和授权。

如果您需要在您的领域模型中使用更丰富的用户概念，您可以拥有您的User class implement IPrincipal。

【讨论】：

有没有办法实现这个：schotime.net/blog/index.php/2009/02/17/… 到我的服务层并从我的 asp.net mvc 应用程序中使用它？或者自定义身份验证类是否需要与 mvc 应用在同一个项目中？
从应用程序/UI 层利用服务层或域模型服务的最佳方式是使用依赖注入 (DI)。但是，您不能真正将服务注入到属性中，因为它是静态连接的。但是，您可以使用 DI 全局配置 ASP.NET MVC FilterAttributes。这是一个示例，展示了如何处理 HandleError：blog.ploeh.dk/2009/12/01/GlobalErrorHandlingInASPNETMVC.aspx
@MarkSeemann 为什么我应该在用户通过身份验证后设置 Thread.CurrentPrincipal？
@Rookian 为了你自己，你可能不需要它，但许多 .NET 框架倾向于依赖它。