java - JAAS＆JACC:如何将用户赶出去？

Question

我们目前正在使用JBoss EAP 6.4 / 7.0来采用JAAS和JACC。简要说明一下我们如何应用事物：


我们使用HttpServletRequest.login(...)进行身份验证
随后，我们使用HttpServletRequest.logout()注销。
我们有一个LoginModule，用于验证凭据并准备角色。


一切都很好，但是，我的应用程序的一部分必须允许一组特定的用户能够：


撤销其他人的角色以登录系统，并且
将他们踢出任何当前活动的会话。


第一部分很简单，但是我很难弄清楚如何使某人的会话无效。我有办法以某种方式掌握其他用户的主题/会话并使它无效吗？

非常感激

Answer 1

注意事项：


认证机制（AM）在本文中是指负责在Java EE运行时中使用/进行与认证的调用方实体有关的身份验证语句并由此注册/建立其身份的任何组件。这样的组件可能特定于应用服务器（AS）或Java EE标准。用于Java EE应用程序开发人员扩展的AS实现细节或类型；部署为Java EE应用程序的一部分或AS的一部分。这样的组件之一就是您的JAAS LoginModule（LM）。身份存储（IS）似乎是当今（除其他外）用于指代LM的（半）规范性术语，但我想将其保留给您的特定于应用程序的持久层（例如JPA @Entity）类型，该类型表示您的用户，因此必须建立这种（不确定的）区别。您可能会问：“您为什么要含糊？”您不能只将LM称为LM吗？因为我对JBoss LM一无所知！实际上，我既不是JBoss用户，也不是在Java EE中使用JAAS的人。尽管如此，我还是觉得我可以为适用于一般情况的问题做出贡献，因此不可避免地会产生模糊性。
由于缺乏更好的用语，已停用的用户是指您的“被踢出用户”，即，其权限（组，角色，权限（无论在那里被调用）的用户）已被撤销的用户在IS层面上有所不同。



首先，没有标准的Java EE API会将任意用户的Subject或HttpSession公开给您的代码。从理论上讲，您可以自己记录该信息，例如在身份验证期间，但是我将假定这不是您想要的。此外，特别是关于Subject，尽管没有任何标准明确地禁止代表Principal的请求在服务期间修改其（Subject /凭据集合），但是没有一个标准指出必须是。实际上，甚至还不清楚当前通过身份验证的调用方的Subject（在身份验证期间填充并可以通过JACC的"javax.security.auth.Subject.container" PolicyContextHandler检索的那个）是否必须与运行时查询Policy时使用的数据结构一致。授权决定；也就是说，运行时可能只为您提供一个副本，或者在内部使用完全不同的身份验证调用方表示形式，或二者之间的任何方式。因此，即使您能够修改Subject，这样做也不一定会影响有效的安全上下文。

前进到可以做什么。您的需求可以在身份验证和/或授权方面得到解决，前一种方法比后一种方法要容易得多。由于您未回答我的评论，因此我将简要介绍其两个可能的答案。

禁止呼叫者重新认证

一旦应用程序停用了用户，它就必须以某种方式指示AM停止对他们发出的后续请求进行重新认证。为了减少耦合，应用程序通常将不直接与AM通信，而是满足后者评估的某些条件。例如，应用程序可能为用户分配了一些特殊的“ locked_out”权限，或者设置了HttpSession属性。当要求重新认证已停用的用户时，AM将确认已停用并拒绝对其进行重新认证。随后，它将使用户会话无效。它到底将如何完成取决于它的种类和实现。为此，您的LM可能必须利用"javax.servlet.http.HttpServletRequest" JACC PolicyContextHandler。 JASPIC ServerAuthModule作为validateRequest自变量接收到请求实例后，便可以立即访问该请求实例。某些其他组件可能不得不诉诸于使用AS内部构件，或者使应用程序承担会话无效的责任（某些呼叫拦截组件，例如Servlet Filter，将不得不第二次查询IS并采取行动。相应地）。

前述方法显然需要修改AM功能的能力。另外，缓存AM需要在重新使用其先前建立的认证结果之前评估所述停用条件。最后，如评论中所述，如果在用户的IS访问撤消时，代表该用户的请求正在接受服务（在发生访问撤消事件之前已到达/已通过身份验证） ，则该请求的服务将正常完成（除非应用程序例如通过HttpServletRequest#（login | authenticate）请求对该用户进行重新认证。

禁止呼叫者重新授权

正如我在开始时提到的那样，虽然用户的Subject很难被检索/修改，但在符合JACC的Java EE运行时上，这些Policy实际上是被授权的。不幸的是，默认的AS提供的JACC提供程序（PolicyConfiguration + Policy）有一个严重的限制：它仅允许您在Java EE角色上进行操作，而不能在映射到（即“具有”）调用方Principal上进行操作，这些角色。例如，默认提供程序允许您扩展映射到“ admin”角色的Permission所具有的Principal。它允许您删除“ admin”角色及其所有Permission；但是它不允许您决定谁将成为“管理员”，至少不能以标准方式。

就JACC而言，此限制基本上为您提供了两种选择：让AM向每个呼叫者的Principal添加一个“虚拟”组Subject，其名称与各自呼叫者的Principal相同。然后，在停用用户后，添加（通过PolicyConfiguration#addToRole）与“虚拟”组有关的custon Permission。最后，从“应用程序空间”代码中检查（例如，通过AccessController＃checkPermission）用户是否具有Permission，如果有，将其踢出。但是，等等，这是完全没有意义的，如果它不能自行处理授权，为什么还要首先使用Policy？另一种方法是编写并安装自己的JACC提供程序。这样做将使您能够完全控制Principal-/组到角色的映射，并使您可以采取任何行动，但是您可以在以后的授权时间范围内使用该信息。但是，编写新的提供程序并非易事，特别是因为它必须满足JRE范围内的授权需求，而不仅仅是在单个应用程序的范围内。我怀疑您的要求是否足以证明如此高的工作量。如果您仍然想走这条路，那么关于Arjan Tijms的blog的JACC相关文章就是一个很好的起点。