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

Question

摘要

长话短说,我们的任务是去除一个相当古老而臃肿的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中工作(应该不是我猜的问题)
• 这不能以用户为中心,管理员需要成为CRUD(或通过ldap导入)用户和组的唯一权限
• 当配置完成后,我们必须能够通过LDAP进行身份验证

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

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

Answer 1

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

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

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

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

Answer 2

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

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

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

1. 使用AzMan
2. 通过自定义RoleProvider自己完成
3. 找一个为你做过的人.
4. 使用ADFS或Microsoft的新联合服务

选择1:AzMan AzMan(授权管理器)(另请参阅Windows授权管理器)是Microsoft编写的用于管理应用程序授权的工具.AzMan有一些不错的功能:

1. 它可以将您的角色链接到AD组(或Windows组)
2. 它可以存储为文件,以便您可以将其与应用程序保持一致.
3. 很好地将授权分解为任务,操作和角色.
4. 附带一个单独的管理工具
5. 2008版本将与SQL身份验证存储进行交互.

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

选择2:自己写 RoleProvider

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

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

如果你计划使用SqlRoleProvider你也可能会遇到一些问题.如果使用SqlRoleProvider同SqlMemberProvider一个应用程序中的环境那么它会工作得很好,非常易于安装.但是,如果您要对单个存储进行身份验证的多个应用程序,则SqlRoleProvider无需修改即可在所有情况下无法正常使用.

选择3:找一个为你做过的人.

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

选择4:Active Directory联合服务

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