如何将 JAAS 授权检查委托给 Shiro？

Question

我正在开发一个服务器端应用程序，需要基于对象的身份验证和授权。我喜欢 Shiro 的简单性，但为了与 JAAS 兼容，我编写了一个使用 Apache Shiro 作为底层机制的 LoginModule。

但我的问题是我找不到将 JAAS 授权检查委托给 Shiro 的方法。我怎样才能实现这个目标？

Answer 1

注意：答案解决了外部授权系统通过标准安全框架与 JVM 集成的一般情况。它不是 Shiro 或 JMX 特定的，因为我对两者都不熟悉。

---

从概念上讲，您似乎正在追求策略决策点 (PDP)，即评估授权查询（“实体 X 是否允许执行 Y？”）的设施。 JDK 提供了其中的几个：

1. 有效的 SecurityManager，特别是它的 checkXXX 方法组。
2. ProtectionDomain 类，特别是它的 implies(Permission) 方法。
3. 有效implies(ProtectionDomain, Permission)方法rel="nofollow noreferrer">政策。
4. 其次，隐含方法CodeSource，PermissionCollection, 权限，以及校长。

任何上述方法都可以被重写，以便以递增的粒度定制概念性PDP的功能。应该指出的是，JAAS 并没有真正带来自己的 PDP（与它的名字所暗示的相反）；相反，它提供了手段除了代码来源的原始信任因素之外，域和策略还支持基于主体的查询。因此，在我看来，您对保持“JAAS 兼容”的要求基本上转化为想要使用（原始加 JAAS）Java SE 授权模型，又名沙箱，我怀疑它是你想要什么。当标准模型被认为级别太低和/或性能密集时，往往会采用 Shiro 等框架；换句话说，当授权逻辑不需要评估给定一组信任因素的每个堆栈帧时，因为这些因素通常是上下文不敏感的。根据我的假设的有效性，需要检查三种主要情况：

1. 授权与 AccessControlContext 无关。 Shiro 原生授权属性 (SNAA)，无论它们是什么，都适用于整个线程。代码来源无关紧要。
2. 代码来源很重要，强制使用沙箱。 SNAA 仍然独立于 AccessControlContext。
3. 代码来源和 SNAA 都是相关的并且AccessControlContext-依赖。

---

1. 仅基于 SNAA 的授权

1. 按照您认为合适的方式管理身份验证。如果您希望继续使用 JAAS 的 javax.security.auth SPI 进行身份验证，请忘记建立标准 Subject 作为身份验证结果，而是直接绑定 Shiro 特定的结果到线程本地存储。通过这种方式，您可以更方便地访问 SNAA，并避免使用 AccessControlContext（并遭受潜在的 性能损失），用于检索。

2. 子类SecurityManager，至少重写两个checkPermission方法，以便它们

   1. 如有必要，先将 Permission 参数转换为 Shiro 的 PDP (SPDP) 可以理解的内容
   2. 将线程本地 SNAA 和权限委托给 SPDP（如果 SPDP 信号访问拒绝，则抛出 SecurityException）。

   安全上下文接收重载可能会简单地忽略相应的参数。在应用程序初始化时，实例化并安装 (System::setSecurityManager) 您的实现。

---

2. 混合授权，将代码源与上下文不敏感的 SNAA 相结合

1. 以您认为合适的方式管理身份验证；再次将 Shiro 特定的 Subject 与线程本身关联起来。
2. 子类 SecurityManager，至少重写两个 checkPermission 方法，这一次它们委托给 SPDP 和/或重写的实现（进而调用 checkPermission，相应地，当前或提供的访问控制上下文）。对于任何给定的许可，应该咨询哪些（哪些）以及以什么顺序当然取决于实现。当两者都被调用时，应该首先查询 SPDP，因为它可能比访问控制上下文响应得更快。
3. 如果 SPDP 要另外处理对源自特定位置和/或一组代码签名者的代码授予的权限的评估，您还必须子类化 Policy，实现 implies(ProtectionDomain, Permission ) 这样，就像上面的 SecurityManager::checkPermission 一样，它传递一些可理解的域表示（通常只有它的 CodeSource）和权限参数 - 但逻辑上不是 SNAA - 是 SPDP。该实现应该尽可能高效，因为它将在 checkPermission 时针对每个域每个访问控制上下文调用一次。实例化并安装 (Policy::setPolicy) 您的实现。

---

3. 混合授权，将代码来源与 SNAA 相结合，两者都是上下文相关的

1. 按照您认为合适的方式管理身份验证。不幸的是，主题处理部分并不像在本例中创建 ThreadLocal 那样微不足道。

2. 子类化、实例化并安装一个 Policy，该策略分别执行 SecurityManager::checkPermission 和 Policy::implies 的组合职责第二种情况描述。

3. 实例化并安装标准的SecurityManager。

4. 创建一个 ProtectionDomain 子类，能够存储和公开 SNAA。

5. 作者¹ a DomainCombiner

   1. 由 SNAA 构建；

   2. 实现combine(ProtectionDomain[], ProtectionDomain[])，使得

      1. 它将第一个（“当前”上下文）数组参数的域替换为自定义实现的等效实例；
      2. 然后将第二个（“分配”或“继承”上下文）参数的参数（如果有）按原样附加到前一个参数；最后
      3. 返回连接。

   像Policy::implies一样，实现应该是高效的（例如通过消除重复项），因为每次getContext和checkPermission<时都会调用它/code> AccessController 方法是。

   


6. 身份验证成功后，创建一个新的 AccessControlContext 来包装当前的 AccessControlContext，以及自定义 DomainCombiner 的实例，进而包装 SNAA。包装要执行的代码
   该点在 AccessController::doPrivilegedWithCombiner 调用“内”，还传递替换访问控制上下文。

---

_{1   除了使用自定义域和您自己的组合器实现之外，还有一种看似更简单的替代方案，即将 SNAA 转换为 Principal 并使用标准 SubjectDomainCombiner，将它们绑定到当前 AccessControlContext 的域（如上所述，或者简单地通过主题::doAs）。这种方法是否会降低策略的效率主要取决于调用堆栈的深度（访问控制上下文包含多少个不同的域）。最终，您认为可以避免作为域组合器的一部分实现的缓存优化会在编写策略时对您产生影响，因此这本质上是您此时必须做出的设计决策。}