基于Tomcat的Spring Security Kerberos REST API SSO权限配置问题

我来帮你梳理并解决这个权限控制的问题，针对你的疑问和遇到的错误逐个分析：

疑问解答 #

1. 是否必须用Tomcat账户运行Tomcat服务？ #

没错，这是必须的。你已经为HTTP/apirest.domain@DOMAIN这个SPN绑定了Tomcat域用户，Kerberos的服务端认证依赖运行服务的账户持有对应的SPN，这样客户端发送的Kerberos票据才能和服务端身份匹配。如果用其他账户启动Tomcat，SPN和运行主体不匹配，认证直接就会失败。

2. 当前Kerberos安全配置方式是否正确？ #

你的基础配置步骤（创建域用户、注册SPN、生成keytab）是完全正确的，但API层面的配置还有适配空间——尤其是针对REST无状态场景的认证入口，以及LDAP用户信息查询的部分。你参考的两个项目思路没问题，RoleStrippingLdapUserDetailsMapper替代默认的权限填充器是个不错的选择，但需要确保LDAP配置没有遗漏关键参数。

3. 如何消除匿名上下文问题？ #

这个错误"Property 'userDn' not set - anonymous context will be used for read-write operations"的核心原因是：你的LDAP配置没有指定用于查询AD用户/群组信息的绑定账号和密码。默认情况下Spring Security会尝试用匿名上下文访问LDAP，但绝大多数AD环境是禁止匿名查询用户数据的，所以你需要在LDAP配置中明确指定一个有AD查询权限的域账号（可以用你创建的Tomcat域用户，或者专门的查询服务账号）。

4. 匿名上下文在Tomcat启动后即设置，如何在用户发起REST请求后再获取上下文？ #

其实Spring Security的Kerberos认证流程是在请求阶段触发的，启动时的LDAP上下文初始化只是预配置连接池。你不需要刻意延迟上下文创建，只要配置了合法的绑定账号，启动时就会建立合法的LDAP连接池，后续请求时直接复用这个池来查询当前登录用户的信息即可。匿名上下文的问题本质还是因为你没配置绑定账号导致的，解决了这个问题，启动时的上下文就是合法的，不会影响后续请求。

具体配置调整建议 #

1. 修正LDAP配置，添加绑定账号信息 #

如果你用的是ActiveDirectoryLdapAuthenticationProvider，需要补充userDn和password配置：

@Bean
public ActiveDirectoryLdapAuthenticationProvider adLdapAuthProvider() {
    ActiveDirectoryLdapAuthenticationProvider provider = 
        new ActiveDirectoryLdapAuthenticationProvider("DOMAIN", "ldap://your-domain-controller:389/");
    provider.setConvertSubErrorCodesToExceptions(true);
    provider.setUseAuthenticationRequestCredentials(true);
    // 指定用于AD查询的绑定账号（用你创建的Tomcat域用户即可）
    provider.setUserDn("CN=Tomcat,OU=ServiceAccounts,DC=domain,DC=com");
    provider.setPassword("your-tomcat-user-password");
    // 替换为你自定义的RoleStrippingLdapUserDetailsMapper
    provider.setUserDetailsContextMapper(customLdapUserDetailsMapper());
    return provider;
}

如果是直接配置LdapContextSource，则需要显式设置绑定参数：

@Bean
public LdapContextSource ldapContextSource() {
    LdapContextSource contextSource = new LdapContextSource();
    contextSource.setUrl("ldap://your-domain-controller:389/");
    contextSource.setBase("DC=domain,DC=com");
    contextSource.setUserDn("CN=Tomcat,OU=ServiceAccounts,DC=domain,DC=com");
    contextSource.setPassword("your-tomcat-user-password");
    return contextSource;
}

2. 适配REST场景的Kerberos认证入口 #

原示例的EntryPoint是针对Web页面的跳转逻辑，REST场景需要返回401 Unauthorized并携带Negotiate响应头，触发客户端发起Kerberos认证。你可以自定义一个EntryPoint：

public class KerberosRestAuthEntryPoint implements AuthenticationEntryPoint {
    @Override
    public void commence(HttpServletRequest request, HttpServletResponse response, 
                         AuthenticationException authException) throws IOException {
        response.addHeader("WWW-Authenticate", "Negotiate");
        response.setStatus(HttpServletResponse.SC_UNAUTHORIZED);
    }
}

然后在SecurityFilterChain中配置这个EntryPoint：

@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
    http
        .authorizeHttpRequests(auth -> auth
            // 限制AD特定群组访问指定资源
            .requestMatchers("/api/your-protected-resource/**").hasRole("YOUR_AD_GROUP_NAME")
            .anyRequest().permitAll()
        )
        .exceptionHandling(ex -> ex
            .authenticationEntryPoint(new KerberosRestAuthEntryPoint())
        )
        .authenticationProvider(adLdapAuthProvider())
        .addFilterBefore(spnegoAuthenticationProcessingFilter(), BasicAuthenticationFilter.class);
    return http.build();
}

3. 验证SPN和keytab的有效性 #

可以用kinit命令验证keytab是否能正确获取Kerberos票据：

kinit -kt tomcat.keytab HTTP/apirest.domain@DOMAIN

如果命令执行成功且没有报错，说明你的SPN和keytab配置是没问题的。

额外注意事项 #

• 确保Tomcat的krb5.conf配置正确，指向你的域控制器和Kerberos Realm。
• 客户端环境需要支持Kerberos：Windows客户端如果已加入域会自动处理；Linux客户端需要配置krb5.conf并通过kinit获取票据。
• 检查AD中Tomcat用户的权限，确保它有读取用户属性和群组信息的权限。

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