我们当前的Intranet环境有点过时了。当前堆栈具有查询SQL 2000数据库的ASP.NET 1.1 / 2.0应用程序。
对于角色安全性，服务器上有用户组，用户被添加到用户组中（因此您需要将其添加到测试和生产计算机上的组中）。这些用户组将同步到SQL 2000本身的用户角色。根据需要，角色被授予对存储过程的执行权限，以防止任何访问冲突。
在Web应用程序级别，我们使用基本身份验证（对我们的Active Directory进行身份验证）并启用身份模拟。数据库的连接字符串使用集成安全性。这将创建一个Web应用程序在用户登录时连接到数据库的环境，这将对正在调用的存储过程强制实施数据库安全性。它还允许我们使用典型的User.IsInRole（）方法在应用程序本身内执行授权。
这有几个问题。首先，只有我们的服务器管理员才能访问计算机上的用户组，因此更新角色安全性或添加其他用户不受应用程序管理员的控制。此外，获得该角色的唯一方法是调用一个名为“xp_logininfo”的SQL过程，该过程在SQL 2005中被锁定。虽然我不知道完整的详细信息，但我们的DBA告诉我们这个通用模型不能播放考虑到较新版本中模式的性质，SQL 2005很好用。
我们现在已经准备好更新我们的环境了。我们正在编写.NET 3.5应用程序以利用更多AJAX，SQL Server 2005是我们数据库的主要环境。我们还希望更新安全模型，以便为应用程序管理员提供更多灵活性，并可能更多地利用Active Directory。
我们还有一个问题是，给定用户很可能可以访问多个应用程序，因此使用某种集中式解决方案是最佳选择，因此我们可以在需要时轻松删除用户。
在这种环境中维护角色安全的最佳做法是什么？
答案 0 :(得分：2)
答案 1 :(得分：0)
我认为与之前做出的决定相关的考虑因素已经发生了很大变化。
关于模式注释，这些只会帮助您组织数据库元素，因此您可以为模式内的所有内容分配权限，而不必为每个过程/表配置。
关于是否将标识流向SQL Server而不是使用可信子系统模型所涉及的决策，对于特定方案几乎是特定的。也就是说，我不喜欢像这样流动身份，因为通常在应用程序上仍然存在逻辑，这意味着sp可能正在执行部分规则。由于这个原因，这种方法也促使存储过程中有更多的逻辑。
仅关于只能访问计算机中用户组的管理员，请考虑查看ADAM（活动目录应用程序模式）。我不知道它是否支持将它与SQL Server集成，所以我不确定它是否适用于该架构。值得一试。
关于无法获取角色，根据您的信息，我认为用户组和涉及的数据库角色之间存在密切关系。您可以获取用户在活动目录中的组（角色）。
结论：评估ADAM在您的方案中的适用方式，以及使用当前身份流方法所涉及的考虑因素是否仍然存在。另外，不要忘记考虑项目中对更改应用程序标识流的影响。
答案 2 :(得分：0)
尝试以您的存储库本身为LDAP的方式重构您的设计。基本上，您的用户和角色对象映射AD对象。然后，您可以拥有完整的控制权，而不是通过各种系统管理员。当然，根据代码状态，这并不容易。但最好的方法是创建一个小概念证明来完成业务对象到AD的映射。