首页 文章

在这种情况下我们应该开发自定义会员提供商吗？

提问于
浏览 次
12

摘要

长话短说，我们的任务是去除一个相当古老而臃肿的asp.net应用程序的身份验证和授权部分，这些应用程序之前已经从头开始编写了所有这些组件 . 由于我们的应用程序不是典型的，并且我们都没有使用asp.net的内置成员资格提供程序的经验，我们不确定是否应该再次推出自己的身份验证和授权，或者我们是否应该尝试在asp.net会员提供商心态并开发我们自己的会员提供商 .

我们的申请

我们有一个相当古老的asp.net应用程序，它安装在客户位置，为LAN上的客户提供服务 . 管理员创建用户（用户不注册），并且根据安装，我们可能将软件与LDAP集成 .

目前，LDAP集成批量导入用户到我们的数据库，当他们登录时，它会对LDAP进行身份验证，因此我们不必管理他们的密码 . 没什么了不起的 .

管理员可以将用户分配到1个组，他们可以更改该组的授权以管理对软件各个部分的访问 .

组由Admins（基于Web的UI）维护，如前所述，授予/拒绝应用程序中某些功能的权限 .

所有这些都是完全从头开始编写的，不使用任何内置的.net授权或身份验证 . 我们确实有 IsLoggedIn() 方法来检查登录并重定向到我们的登录页面，如果它们不是 .

我们的重写

我们的任务是与LDAP更紧密地集成，他们希望我们将应用程序中的组与LDAP中的组（或LDAP使用的任何类型的容器）联系起来，以便当客户选择使用我们的LDAP集成时，他们没有在LDAP和我们的应用程序中管理他们的用户 .

新的方式是，他们只需在LDAP中创建用户，将他们添加到LDAP中的组，我们的应用程序将看到他们属于相应的LDAP组并进行身份验证和授权 .

此外，我们已被授予完全删除用户身份验证和授权代码并完全重新执行的权限 .

我们的问题

问题是我们都没有任何使用asp.net会员提供程序功能的经验 . 我对它的一点点曝光让我担心它不能用于像我们这样的应用程序 . 虽然，开发我们自己的ASP.NET成员资格提供程序和角色管理器听起来像是一个很棒的体验，很可能是适当的事情 .

基本上，我正在寻找建议，我们是否应该使用ASP.NET成员资格提供程序和角色管理API，还是应该继续推广自己的？我知道这个决定会受到我们要求的影响，所以我将在下面讨论它们

我们的要求

只是一个快速的脏列表

  • 保持拥有用户数据库并对其进行身份验证的能力，并为管理员（仅限用户）提供CRUD用户的能力

  • 允许站点与LDAP集成，选择此项后，他们不希望任何用户存储在数据库中，只需要存在于我们的app / db中的组与LDAP /容器中存在的组/容器之间的关系 .
    正在使用

  • .net 3.5（asp.net webforms和asp.net mvc的混合）

  • 必须在ASP.NET和ASP.NET MVC中工作（不应该't be a problem I'猜测）

  • This can't be user centric ，管理员需要成为唯一的CRUD（或通过ldap导入）用户和组

  • 我们必须能够通过LDAP进行Auth验证

我总是试着密切关注我的问题，所以请随时询问更多信息 . 另外，作为答案中我正在寻找的内容的总结 . “你应该/不应该使用xyz，这就是为什么” .

有关asp.net会员提供商和角色管理的链接非常受欢迎，我发现的大部分内容都是5年 .

c# asp.net authentication authorization

