有效地设计角色

在许多场景中，基于角色的安全性是一种非常有效的机制，但在某些情况下，这种安全性效率较低。 在决定在特定应用程序中应用基于角色的安全性的位置以及应用方式时，应考虑多个因素。

用户和数据特征以及角色的适用性

角色非常适用于描述用户组的特征，并在此基础上筛选这些用户可以执行的操作。 通常，在实践中做到这点的方法是创建反映用户在组织内的位置的角色，例如角色“经理”和“柜员”、“管理员”和“读取者”、“项目一员工”和“项目二员工”）。在这种情况下，访问的数据相对于用户而言相当通用，则可以有效地使用角色来强制实施业务规则，如下所示：

• “经理可以转移任何金额。 柜员最多只能转移 10,000 美元。”

• “管理员可以更改任何内容。 其他人只能读取。”

• “项目一员工可以访问特定数据库。 其他人都不能访问该数据库。”

自然，用户可能拥有多个角色，具体取决于角色如何体现企业的组织结构。

但是，当安全访问决策取决于特定数据片段的特征时，角色效果就不是很好。 例如，使用角色难以反映复杂的用户-数据关系，例如：

• “特定经理只能访问自己下属的人员数据。”

• “消费者 Joe 可以查找自己的账户余额。”

在这种情况下，通常必须在数据库本身执行安全检查，这样就可轻松地考虑所要访问数据的内在特征。 这意味着，必须使用模拟将客户端标识传递给数据库，并让数据库验证请求。 这可能会影响性能，并可能会影响应用程序设计，例如，使用特定用户标识打开连接时，连接池可能不会正常工作。 有关所涉及问题的讨论，请参阅多层应用程序安全性和客户端模拟和委派。

基于角色的授权策略的复杂性和可伸缩性

无论采用何种安全策略，其有效性都取决于部署应用程序的系统管理员实现该策略的方式。 如果管理员根据安全策略将用户分配到正确的角色时犯错，则策略将无法按预期正常工作。 在以下情况下最有可能发生问题：

• 您制定了一个非常复杂的基于角色的策略，其中有许多角色，并且有映射到许多角色的用户。
• 在您创建的角色中，在用于确定应属于这些角色的用户的条件方面不明确。
• 在安装应用程序的站点中有许多用户，并且用户经常在组织内移动，会根据您所创建的角色进行更改。
• 在安装应用程序的站点中有许多管理员，这些管理员划分了职责，因此熟悉应用程序安全要求的管理员可能不熟悉必须使用该应用程序的大型用户组。 当用户在组织内移动时，这是一个特别值得关注的问题，因此需要很好地沟通这些信息。

此外，随着分配给应用程序的角色数增加，COM+ 在查找这些角色中的调用方成员身份所需的时间也会增加，因此性能可能会降低。

若要化繁为简并缓解这些问题，可以使用以下准则：

• 选择自描述性角色名称。 尽可能阐明哪些用户应属于哪些角色。
• 尽量简化基于角色的策略，而不是更简单即可。 选择尽可能少的角色，同时维护有效的策略。
• 清楚地记录为管理员构造的基于角色的策略，而不考虑角色成员身份（对您而言）是否明显。 具体而言，使用适用于每个角色的描述字段来描述角色的意图。 如果无法用几句话概括地描述谁应该属于该角色，那可能就是过于复杂。
• 强烈建议应用程序管理员使用用户组而不是单个用户填充角色。 这是一个更具可伸缩性的解决方案。 这样，当用户在组织内部移动时，就可以更轻松地重新分配或删除用户，并且管理员也可减轻监督工作量和减少面临的通信问题。

相关主题

安全边界

安全调用上下文信息

安全上下文属性

使用角色进行客户端授权