避免Kerberos票据在HTTP请求后失效：单次请求即过期问题排查

我之前也碰到过一模一样的问题，结合你基于GSS-API的Java实现场景，咱们来拆解下这个“单票只能单次使用”的核心问题：

1. SPNEGO Token被服务端的重放防护拦截 #

你提到把票据作为HTTP请求的一部分，这里大概率是踩了SPNEGO Token复用的坑：Kerberos服务票本身在生命周期内是可以多次使用的，但通过GSS-API生成的SPNEGO认证Token是单次有效的——因为大多数服务端会开启重放攻击防护，会记录已经处理过的Token，重复发送同一个Token会直接被拒绝。

解决办法：

• 不要复用之前生成的SPNEGO Token，而是每次发起HTTP请求时，基于同一个有效票据重新生成新的Token。票据可以缓存复用（只要在有效期内），但Token必须每次请求都重新生成。

2. GSSContext被提前销毁或状态异常 #

如果你的代码在完成一次请求后调用了GSSContext.dispose()，或者复用了已经进入完成状态的GSSContext实例，会导致关联的票据资源被销毁，无法再用于后续请求。

解决办法：

• 每次请求都创建全新的GSSContext实例，使用缓存的有效票据初始化上下文，生成Token后再销毁当前上下文。不要尝试复用GSSContext。

3. 票据缓存逻辑存在漏洞 #

你修改了票据生命周期，但可能代码里的缓存逻辑有问题：

• 比如多线程环境下，票据变量没有正确同步，导致后续请求拿到的是已失效的引用；
• 或者KerberosTicket的isCurrent()方法被误判，你可以在复用前打印票据的getStartTime()和getEndTime()，确认它确实还在有效期内。

解决办法：

• 用线程安全的容器（比如ConcurrentHashMap）缓存票据，每次复用前先校验票据的起止时间；
• 如果票据过期，再重新向KDC申请新票据。

可复用的代码示例 #

这里给你一个简化的“缓存票据+每次请求生成新Token”的代码片段：

// 假设已经通过GSS-API获取到有效KerberosTicket，缓存到全局线程安全变量中
private static volatile KerberosTicket cachedTicket;
private static final Object TICKET_LOCK = new Object();

public void sendAuthenticatedRequest(String url) throws Exception {
    KerberosTicket ticket = getValidTicket();
    if (ticket == null) {
        throw new RuntimeException("Failed to get valid Kerberos ticket");
    }

    GSSManager manager = GSSManager.getInstance();
    Oid krb5Oid = new Oid("1.2.840.113554.1.2.2");
    // 替换为你的服务SPN
    GSSName serverName = manager.createName("HTTP/your-service-domain.com", GSSName.NT_HOSTBASED_SERVICE);

    // 每次请求创建新的GSSContext
    try (GSSContext context = manager.createContext(serverName, krb5Oid, ticket, GSSContext.DEFAULT_LIFETIME)) {
        context.requestMutualAuth(false); // 根据服务端需求调整是否需要双向认证
        byte[] token = context.initSecContext(new byte[0], 0, 0);
        String authHeader = "Negotiate " + Base64.getEncoder().encodeToString(token);

        // 发送HTTP请求
        HttpURLConnection conn = (HttpURLConnection) new URL(url).openConnection();
        conn.setRequestProperty("Authorization", authHeader);
        // 处理请求响应...
        int responseCode = conn.getResponseCode();
        System.out.println("Response code: " + responseCode);
    }
}

// 获取有效票据：如果缓存的票据有效则复用，否则重新获取
private KerberosTicket getValidTicket() throws Exception {
    if (cachedTicket != null && cachedTicket.isCurrent()) {
        return cachedTicket;
    }

    synchronized (TICKET_LOCK) {
        if (cachedTicket != null && cachedTicket.isCurrent()) {
            return cachedTicket;
        }
        // 这里调用你的票据获取逻辑，替换为实际代码
        cachedTicket = obtainKerberosTicketViaGSSAPI();
        return cachedTicket;
    }
}

// 你的原始票据获取方法
private KerberosTicket obtainKerberosTicketViaGSSAPI() throws Exception {
    // 这里是你基于GSS-API获取票据的实现代码
    // ...
}

额外验证点 #

• 检查KDC端的策略：代码中设置的票据生命周期可能会被KDC的全局策略覆盖，确保KDC允许的票据有效期足够长（比如1小时）；
• 开启Kerberos调试日志：在JVM启动参数中添加-Dsun.security.krb5.debug=true，查看票据的获取、使用日志，排查是否有票据被标记为无效的细节。

内容的提问来源于stack exchange，提问作者Juan Ga