5 回答

  • 5

    您的问题上下文中的安全性涉及两个单独的操作：身份验证和授权，以及在.NET中划分为MembershipProviders和RoleProviders的操作 . 我强烈建议使用两者（意味着自定义或内置）来进行身份验证和授权 . 这样做，提供了升级的途径，如果您以后找到更好的工具来完成工作，并使其他开发人员更容易理解安全性 .

    现在，对于身份验证，我会像其他人所说的那样使用 SqlMembershipProvider 或 ActiveDirectoryMembershipProvider . 我的经验是，在99％的情况下， ActiveDirectoryMembershipProvider 为完整的AD存储（即不是ADAM又名ActiveDirectory应用程序模式）提供了足够的功能 . 我在多域情况下遇到了 ActiveDirectoryMembershipProvider 的问题，但总的来说找到一种使用它而不是自己滚动的方法要好得多 . 同样， SqlMembershipProvider 用于身份验证，运行良好并且可以很好地扩展 .

    然而，授权是完全不同的鱼 . 这真的是你感受到痛苦的地方 . 首先，没有“ActiveDirectoryRoleProvider” . 这意味着如果要与AD组集成，您有三种选择：

    • 使用AzMan

    • 通过自定义RoleProvider自行完成

    • 找一个为你做过的人 .

    • 使用ADFS或Microsoft的新联合服务

    Choice 1: AzMan AzMan (Authorization Manager)（另请参阅Windows Authorization Manager）是Microsoft编写的用于管理应用程序授权的工具 . AzMan有一些不错的功能：

    • 它可以将您的角色链接到AD组（或Windows组）

    • 它可以存储为文件，以便您可以将其与应用程序保持在一起 .

    • 很好地将授权分解为任务，操作和角色 .

    • 附带一个单独的管理工具

    • 2008版本将与SQL身份验证存储进行交互 .

    问题在于，AzMan可以成为一个反对的熊，并且理解该工具不适合没有经验的人 . 我发现文档很少，但那是几年前的事 . 此外， AuthorizationStoreRoleProvider 不支持任务，即使AzMan本身也是如此 . 任务是可以完成的最细粒度的事情，并且可以分组到操作中，这些操作本身可以分组为可以删除用户或AD组的角色 . 文档已经变得更好了 . 我知道，当我上次使用AzMan时，缺少与数据库身份验证存储的继承交互使得使用它有点痛苦 .

    Choice 2: Write your own RoleProvider

    这对LDAP来说可能是一次痛苦的经历 . 如果您计划在非AD环境中使用 SqlRoleProvider ，则在需要查询AD组并且不想使用AzMan的情况下，您只需要自定义RoleProvider .

    我使用的另一种替代方法是管理数据库中的角色，并允许 MembershipProvider 成为它想要的任何东西 . 这仍然需要编写一个自定义提供程序（但是一个非常简单的提供程序），并且可以轻松地将应用程序移动到AD环境中 . 如果您将角色存储在数据库中，并且您希望允许管理员将多个级别的组关联到您的角色，那么您必须将其写入自定义 RoleProvider .

    如果您打算使用 SqlRoleProvider ，也可能会遇到一些问题 . 如果在单个应用程序环境中将 SqlRoleProvider 与 SqlMemberProvider 一起使用，那么它将运行良好并且非常容易设置 . 但是，如果您要对单个存储进行身份验证的多个应用程序，则 SqlRoleProvider 在所有情况下都无法正常运行而无需修改 .

    Choice 3: Find someone that has done it for you.

    具体来说，我的意思是找到一个开发了 ActiveDirectoryRoleProvider 的人 . 你可以轻松地谷歌进行各种选择，但我还没有使用它们，并希望在我的应用程序中倾注任何与安全性有关的代码 .

    Choice 4: Active Directory Federated Services

    微软真的一直在推动这个解决方案，如果能让它正常运行，它确实可以保证单点登录 . 这个解决方案的关键在于让您与合作伙伴之间进行特别设置 .

    回复于
  • 2

    我很满意会员提供商和角色提供者课程 . 他们只是工作 . 在我看来，最好的部分是，对于我的本地开发，我使用SQL提供程序登录到本地数据库，该数据库具有与我想要测试的一些人相同的用户名（管理员，高级用户，基本用户）使用通用密码 . 然后，当我发布我的应用程序时，它使用ActiveDirectory成员资格提供程序并无缝集成 . 我不必为访问限制更改一段代码 . （除了我的web.config文件之间的差异）

    根据您的情况，编写自己的自定义提供程序似乎最好，因为您希望在数据库中发现用户，但将其密码与LDAP进行比较 . 此外，它们与Webforms和MVC无缝集成 .

    我会在提供商上推荐Scott Mitchell的Multipart系列 . 非常广泛和彻底 .

    另外，我想补充一点，因为有些文章是旧的，并不意味着它们仍然不适用 . 会员提供者框架已经出现多年了，所以有些文章收集以太网粉尘是有道理的 .

    回复于
  • 5

    我正在处理一些相同的东西，所以我将稍微开始这个答案，并希望随着时间的推移 Build 它 .

    一个快速的答案是，根据您的要求，我建议您可能想要研究Microsoft为您提供的两个内置提供程序：基于SQL Server和基于Active Directory . 开箱即用，只需翻转.config文件中的某些配置，就可以将交换机从使用SQL Server转到使用Active Directory . 除非我误解了你的需求，否则听起来这正是你在两个场景中所需要的 . 如果你这样做，100％的应用程序可以看起来和功能相同，即使使用相同的代码库 . 将数据从一个部署的现有应用程序迁移到另一个部署变得更加有趣（不幸的是，我没有这方面的经验），但是相对于另一个部署的清洁部署应该非常简单 .

    很明显，如果您不喜欢内置提供程序的行为，您可以创建自己的行为 .

    我在工作中的地方是我们一直在使用基于SQL的提供程序，我们需要转移到Active Directory，内置提供程序可能或可能不足以满足我们的需求（我仍然在评估它，并且非常此刻积极参与） . 我还使用了一些概念验证代码，以便在我们需要的情况下，我相信我们可以合理地创建自己的提供商 .

    所以我知道这不是你的问题的答案，但我希望这给你一些现在可以思考的东西，并以某种方式帮助你 . 就像我说的那样，随着我在这里的知识增长，我很乐意为此增添更多 .

    回复于
  • 2

    FYI material

    [How Do I:] Create a Custom Membership Provider? - 来自ASP.Net官方网站的视频教程 . 这个主题的一个非常好的介绍 .

    Simple LDAP Membership Provider - 一个非常简单的LDAP成员资格提供者的论坛帖子 .

    GPL .Net LDAP Membership Provider - 它已经有一段时间了 . 但我想还是值得一提的 .

    Notes

    • 您可能必须与客户争论使用LDAP作为数据库 . 要坚强！ LDAP可用于身份验证甚至授权 . 但您最终可能需要存储更多信息 . 唯一合理的方法是将LDAP uid映射到数据库用户表并运行它 . 您的会员提供商可以使其对项目的其余部分透明 . 但是客户端必须明白，虽然LDAP为他们提供单点登录，但它可以用作数据库替代品 .

    • 就个人而言，我会坚持使用Membership API，但尝试编写一个高性能的后端 . 也许有点缓存并自动将LDAP用户映射到uid上的数据库用户表作为键 . 关于LDAP的好处是它在.Net中有相当多的支持 . 除非你真的想要，否则你不必管理套接字等 . 因此，我的LDAP /目录访问代码通常很容易在每个方法下使用十几行 . 这对于 生产环境 来说通常都足够好 .

    回复于
  • 2

    只是把另一个想法扔进戒指 - 你考虑过联邦身份验证和基于声明的授权吗？看起来它可能非常适合您的场景 . 基本上，这使您可以将身份验证与应用程序分离为联合服务提供程序（想想OpenID），该联合服务提供程序管理身份验证并向您的应用程序发出令牌 . 有些服务提供商可以与LDAP，AD和其他目录标准集成 . ADFS（Active Directory联合身份验证服务，以前称为Geneva Server）是与AD链接的一个示例 .

    如果配置得当，与身份相关联的属性（例如组成员身份）可以作为与身份相关联的“声明”传递给您的应用程序 - 您的应用程序可以根据声明执行其喜欢的操作 . 关键是您的应用程序可以找出用户所属的组，以及其他属性，例如：电子邮件地址，通过检查令牌中传递的声明 .

    联合身份验证的优势是双重的 . 首先，只要有提供者（或者当然可以编写自己的提供者），您就可以与任何您喜欢的目录集成，而不仅仅是LDAP . 其次，它使您的应用程序代码中的身份验证不受影响，因此您可以在将来改变实现以支持不同的方案 .

    查看http://msdn.microsoft.com/en-us/magazine/ee335707.aspx以获取Windows Identity Foundation（以前代号为'Geneva Framework'）的介绍 . 或者查看team blog .

    回复于

相关问题