似乎只能使用< authentication mode =“Windows”> ;,是否可以使用FORMS？ 背景 – 这里的目标是在使用Active Directory作为后端身份验证系统时提供ASP.NET Forms UX.如果使用内置技术有另外一个简单的方法,那么很好,我也想听听. 更新 我应该说,我有认证工作,我正在努力的是添加一个精细控制级别(如角色). 目前,我必须将我的Active Directory连接设置为指向我的域中的特定OU,这限制了对该OU中的物理访问权限 – 我想要将Active Directory连接指向我的整个域,以及如果我使用Windows身份验证,则可以基于组成员资格(也称为角色)限制访问,但是我希望拥有两个世界的最佳效果,这是否可能没有编写我自己的RoleProvider？
解决方法
>使用AuthorizationManager aka AzMan. – AzMan内置于Windows 2003中,可与Active Directory组进行交互.此外,还有一个.NET 2.0内置的AuthorizationStoreRoleProvider,您可以使用它与其进行交互. AzMan致力于任务,操作和角色,大概您的应用程序将被编码为对特定任务执行操作,然后可以将其分组到操作中,然后您可以创建具有执行各种操作权限的角色.安装AzMan时可以安装管理应用程序,您可以使用它们来管理任务,操作和角色.然而,AzMan有一些缺点.首先,AuthorizationStoreRoleProvider不会识别任务.相反,它将加载具有操作列表的角色列表.因此,除非您创建提供程序的自定义版本,否则您的应用程序将需要寻找操作名称而不是任务名称.其次,在最低层次上,仍然可以通过COM来进行互动,这可以是一种负担.除非您希望管理员必须使用AzMan工具,否则您需要编写自己的页面来管理角色的操作,角色和成员资格.>使用sqlRoleProvider并将角色映射到用户名.这个解决方案的优点是实现起来非常简单. RoleProvider可以使用用户名,而不是UserId,您几乎可以使用它.在您的代码中,您只需检查IsInRole来确定给定的用户是否被删除到您的代码识别的角色.显着的缺点是它仅适用于用户名,而不是AD组,因此管理员无法使用AD工具来管理用户.相反,您必须编写一个管理控制台来管理角色成员身份.此外,更改AD级别的用户名需要更新您应用程序的已知用户名列表.>写(或定位)一个尊重AD组的自定义AD RoleProvider.编写自定义角色提供程序不是为了微弱的心脏,但是这样做可以让管理员使用其现有的AD工具管理角色成员资格.