Keycloak集成Kerberos时Windows无票据用户弹出登录提示如何屏蔽

该问题本质是Windows系统SSPI认证层与Chromium/Edge、IE系列浏览器的默认行为差异：当服务端返回401 Unauthorized响应且携带WWW-Authenticate: Negotiate头时，Windows浏览器会优先调用系统接口拉取本地Kerberos票据，拉取失败就直接弹出原生认证提示框；Linux、macOS下的浏览器默认不会触发系统级弹窗，会自动降级走后续表单认证流程。你之前配置的Apache规则不生效，大概率是Kerberos协商逻辑直接在Keycloak/Wildfly层处理，Apache根本没有拦截到Keycloak返回的401响应头，规则自然不触发。

方案1：调整SPNEGO认证器配置（优先推荐，无侵入、不重启） #

这个方案完全匹配你内外网差异化认证的需求，不影响现有内网Kerberos SSO逻辑：

1. 登录Keycloak管理控制台，进入对应业务域，打开「认证」菜单，切换到你当前使用的浏览器认证流（不要直接修改默认browser流，建议基于默认流拷贝自定义流绑定到客户端）
2. 找到流中的SPNEGO认证节点，点击右侧「配置」，先做基础配置：
   • 将Kerberos required选项设置为disabled，保证Kerberos认证失败时自动降级到下一个认证器（用户名密码表单）
   • 如果你能梳理全内网IP段，直接在Client IP address filter项填入内网CIDR段，比如10.0.0.0/8,172.16.0.0/12,192.168.0.0/16，配置后仅内网IP请求会触发SPNEGO协商，外网IP直接跳过Kerberos流程走表单，从根源避免给外网Windows用户返回Negotiate挑战头，不会触发原生弹窗
3. 如果内网IP段无法全枚举，直接通过Keycloak管理API修改SPNEGO认证器的隐藏配置omitNegotiateHeaderIfNoToken为true：该配置开启后，服务端不会在首次未携带Kerberos票据的请求响应中返回WWW-Authenticate: Negotiate头，只有检测到请求携带Authorization: Negotiate开头的票据时才返回协商挑战，既不影响内网带票据用户的自动SSO，也不会让外网Windows用户收到挑战头触发弹窗。
   调用API的示例命令（替换为你环境的实际地址、管理员token、SPNEGO执行器ID即可）：

   curl -X PUT https://<keycloak访问地址>/auth/admin/realms/<业务域名>/authentication/executions/<SPNEGO执行器ID> \
   -H "Authorization: Bearer <管理员access_token>" \
   -H "Content-Type: application/json" \
   -d '{"config":{"omitNegotiateHeaderIfNoToken":"true"}}'
   

   配置实时生效，无需重启服务。

方案2：Wildfly Undertow层加响应头过滤（适配低版本Keycloak） #

如果你的Keycloak/RH-SSO版本较老，没有上述隐藏配置项，可以直接在底层Wildfly的Undertow子系统配置自定义过滤器，实现和方案1一致的效果：

1. 登录Wildfly的Jboss CLI控制台，执行命令添加表达式过滤器，规则为：非内网IP、且请求未携带Negotiate授权头时，自动删除响应中的WWW-Authenticate头：

   /subsystem=undertow/configuration=filter/expression-filter=removeSpnegoChallenge:add(expression="not regex(pattern='^(10\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.|192\\.168\\.)', value=%{i,REMOTE_ADDR}) and not regex(pattern='^Negotiate', value=%{i,Authorization}) -> response-header-remove(header-name='WWW-Authenticate')")
   

2. 将过滤器绑定到Keycloak对外服务对应的server/host节点：

   /subsystem=undertow/server=default-server/host=default-host/filter-ref=removeSpnegoChallenge:add()
   

3. 重启Wildfly服务生效。

方案3：认证流加UA条件判断（纯控制台可视化配置） #

如果不想调API、也不想改Wildfly底层配置，可以直接在现有认证流的SPNEGO节点前加一个「用户代理」条件执行器，配置规则为仅匹配内网域终端的UA特征时才执行SPNEGO认证，其余请求直接跳过SPNEGO走表单。该方案全程在控制台可视化操作，缺点是UA可以伪造，但外网用户无动力伪造UA触发Kerberos流程，完全满足常规使用需求。

• 全局传入prompt=login参数的方案会强制所有场景触发认证，直接破坏内网SSO体验，不建议使用
• 客户端侧修改权限、浏览器配置的方案需要适配所有终端，维护成本极高，不适合ToB/对外服务场景
• 所有配置上线前先分别用外网Windows设备、内网域设备验证：外网Windows设备访问直接跳表单无原生弹窗，内网域设备访问自动完成SSO即为配置正常。

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