我有一个解决方案，分为3个项目 其中两个是使用ASP.Net Identity提供商的MVC 5 Web应用程序 一个是由其他项目引用的类库。所有CRUD操作都在这里进行。
所有项目都指向相同的数据库并通过EF运行。
所有业务逻辑都发生在类库中，但与用户无关。用户验证仅在Web应用程序中进行。这里的问题是在所有Web项目中重复用户验证代码，并且类库不知道用户调用API 这种架构很快就会带来维护噩梦，所以我希望只有类库与db进行业务逻辑或用户验证。 现在，既然ASP.Net Identity提供程序在类库中不起作用，那么有人找到了解决方法吗？
答案 0 :(得分：0)
我不确定＆＃34;维护噩梦＆＃34;您指的是在Web应用程序中具有安全性。将应用程序域与安全模型分离是一件好事。您的域模型和业务逻辑可能在某些Web应用程序中保持不变，但安全模型可能会有所不同。我不会将这些捆绑在一起。如果它在您的类库中，您将如何让OWIN安全框架为您处理表单身份验证。您是否也要在类库中管理所有这些。
当您参考＆＃34;用户验证＆＃34;我假设你在谈论授权。如果您必须在类库中执行授权，我将实现自定义ClaimsAuthorizationManager。您可以覆盖CheckAccess方法来执行授权。 ClaimsAuthorizationManager在您的web.config中配置，因此您可以为不同的Web应用程序使用不同的ClaimsAuthorizationManager。但是类库中的逻辑将保持不变。在执行您要插入的操作之前，您想要授权用户的任何位置：
ClaimsPrincipalPermission.CheckAccess("MyResource", "MyAction");
传递的资源和操作在您创建的自定义ClaimsAuthorizationManager中使用，以了解授权发生的上下文。我为decoupling your security model from your application domain in this article谈论这个方法。如果授权失败，则抛出SecurityException。您可以让它渗透到您正确处理它的Web应用程序（在控制器中重定向或Web APi的HTTP未授权错误）。请注意，如果您在非Web应用程序中使用类库，则此体系结构将起作用。我已将它与ASP.NET Identity一起使用，效果很好。