Jetty 12.0.x SPNEGO：设置服务名，而不是完整 principal

配置 Jetty 12 认证时，把代理 URI、JAAS 用户和 GSS 服务组件区分开。

Jetty 的 SPNEGO 配置里涉及三个名字：用于匹配认证的 URI、通过 JAAS 登录的用户，以及为其申请票据的服务。三者用途不同。

在 Jetty 12.0.x 的实现中，认证对象的一个片段是：

var auth = new org.eclipse.jetty.client.SPNEGOAuthentication(
    java.net.URI.create("http://proxy.example:8080"));
auth.setServiceName("HTTP");

这个片段只说明服务组件，并不是完整的代理认证方案。JAAS 登录、代理路由和请求的认证交换仍然各自独立。

在该实现中，Jetty 通过组合 getServiceName()、@ 字符和认证交换所用的主机来构造基于主机的 GSS 名称。若把 [email protected] 作为服务组件传入，就会再附加一个主机。应阅读该 setter 的约定，而不是假定它接受完整的 Kerberos principal。

得到的 GSS 名称在概念上形如 HTTP@hostname。KDC 中对应的服务 principal 通常表示为 HTTP/hostname。选定的代理名称必须与实际注册的服务一致 对该账户而言；IP 地址或别名可能会选中另一个票据目标。

也要检查 407 路径

在 Jetty 12.0.x 中，authenticate() 从 request.getHost() 取得 GSS 主机名，并使用默认的 Authorization 头构造结果。按代理 URI 匹配认证对象本身并不会把这些选择改成代理的主机名和 Proxy-Authorization。

因此代理集成需要正确的请求主机，以及针对该交换的代理作用域结果。HTTPS CONNECT 请求与普通源请求可能有不同的主机值。应确认已安装实现的行为，而不是假定服务名 setter 会提供完整的 407 流程。

对于 407，检查该请求使用的代理认证交换和主机。401 属于源认证。仅有有效的用户票据并不能证明 Jetty 申请了正确的服务票据，也不能证明中间方接受了它。

相关文章