3

自从我完成 JASPIC 工作以来，已经过了很长时间了。

我有一个web.xml看起来像这样的：

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
                             http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
  <security-constraint>
    <web-resource-collection>
      <web-resource-name>service-broker-related-resources</web-resource-name>
      <url-pattern>/v2/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
      <role-name>emcc</role-name>
    </auth-constraint>
  </security-constraint>

  <login-config>
    <auth-method>BASIC</auth-method>
    <realm-name>Frob Service Broker</realm-name>
  </login-config>

  <security-role>
    <role-name>emcc</role-name>
  </security-role>

</web-app>

我还设置并安装了服务器身份验证模块 (SAM)。在我的glassfish-web.xml喜欢中提到过：

<!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd">
<glassfish-web-app httpservlet-security-provider="emccSAM">

我的 SAM 工作正常。

事实上，它的效果有点太好了！它正在拦截所有请求，而不仅仅是由<url-pattern>of标识的请求/v2/*。这最初让我感到惊讶。

但是当我仔细考虑这一点时，我认为这有一定的意义：SAM 现在负责身份验证，而不是容器，真的。

那么web.xml现在本质上是无关紧要的吗？

然后我想了更多，很明显它是相关的，因为它的内容也说明了身份验证发生后要做什么，即如果用户通过 SAM 成功验证，现在检查她是否具有emcc角色。如果她没有，并且大概请求以 开头/v2/，那么我们将她赶出去。如果她不这样做，并且大概是从其他任何内容开始请求，那么我们就让她进来。

那么，我的 SAM 必须自行有效地决定传入的请求是否值得验证，这是预期的行为吗？ 我希望我的 SAM 会“正常”触发，即仅当有人尝试访问需要身份验证的 URI 时，如<security-constraint>.

可能值得注意的是，唯一起作用的 servlet 是当 JAX-RSApplication类使用@ApplicationPath("/v2").

4

1 回答 1

2

SAM 确实完全负责身份验证。它可能尊重声明性配置，但不是必须的。它甚至可以完全自己执行 Servlet 请求的授权（尽管这样做会远远超出其合同的范围）。

根据 JASPIC 规范的第 3.8.3 节，强制要求在“满足相应连接要求的每个请求”上validateRequest调用已配置的ServerAuthContext（因此在这种情况下也是单个封装的 SAM）。

如果 SAM 希望知道 Servlet 端点是否应该（描述符或注释）被认为是“受保护的”，它可能会在初始化时调用中继给它isMandatory的request MessagePolicy参数，或者在消息身份验证时探测MessageInfo参数的映射键和映射值的存在"javax.security.auth.message.MessagePolicy.isMandatory"等于Boolean.valueOf(value).booleanValue() == true（规范§ 3.8.1.1）。

最后但同样重要的是——声明性安全约束与授权无关吗？首先，我不确定各种规格是否适合 SAM 分配未声明的角色。除此之外，我从来没有尝试过这个，所以我只能猜测并在这一点上提供一个模糊的答案。我对此的看法是，它或多或少与身份验证提供者的情况相同。本质上，您负责在 AS 之外配置提供程序，因此您必须以某种方式进行补偿，即提供替代配置接口。假设授权由一些 JACC 提供程序管理。如果它是 AS 提供的默认设置，那么在没有声明性安全约束的情况下，它将无法确认调用者需要在"emcc"角色为了访问/v2/*资源的集合，即有一个等价物WebRoleRefPermission映射到他们的Principal；因此，Policy::implies将始终授予访问权限。但是手工制作的提供者，比如定制的 SAM，可以从其他地方检索这些知识，这样@RolesAllowed委托给它的朋友们仍然可以工作。毕竟，Java EE 安全模型——包括填充Subjects 的“管道”、将它们绑定到请求的线程AccessControlContext、处理Subject::doAs(Privileged)调用等等——并不是无关紧要的，只是提供者如何获得约束有。自然，您的要求是否证明麻烦的问题仍然存在。

于 2017-12-04T11:20:14.323 回答