3

我们当前的 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。

我们还有一个担忧是给定用户很可能可以访问多个应用程序，因此拥有某种集中式解决方案是最佳选择，这样我们就可以在需要时轻松删除用户。

在这种环境中维护角色安全的最佳实践是什么？

4

3 回答 3

2

ASP.NET 2.0 的成员资格、角色和配置文件

于 2009-04-03T16:14:51.560 回答
0

我认为与之前做出的决定相关的考虑因素并没有发生太大变化。

关于模式注释，这些只会帮助您组织数据库元素，因此您可以为模式内的所有元素分配权限，而不必为每个过程/表进行配置。

是否让身份流向 SQL Server 而不是使用受信任的子系统模型所涉及的决策非常特定于特定场景。也就是说，我不喜欢像那样流动身份，因为通常仍然在应用程序上执行逻辑，这意味着 sp 可能正在执行部分规则。由于这个原因，这种方法也推动了存储过程中的更多逻辑。

关于只有管理员有权访问机器中的用户组，请考虑查看 ADAM（活动目录应用程序模式）。我不知道它是否支持将它与 SQL Server 集成，所以我不确定这是否适用于该架构。不过值得检查。

关于无法获取角色，根据您的信息，我假设用户组和所涉及的数据库角色之间存在密切关系。您可以获取用户在活动目录中的组（角色）。

底线：评估 ADAM 如何适合您的场景，以及使用当前身份流方法所涉及的注意事项是否仍然存在。另外不要忘记考虑项目中更改应用程序身份流的影响。

于 2009-04-03T16:59:10.687 回答
0

尝试重构您的设计，使您的存储库本身是 LDAP。所以本质上你的用户和角色对象映射了 AD 对象。然后，您可以拥有完全的控制权，而无需通过各种系统管理员。当然，这并不容易，具体取决于代码的状态。但最好的开始方法是创建小型概念证明来完成您的业务对象到 AD 的映射。

于 2009-04-13T16:13:23.637 回答