如何在Java中协商Kerberos/NTLM令牌实现WIA HTTP代理？

你的思路的核心问题 #

WIA（通常基于NTLM或Kerberos协议）是挑战-响应式的认证机制，无法一次性生成可直接复用的Authorization头令牌：

• NTLM需要3次交互（Type1请求→Type2挑战→Type3响应），令牌依赖服务器返回的动态挑战值
• Kerberos的服务票据绑定特定目标服务、客户端身份和有效期，不能通用所有请求
  因此直接生成通用令牌的思路不成立，代理必须完整参与与目标服务器的认证协商流程。

正确的实现方向 #

1. 代理需完整处理WIA协商流程 #

代理作为域内身份载体，需要替域外浏览器完成与目标服务器的认证交互：

• 拦截浏览器的请求，转发给目标服务器
• 若服务器返回401 Unauthorized并携带WWW-Authenticate: NTLM或Negotiate头，触发认证流程
• 代理使用域内账号生成对应协议的认证消息，与服务器完成多轮交互，获取认证通过的会话
• 将认证通过后的响应返回给浏览器，并维护该目标服务器的认证上下文，后续请求复用已建立的会话

2. Java中实现WIA认证的工具 #

NTLM协议实现（推荐使用jcifs-ng库）

import jcifs.ntlmssp.NtlmContext;
import jcifs.ntlmssp.NtlmPasswordAuthentication;
import java.util.Base64;

// 初始化NTLM认证上下文（使用域账号密码）
NtlmPasswordAuthentication auth = new NtlmPasswordAuthentication("YOUR_DOMAIN", "DOMAIN_USER", "USER_PASSWORD");
NtlmContext ntlmContext = new NtlmContext(auth);

// 生成Type1消息，发送给服务器
byte[] type1 = ntlmContext.initSecContext(new byte[0], 0, 0);
String type1Encoded = Base64.getEncoder().encodeToString(type1);
// 构造请求头：Authorization: NTLM <type1Encoded>

// 从服务器响应中提取Type2挑战
String wwwAuthHeader = serverResponse.getHeader("WWW-Authenticate");
byte[] type2 = Base64.getDecoder().decode(wwwAuthHeader.split(" ")[1]);

// 生成Type3响应，完成认证
byte[] type3 = ntlmContext.initSecContext(type2, 0, type2.length);
String type3Encoded = Base64.getEncoder().encodeToString(type3);
// 构造请求头：Authorization: NTLM <type3Encoded>

Kerberos协议实现（使用JDK自带GSSAPI）

首先配置JAAS配置文件（krb5.conf），指定KDC地址和域信息，然后通过GSSAPI获取服务票据：

import javax.security.auth.Subject;
import javax.security.auth.login.LoginContext;
import org.ietf.jgss.GSSContext;
import org.ietf.jgss.GSSManager;
import org.ietf.jgss.GSSName;
import java.util.Base64;

// 登录Kerberos域
LoginContext lc = new LoginContext("KerberosClient");
lc.login();
Subject subject = lc.getSubject();

// 获取目标服务的GSS上下文
GSSManager manager = GSSManager.getInstance();
// 服务名格式：HTTP/<server-hostname>@DOMAIN.COM
GSSName serverName = manager.createName("HTTP/target-server.your-domain.com@YOUR_DOMAIN.COM", GSSName.NT_HOSTBASED_SERVICE);
GSSContext context = manager.createContext(serverName, null, null, GSSContext.DEFAULT_LIFETIME);

// 生成Negotiate令牌
byte[] token = context.initSecContext(new byte[0], 0, 0);
String negotiateToken = Base64.getEncoder().encodeToString(token);
// 构造请求头：Authorization: Negotiate <negotiateToken>

3. 结合BrowserMobProxy的改造 #

BrowserMobProxy支持请求/响应拦截，可以在代理逻辑中加入认证处理：

• 拦截服务器返回的401响应，触发WIA协商流程
• 完成认证后，将有效的Authorization头添加到当前请求的重试请求中
• 维护每个目标服务器的认证上下文缓存，避免重复协商（注意会话隔离，防止不同Selenium会话的认证冲突）

4. 潜在注意事项 #

• Kerberos要求代理服务器必须在域内，且配置正确的DNS和KDC地址，否则无法获取服务票据
• NTLM需要存储域账号的明文密码（Windows环境下可通过SSPI获取当前用户凭证，但跨平台Java实现需明文）
• 部分服务器要求认证绑定TCP连接，代理需保持连接复用，否则每新建连接都要重新认证

内容的提问来源于stack exchange，提问作者Adrian Diemer