基于Custom Java Provider的Cognos认证Windows客户端SSO配置问题

服务器端自定义认证Provider运行正常、Web端SSO生效但Windows客户端反复跳转自定义登录页的核心原因是：Windows客户端不经过Web端的Cookie/浏览器跳转链路，是通过二进制RPC通道直连Cognos Dispatcher完成认证的，现有Provider的SSO逻辑大多只适配了Web请求场景，没有覆盖客户端的认证交互流程。

一、自定义Java Provider侧的必要适配 #

• 抽离公共的SSO身份识别逻辑：不要把身份提取逻辑绑定在Web请求的Header、Cookie、Session上下文里，重写Provider的gtAuthenticate接口时，要同时支持Web渠道、RPC渠道的身份识别逻辑，避免客户端请求因为读不到Web上下文的凭证被引导到登录页。
• 增加客户端请求的识别分支：通过请求来源的端口、调用进程标识判断请求来自Windows客户端时，直接走本地Windows域身份的提取流程，不要执行Web场景的302跳转自定义登录页的逻辑。
• 去掉客户端请求的强制凭证校验：如果检测到有效本地域身份，直接完成身份映射，不要对客户端请求抛出要求输入用户名密码的异常。

二、Cognos Analytics服务器端的配置调整 #

• 进入Cognos Administration的安全配置页，找到自定义认证Provider的高级参数，开启允许非Web渠道请求触发SSO的开关，规避服务器对非浏览器来源请求的强制登录校验（对应规避CAM-CR-1018的强制认证拦截）。
• 取消全局配置里的"强制Web表单认证"选项：这个配置会把所有非浏览器来源的请求强制重定向到Web登录页，直接阻断Provider的SSO逻辑触发。
• 确认Dispatcher的访问控制列表：所有安装了对应Windows客户端的机器IP要在允许访问范围内，不会被网关层拦截身份凭证的传递。

三、Windows客户端本地配置操作 #

• 打开客户端自带的Cognos Configuration工具，把Analytics服务器的连接地址配置为Dispatcher直连地址，不要配置Web网关的跳转地址，正确格式为http://<Cognos服务器IP>:9300/p2pd/servlet/dispatch。
• 客户端认证模式选择：不要勾选"使用第三方Web认证"选项，保持和服务器端自定义Provider的认证模式同步，避免客户端先请求Web登录页再跳转。
• 开启本地SSO关联：在客户端的Cognos配置里，勾选"使用当前Windows登录身份发起连接"选项，让客户端在建立RPC连接时自动传递当前登录的域用户凭证。
• 严格对齐版本号：确保客户端的大版本、补丁包版本和Analytics服务器完全一致，版本差超过1个小版本会导致RPC通道的凭证加密协议不兼容，SSO会直接失效。

四、排查常见失效场景 #

• 仍然跳转自定义登录页：查看服务器端cogserver.log日志，过滤自定义Provider的输出日志，确认客户端发起连接时Provider是否收到了有效的身份参数。如果没有收到，检查客户端连接地址是不是错配置成了Web网关的端口（比如9300以外的80/443端口）。
• 认证后报权限不足：检查Provider内的角色映射逻辑，确保Windows域身份对应映射到Cognos的内置功能角色（比如内容管理员、普通报表用户），不要只给Web端的用户条目关联角色。
• SSO间歇性失效：打开Windows凭据管理器，把配置的Cognos服务器地址添加到凭据存储列表，避免系统弹出凭证输入框阻断自动身份传递流程。

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