java - JAAS＆amp; JACC：我如何踢出用户？

_{关于术语的说明：}

_{身份验证机制（AM）在此指的是负责制作与身份验证调用者实体的身份相关的注册/建立的身份验证声明的任何组件与/在Java EE运行时中。这些组件可能特定于Application Server（AS）或Java EE标准; AS实现细节或类型，由Java EE应用程序开发人员进行扩展;部署为Java EE应用程序的一部分或作为AS的一部分。其中一个组件是 JAAS LoginModule（LM）。虽然 Identity Store（IS）似乎是用于指代（以及其他事物）LM的（半）规范术语，但我希望将其保留用于特定于应用程序的持久层（例如代表您的用户的 JPA @Entity）类型，因此必须建立此（不明确的）区别。＆＃34;你为什么模糊不清？＆＃34;，你可能会问，＆＃34;你不能称LM为LM吗？＆＃34;。因为我对JBoss LMs一无所知！事实上，我既不是JBoss用户，也不是在Java EE中使用JAAS的人。不过，我觉得我可以为一般情况提供答案，因此不可避免地含糊不清。}
_{已停用的用户指的是缺少更好的术语，指向您被踢出的用户＆＃34;即用户的权利（组，角色，权限 - 无论它们在那里被调用的是什么）已经在IS级别以某种方式被撤销。}

<小时/> 首先，没有标准的Java EE API会将任意用户的Subject或HttpSession公开给您的代码。理论上你可以自己记录这些信息，例如：在身份验证期间，但我会假设这不是你想要的。此外，关于Subject具体而言，虽然没有标准明确禁止在Principal代表服务请求期间修改其（Subject /凭证集合），没有人说它有是其中之一。实际上甚至不清楚当前身份验证的来电者Subject - 在身份验证期间填充的那个，并且可以通过 JACC ＆＃39;来检索。 s "javax.security.auth.Subject.container" PolicyContextHandler - 必须与运行时在Policy进行授权决策时查询的数据结构一致;也就是说，运行时可能只为您提供副本，在内部使用完全不同的经过身份验证的调用方表示，或者介于两者之间。因此，即使您能够修改Subject，这样做也不一定会影响有效的安全上下文。

继续可以完成的事情。您的需求可以通过身份验证和/或授权方面解决，前一种方法比后一种方法更容易使用。由于您没有回答我的评论，我将简要介绍其可能的答案。

禁止来电者重新认证

一旦应用程序停用了用户，它必须以某种方式指示AM在其发出的后续请求中停止重新验证它们。为了减少耦合，应用程序通常不会直接与AM通信，而是满足后者评估的某些条件。例如，应用程序可能会分配一些特殊的＆＃34; locked_out＆＃34;权限给用户，或设置HttpSession属性。当要求重新验证停用的用户时，AM将确认停用并拒绝重新验证它们。随后它将使用户的会话无效。它究竟是如何实现的，取决于它的种类和实现。您的LM可能必须为此目的利用"javax.servlet.http.HttpServletRequest" JACC PolicyContextHandler。 JASPIC ServerAuthModule可以立即访问请求实例，并将其作为validateRequest参数接收。其他一些组件可能不得不求助于使用AS内部，或者使应用程序承担会话失效的责任（某些调用拦截组件，例如 Servlet Filter）第二次查询IS并采取相应行动。）

上述方法显然需要能够修改AM的功能。另外，高速缓存AM需要在重用其先前建立的认证结果之前评估所述去激活条件。最后，如评论中所述，如果在用户的IS访问撤销时，代表该用户的请求正在被服务（已经到达/已经过认证）发生访问撤销事件），该请求的服务将正常完成（除非应用程序请求重新验证该用户，例如通过HttpServletRequest#（login | { {1}}）。

禁止来电者重新授权

正如我在开头提到的那样，用户＆＃39; authenticate不容易检索/修改，支持Subject，在符合JACC标准的Java EE运行时，实际上是这样的。{1}}。遗憾的是，默认的AS提供的JACC提供程序（Policy + PolicyConfiguration）有一个严重的限制：它只允许您在Java EE 角色上运行，而不是在调用者身上运行{ {1}} 映射到，即＆＃34;拥有＆＃34;，这些角色。例如，默认提供程序允许您扩展Policy映射到＆＃34; admin＆＃34;的Principal。角色有;它允许你删除＆＃34; admin＆＃34;角色及其所有Permission;但不允许你决定谁成为＆＃34; admin＆＃34; - 至少不是以标准方式。

就JACC而言，这个限制基本上让你有两种选择：要么让AM添加一个＆＃34;虚拟＆＃34; 群组 Principal到每个来电者Permission，其名称与相应来电者Principal的名称相同。然后，在用户停用后，添加（通过Subject）与＆＃34;虚拟＆＃34;相关的术语Principal。组。最后，检查（例如通过AccessController＃checkPermission）＆＃34; application-space＆＃34;代码用户是否拥有PolicyConfiguration#addToRole，如果是，请将其踢出。但等等，这完全没有意义 - 如果它本身无法处理授权，为什么还要先使用Permission呢？另一种方法是创建和安装您自己的JACC提供程序。这样做可以让您完全控制Permission - /组到角色的映射，并使您能够在授权方面采取相应的行动，从那时起依据该信息。编写新的提供程序是非常重要的，特别是因为它必须满足 JRE-wide 的授权需求，而不仅仅是在单个应用程序的范围内。我怀疑你的要求证明了一定数量的高工作量。如果你仍然想要沿着这条道路走下去，关于Arjan Tijms的JACC相关文章＆＃39; blog是一个很好的起点。

JAAS＆amp; JACC：我如何踢出用户？

1 个答案: