我有一个业务逻辑层（“存储库”），它作为一组.NET接口公开，由可交换的具体实现支持。
最初我有这个业务层实现身份验证和授权（authn / authz），这意味着我有IUserIdentity和IUserRole等接口，所有访问敏感数据的方法都采用了IUserIdentity并在允许操作之前执行了授权。
到目前为止，业务层一直是前端不可知的...但是现在当我尝试集成到ASP.NET网站时，我意识到ASP.NET本身具有丰富的身份验证/授权系统通过Membership和Role API构建它。
所以问题是，我应该从业务逻辑层中删除所有authn / authz并依赖Web前端来执行此操作吗？这会简化很多事情，但我不知道后来我是否会后悔将它移出去。
另一种方法是将authn / authz保留在我的业务逻辑中，但通过自定义成员资格/角色提供程序将其与ASP.NET集成。然而，这看起来真的很麻烦......我仍然需要调查这样做的成本。
你会做什么（或做过什么）以及为什么？
答案 0 :(得分：5)
我认为安全是一个贯穿各领域的跨领域问题。我不知道.NET是否有方面，除非你使用Spring.NET。
答案 1 :(得分：1)
保持它。 ASP.NET中的表单身份验证非常易于自定义，您的业务逻辑层仍然是前端不可知的。
请考虑远离this approach，而是尝试Forms Authentication。基本上，您可以从Login控件的Authenticate事件中调用已建立的方法。
答案 2 :(得分：1)
我建议您保留现有逻辑，并在现有安全类周围编写自定义成员资格/角色提供程序，如果您想直接使用asp.net使用它。这应该比你想象的要容易。
http://www.codeproject.com/KB/aspnet/customaspnetproviders.aspx
由于您已经有用于管理安全权限的类，这只是意味着包装现有逻辑。
这也将帮助您稍后使用安全逻辑，让我们说，当您创建使用业务逻辑的Winform客户端时，或者将业务逻辑公开为Web服务时
答案 3 :(得分：0)
您打算使用多个前端（asp.net，winforms，mobile？），还是通过（Web）服务公开业务层？那么您应该在业务层之上实现身份验证。
当你想要的只是授予/ deney访问权限时，你可以在IIS上使用集成安全性，并且永远不会为它提供自定义代码。
您还可以查看asp.net会员提供商。
答案 4 :(得分：0)
我认为基于角色的安全性应该在业务层中，这是CSLA所说的。