我有一个业务逻辑层（“存储库”），它是作为一组由可交换具体实现支持的.NET接口公开的。业务逻辑层是否应该实现授权和认证？
本来我有这个业务层实现身份验证和授权（authn/authz），这意味着我有接口，如IUserIdentity和IUserRole，并且所有访问敏感数据的方法在执行操作之前都接受了IUserIdentity并执行了授权。
到目前为止，业务层一直是非常前端的不可知论者......但是现在当我尝试集成到ASP.NET网站时，我意识到ASP.NET本身具有丰富的认证/授权系统通过成员资格和角色API内置于其中。
所以，问题是，我应该从商业逻辑层去掉所有的authn/AuthZ的，并依赖于Web前端做到这一点？这将简化很多事情，但我不知道我是否会后悔将它推出去。
另一种方法是保持authn/AuthZ的在我的业务逻辑，而是通过自定义的会员/角色提供其与ASP.NET集成。然而，这看起来很麻烦......我仍然需要调查这样做的成本。
你会做什么（或已经做了），为什么？
我认为安全是一个横切关注点，在各方面属于。我不知道.NET是否有方面，除非你使用Spring.NET。
保留它。 ASP.NET中的表单身份验证非常容易定制，您的业务逻辑层仍然是前端不可知的。
考虑呆在从this approach离开，而是尝试Forms Authentication。基本上，您可以从Login控件的Authenticate事件中调用已建立的方法。
你打算使用多个前端（asp.net，的WinForms，移动？），或者通过（网络）服务暴露业务层？那么你应该在业务层之上实现认证。
当您只想授予/ deney访问权时，您可以在IIS上使用集成安全性，并且永远不会为其定制代码。
你也可以看看asp.net会员供应商。
我建议你保留现有的逻辑，并且围绕你现有的安全类编写一个自定义的成员/角色提供者，如果你想直接使用asp.net来使用它。这应该比你想象的要容易。
http://www.codeproject.com/KB/aspnet/customaspnetproviders.aspx
正如你已经拥有管理安全权限等级，这也就意味着包装现有的逻辑。
这也将帮助您以后使用你的安全逻辑，我们可以说，当你创建一个WinForm客户端消耗你的业务逻辑，或当你暴露你的业务逻辑的Web服务
我相信角色基于安全的安全应该放在业务层，这是CSLA所说的。
其实（抱歉，我应该提到这一点）我正在使用ASP.NET MVC，它通过Authorize属性实现了安全性方面的概念。如果我记得正确，.NET中的 – DSO 2009-02-24 22:24:30