代码之家  ›  专栏  ›  技术社区  ›  dso

业务逻辑层应该实现授权和身份验证吗?

  •  7
  • dso  · 技术社区  · 15 年前

    我有一个业务逻辑层(“存储库”),它作为一组.NET接口公开,并由可交换的具体实现支持。

    最初,我让这个业务层实现身份验证和授权(authn/authz),这意味着我有诸如IUserIdentity和IUserRole之类的接口,所有访问敏感数据的方法都具有IUserIdentity并在允许操作之前执行授权。

    到目前为止,业务层一直是前端不可知论者。。。但现在,当我尝试集成到ASP.NET网站时,我意识到ASP.NET本身通过成员资格和角色API内置了丰富的身份验证/授权系统。

    所以问题是,我是否应该从业务逻辑层删除所有authn/authz,并依靠web前端来完成这项工作?这将简化很多事情,但我不知道我以后是否会后悔把它搬走。

    另一种方法是将authn/authz保留在我的业务逻辑中,但通过自定义成员资格/角色提供程序将其与ASP.NET集成。然而,这似乎真的很麻烦。。。我仍然需要调查这样做的成本。

    5 回复  |  直到 15 年前
        1
  •  5
  •   duffymo    15 年前

        2
  •  1
  •   matt eisenberg    15 年前

    留着吧。ASP.NET中的表单身份验证非常容易自定义,并且您的业务逻辑层仍然是前端不可知的。

    考虑远离 this approach 而不是尝试 Forms Authentication . 基本上,您可以从登录控件的Authenticate事件调用已建立的方法。

        3
  •  1
  •   amazedsaint    15 年前

    我建议您保留现有的逻辑,如果希望使用asp.net直接使用现有的安全类,请围绕现有的安全类编写一个自定义成员资格/角色提供程序。这应该比你想象的容易。

    http://www.codeproject.com/KB/aspnet/customaspnetproviders.aspx

    由于您已经有了用于管理安全权限的类,这就意味着要包装您现有的逻辑。

        4
  •  0
  •   oɔɯǝɹ    15 年前

    您计划使用多个前端(asp.net、winforms、mobile?),还是通过(web)服务公开业务层?然后,您可能应该在业务层的顶部实现身份验证。

    当您只想授予/deney访问权限时,可以在IIS上使用集成的安全性,而不必使用自定义代码。

        5
  •  0
  •   jradxl    14 年前

    我相信基于角色的安全性应该在业务层,CSLA就是这么说的。