3

我们有一个用于验证用户的 SSO 系统。

我们在这两个选项之间进行了辩论：

  1. 我们是否应该将每个应用程序的授权集中到一个数据库（或任何其他单一解决方案）并检索 SSO 请求中的信息

  2. 每个 Web 应用程序客户端都应该在本地数据库/方案中管理自己的授权逻辑。

4

2 回答 2

4

您应该努力将业务逻辑与非功能性需求（例如身份验证、日志记录，当然还有授权）分离。

您已经实现了 SSO，并且肯定使用用户目录作为 SSO 的后端来存储用户身份。这表明您已成功从您保护的应用程序外部化身份验证。您是否考虑过为每个应用创建一个用户名/密码数据库？您是否考虑过编写逻辑来管理密码、哈希等...？当然不是！这同样适用于授权。

分析公司 Gartner 将您正在考虑的领域定义为外部授权管理。如果您是 Gartner 客户，您可以在此处找到更多信息。

实现外部化授权有两种主要模型：要么使用基于角色的访问控制模型 (RBAC)，要么使用基于属性的访问控制 (ABAC)。NIST 为两者提供了定义和更多内容：

许多应用程序框架提供了某种形式的外部化。以 Java Spring 为例：它带有 Spring Security 和 Access Decision Managers（更多关于 Spring 架构的信息）。PHP、Ruby、Python 和 .NET 等等，但其中一些也都有自己的方式。

因此，如果可以，请不要在应用程序中实现授权逻辑，而应利用所提供的框架。

更进一步，您甚至可以考虑标准化您的外部化授权。就像 SSO 有它的标准 (SAML) 一样，外部授权有 XACML（可扩展访问控制标记语言），这是一个由 OASIS 定义的标准，与 SAML 非常相似，并得到了 IBM、Oracle 和 Axiomatics 等公司的支持——这就是我工作的地方。

XACML 为您提供了一种基于策略的外部化、细粒度授权方法。您可以编写策略并将其应用于任意数量的应用程序。当然，您可以使用 XACML 扩展您的 SSO 层。

使用外部授权（尤其是在 XACML 上标准化）的好处是：

  • 授权逻辑的整合：维护起来更容易、更便宜
  • 更好的安全性：XACML 更具表现力，您现在可以去一个地方检查安全性是否正确实施。
  • 公开新业务的能力：我处理的一些客户希望将应用程序公开给网络/第 3 方。使用细粒度授权可以让他们控制谁可以在什么情况下做什么。
  • 合规性：看看我们今天生活的世界。根据我们的工作领域（银行、保险、医疗……），我们必须遵守许多法规。这些规定很难在代码中实现，但很容易表达为 XACML 提供的策略。

如果您想了解更多信息，我在 JavaZone 2013 上发表了关于 Java 和 XACML 的演示文稿。幻灯片在这里。

您使用什么 SSO 解决方案？SiteMinder 为您提供了一个授权 API (ActivePolicy) 来实现更细粒度的授权。看看那个。

我希望这有帮助！

于 2013-10-25T12:28:15.723 回答
2

我会区分授权所需的逻辑和数据。

如果您正在查看授权逻辑，它更特定于应用程序。为什么要集中逻辑？您可能会遇到跨多个应用程序使用相同授权逻辑的情况，并且此类授权逻辑可能会发生变化。但是，许多应用程序不需要这个，并且由于所需的时间和成本，开发用于外部化所有授权逻辑的应用程序可能并不总是可行的选择。为此需要一些策略规范语言，并且每个客户端应用程序都应使用解释器。

集中授权所需的数据是一项简单得多的任务，并且可能是比上述更频繁需要的功能。但是，当所需的数据依赖于领域对象而不是主题时，您又会遇到上述情况。我想当你有一套应用程序，其中相同的用户角色或属性被类似地应用时，这样做会有更多的价值（并且可能也需要）。另一种情况可能是需要由一组人进行集中授权管理——这可能适用于您的应用程序，也可能不适用于您的应用程序。

规定一种解决方案而不是另一种解决方案不是我喜欢做的事情。如果我需要对这种性质的问题提出是/否的答案，我也会评估其他方面。例如，

  1. 现有应用程序、它们的实现语言、平台、修改开销和使用的现有授权机制。
  2. 究竟应该集中什么（逻辑、数据）？
  3. 集中授权的复杂性是否合理？
  4. 网络通信开销和增加的延迟
  5. 这如何影响系统和部件的可测试性？
  6. ......这个列表不会轻易结束......
于 2013-10-25T18:32:59.580 回答