CAS协议验证接口完整指南serviceValidate与proxyValidate详解【免费下载链接】rubycas-serverProvides single sign-on authentication for web applications, implementing the server-end of Jasigs CAS protocol.项目地址: https://gitcode.com/gh_mirrors/ru/rubycas-serverrubycas-server是一个基于 Ruby 的 CASCentral Authentication Service服务器端实现为 Web 应用提供单点登录认证。它的核心职责就是响应应用端发起的CAS 协议验证请求其中最常用的两个验证接口是serviceValidate和proxyValidate——应用把用户带来的ticket交给它们它们回答这个用户是谁、是否有效。验证接口在单点登录中的位置先建立整体感觉。CAS 的认证流程分为 6 步用户访问受保护页面应用将浏览器重定向到 CAS 服务器的登录页用户在 CAS 登录页输入账号密码CAS 服务器向数据源AD、LDAP、SQL 数据库等验证凭据验证通过后CAS 向浏览器签发一张Service Ticket服务票据并重定向回应用应用拿着这张 ticket 调用 serviceValidate / proxyValidate 接口向 CAS 验证票据——这就是本文主角验证成功则用户完成登录失败则回到登录页。第 5 步就是验证接口的用武之地用户与 CAS 之间的信任凭证ticket必须经服务器确认应用才能安全地放行。票据的生命周期管理过期、防重放由 lib/casserver/cas.rb 统一负责。serviceValidate最常用的 CAS 验证接口GET /serviceValidate是 CAS 协议 2.5.1 节定义的标准验证端点适用于绝大多数应用直接向 CAS 验证用户的场景。路由定义见 lib/casserver/server.rb。请求参数一览参数是否必填作用service✅发起验证的应用 URL必须与签发票据时登记的 service 一致ticket✅用户登录后拿到的服务票据形如ST-xxxxpgtUrl❌代理回调地址传入后 CAS 会生成 PGT 并在响应中返回 IOUrenew❌要求重新交互认证五道关卡CAS 如何审查一张票据无论调用哪个验证接口票据都要通过同一套审查逻辑实现于 lib/casserver/cas.rb参数完整性service或ticket缺失 →INVALID_REQUEST防重放票据只能使用一次。验证成功后立即标记 consumed见 lib/casserver/model/consumable.rb第二次提交同一票据 →INVALID_TICKETalready been used up票据类型serviceValidate拒绝代理票据ProxyTicket传入 PT 会报INVALID_TICKET有效期票据自创建起超过未使用期限默认5 分钟可在 config/config.example.yml 中通过maximum_unused_service_ticket_lifetime调整→ 过期错误Service 匹配请求的service与票据签发时绑定的应用必须完全一致否则 →INVALID_SERVICE。此外两个接口都支持allowed_service_ips白名单校验见 lib/casserver/server.rb若配置了该选项白名单外的 IP 调用验证接口会直接收到INVALID_REQUEST失败响应这是防止第三方应用冒用 CAS 套取用户信息的重要防线。响应格式成功与失败长什么样接口强制返回text/xml格式视图模板为 lib/casserver/views/proxy_validate.builder。验证成功时响应核心是cas:authenticationSuccess节点其中包含cas:user认证通过的用户名cas:attributes认证器额外提供的用户属性如配置 SQL/LDAP 认证器时的extra_attributes见 config/config.example.yml 的示例cas:proxyGrantingTicket当传入pgtUrl时返回的 PGT IOU。验证失败时返回cas:authenticationFailure节点code属性携带错误码如INVALID_TICKET、INVALID_SERVICE、INVALID_REQUEST节点正文为可读的错误说明。HTTP 状态码也随之变化INVALID_*类错误返回422内部错误返回500映射逻辑见 lib/casserver/server.rb。proxyValidate支持代理链的验证接口GET /proxyValidate协议 2.6.1 节是 serviceValidate 的代理增强版路由位于 lib/casserver/server.rb。两者的核心差异只有两点接受代理票据proxyValidate 允许PT-开头的 ProxyTicket 通过验证它内部调用同一个验证函数但打开允许代理票据开关见 lib/casserver/cas.rb并会校验代理票据确实由某个 PGTProxy Granting Ticket签发响应多出 proxies 节点当票据来自代理链时响应的cas:authenticationSuccess内会包含cas:proxies列表逐项列出中间代理过的服务 URL让终端应用知道这个身份经过了哪些代理转发。什么时候用 proxyValidate当你的架构里存在代理 CASproxy CAS层——即某个中间系统替用户向更深层的服务请求访问时使用 proxyValidate普通应用直接验证用户身份则用 serviceValidate 即可。配套的GET /proxy端点用 PGT 换取代理票据与pgtUrl参数共同构成完整的代理机制票据生成逻辑见 lib/casserver/cas.rb。快速上手集成与调试要点以下 4 个坑是集成验证接口时最常踩的建议逐项自查service 必须逐字匹配验证请求中的service参数要与登录重定向时的完全一致CAS 会先对两边 URL 做清理归一化再比较逻辑见 lib/casserver/cas.rb。带不带的 query 参数、末尾斜杠差异都会导致INVALID_SERVICE。票据一次性浏览器刷新页面导致重复验证是典型故障源——第二次请求必然失败。应用应在拿到成功响应后立即建立本地会话而不是反复调用验证接口。注意 5 分钟时效用户登录到应用真正调用验证接口之间不要拖太久超时票据按过期处理。配置 IP 白名单生产环境强烈建议在 config/config.example.yml 中配置allowed_service_ips只允许自有应用服务器 IP 调用验证接口。想亲眼看看行为是否符合预期项目的 RSpec 集成测试是最好的活文档spec/casserver_spec.rb 完整覆盖了白名单内 IP 收到authenticationSuccess、白名单外 IP 收到 422 INVALID_REQUEST等场景照着它就能快速验证你的部署是否正确。核心文件速查表关注点文件接口路由与 IP 白名单lib/casserver/server.rb票据生成与五道验证关卡lib/casserver/cas.rbXML 响应视图lib/casserver/views/proxy_validate.builder一次性票据逻辑lib/casserver/model/consumable.rb票据模型定义lib/casserver/model.rb票据有效期等配置config/config.example.yml集成测试用例spec/casserver_spec.rb小结rubycas-server 的serviceValidate与proxyValidate是 CAS 单点登录中信任交接的关键端点前者面向标准场景用五道关卡参数、一次性、类型、时效、service 匹配保障票据可信后者额外打通代理链场景用proxies节点保留完整的代理轨迹。理解了应用拿 ticket 来换用户名这一本质再配合 IP 白名单与合理的票据时效配置你就可以放心地把这套 CAS 服务器接入自己的应用体系了。【免费下载链接】rubycas-serverProvides single sign-on authentication for web applications, implementing the server-end of Jasigs CAS protocol.项目地址: https://gitcode.com/gh_mirrors/ru/rubycas-server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CAS协议验证接口完整指南：serviceValidate与proxyValidate详解
CAS协议验证接口完整指南serviceValidate与proxyValidate详解【免费下载链接】rubycas-serverProvides single sign-on authentication for web applications, implementing the server-end of Jasigs CAS protocol.项目地址: https://gitcode.com/gh_mirrors/ru/rubycas-serverrubycas-server是一个基于 Ruby 的 CASCentral Authentication Service服务器端实现为 Web 应用提供单点登录认证。它的核心职责就是响应应用端发起的CAS 协议验证请求其中最常用的两个验证接口是serviceValidate和proxyValidate——应用把用户带来的ticket交给它们它们回答这个用户是谁、是否有效。验证接口在单点登录中的位置先建立整体感觉。CAS 的认证流程分为 6 步用户访问受保护页面应用将浏览器重定向到 CAS 服务器的登录页用户在 CAS 登录页输入账号密码CAS 服务器向数据源AD、LDAP、SQL 数据库等验证凭据验证通过后CAS 向浏览器签发一张Service Ticket服务票据并重定向回应用应用拿着这张 ticket 调用 serviceValidate / proxyValidate 接口向 CAS 验证票据——这就是本文主角验证成功则用户完成登录失败则回到登录页。第 5 步就是验证接口的用武之地用户与 CAS 之间的信任凭证ticket必须经服务器确认应用才能安全地放行。票据的生命周期管理过期、防重放由 lib/casserver/cas.rb 统一负责。serviceValidate最常用的 CAS 验证接口GET /serviceValidate是 CAS 协议 2.5.1 节定义的标准验证端点适用于绝大多数应用直接向 CAS 验证用户的场景。路由定义见 lib/casserver/server.rb。请求参数一览参数是否必填作用service✅发起验证的应用 URL必须与签发票据时登记的 service 一致ticket✅用户登录后拿到的服务票据形如ST-xxxxpgtUrl❌代理回调地址传入后 CAS 会生成 PGT 并在响应中返回 IOUrenew❌要求重新交互认证五道关卡CAS 如何审查一张票据无论调用哪个验证接口票据都要通过同一套审查逻辑实现于 lib/casserver/cas.rb参数完整性service或ticket缺失 →INVALID_REQUEST防重放票据只能使用一次。验证成功后立即标记 consumed见 lib/casserver/model/consumable.rb第二次提交同一票据 →INVALID_TICKETalready been used up票据类型serviceValidate拒绝代理票据ProxyTicket传入 PT 会报INVALID_TICKET有效期票据自创建起超过未使用期限默认5 分钟可在 config/config.example.yml 中通过maximum_unused_service_ticket_lifetime调整→ 过期错误Service 匹配请求的service与票据签发时绑定的应用必须完全一致否则 →INVALID_SERVICE。此外两个接口都支持allowed_service_ips白名单校验见 lib/casserver/server.rb若配置了该选项白名单外的 IP 调用验证接口会直接收到INVALID_REQUEST失败响应这是防止第三方应用冒用 CAS 套取用户信息的重要防线。响应格式成功与失败长什么样接口强制返回text/xml格式视图模板为 lib/casserver/views/proxy_validate.builder。验证成功时响应核心是cas:authenticationSuccess节点其中包含cas:user认证通过的用户名cas:attributes认证器额外提供的用户属性如配置 SQL/LDAP 认证器时的extra_attributes见 config/config.example.yml 的示例cas:proxyGrantingTicket当传入pgtUrl时返回的 PGT IOU。验证失败时返回cas:authenticationFailure节点code属性携带错误码如INVALID_TICKET、INVALID_SERVICE、INVALID_REQUEST节点正文为可读的错误说明。HTTP 状态码也随之变化INVALID_*类错误返回422内部错误返回500映射逻辑见 lib/casserver/server.rb。proxyValidate支持代理链的验证接口GET /proxyValidate协议 2.6.1 节是 serviceValidate 的代理增强版路由位于 lib/casserver/server.rb。两者的核心差异只有两点接受代理票据proxyValidate 允许PT-开头的 ProxyTicket 通过验证它内部调用同一个验证函数但打开允许代理票据开关见 lib/casserver/cas.rb并会校验代理票据确实由某个 PGTProxy Granting Ticket签发响应多出 proxies 节点当票据来自代理链时响应的cas:authenticationSuccess内会包含cas:proxies列表逐项列出中间代理过的服务 URL让终端应用知道这个身份经过了哪些代理转发。什么时候用 proxyValidate当你的架构里存在代理 CASproxy CAS层——即某个中间系统替用户向更深层的服务请求访问时使用 proxyValidate普通应用直接验证用户身份则用 serviceValidate 即可。配套的GET /proxy端点用 PGT 换取代理票据与pgtUrl参数共同构成完整的代理机制票据生成逻辑见 lib/casserver/cas.rb。快速上手集成与调试要点以下 4 个坑是集成验证接口时最常踩的建议逐项自查service 必须逐字匹配验证请求中的service参数要与登录重定向时的完全一致CAS 会先对两边 URL 做清理归一化再比较逻辑见 lib/casserver/cas.rb。带不带的 query 参数、末尾斜杠差异都会导致INVALID_SERVICE。票据一次性浏览器刷新页面导致重复验证是典型故障源——第二次请求必然失败。应用应在拿到成功响应后立即建立本地会话而不是反复调用验证接口。注意 5 分钟时效用户登录到应用真正调用验证接口之间不要拖太久超时票据按过期处理。配置 IP 白名单生产环境强烈建议在 config/config.example.yml 中配置allowed_service_ips只允许自有应用服务器 IP 调用验证接口。想亲眼看看行为是否符合预期项目的 RSpec 集成测试是最好的活文档spec/casserver_spec.rb 完整覆盖了白名单内 IP 收到authenticationSuccess、白名单外 IP 收到 422 INVALID_REQUEST等场景照着它就能快速验证你的部署是否正确。核心文件速查表关注点文件接口路由与 IP 白名单lib/casserver/server.rb票据生成与五道验证关卡lib/casserver/cas.rbXML 响应视图lib/casserver/views/proxy_validate.builder一次性票据逻辑lib/casserver/model/consumable.rb票据模型定义lib/casserver/model.rb票据有效期等配置config/config.example.yml集成测试用例spec/casserver_spec.rb小结rubycas-server 的serviceValidate与proxyValidate是 CAS 单点登录中信任交接的关键端点前者面向标准场景用五道关卡参数、一次性、类型、时效、service 匹配保障票据可信后者额外打通代理链场景用proxies节点保留完整的代理轨迹。理解了应用拿 ticket 来换用户名这一本质再配合 IP 白名单与合理的票据时效配置你就可以放心地把这套 CAS 服务器接入自己的应用体系了。【免费下载链接】rubycas-serverProvides single sign-on authentication for web applications, implementing the server-end of Jasigs CAS protocol.项目地址: https://gitcode.com/gh_mirrors/ru/rubycas-server创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考