CAS协议介绍
中创软件商用中间件有限公司

前言
本文是CAS协议规范的中文译文。

1.Introduction
以下是CAS1.0和2.0协议的官方规范。
注：CAS1.0和2.0协议大体包含两个方面的内容：各种票根（Ticket）和暴露给CAS客户的HT
TP（S）URL。这些UPL（/login、/logout、/validate、/serviceValidate、/proxy、/proxyValidate等）围绕着这些票根（ST、TGC、PGT、PT等）进行活动。在此期间服务和终端服务之间会进行多次HTTPS交互。
Conventions & Definitions（公约和定义）
●“Client” 指的是终端用户或者是WEB浏览器。
●“Server”指的是统一认证服务所在的服务器。
●“Service” 指的是终端用户或者WEB浏览器试图访问的应用.
●“Back-end service”是指一个服务试图代表一个client去访问一个应用，这个应用就被称为终端服务（Back-end service） 。它也被称作“target service”目标服务。
注：这里的service可以包含两部分，一是应用程序本身提供的service；二是应用程序本身还可提供代理服务，使Client能够通过它的代理功能访问终端服务。
按照翻译，不容易理解“终端服务”，通过下面的图可以很容易看清楚它的作用。
黄区域指Client；绿区域指Server；紫区域指Service；蓝区域指终端服务。其中CAS1.0中没有终端服务这一块，也没有Service的proxy，也即不能进行代理认证。
2.CAS URIs
CAS是一个基于HTTP的协议，这就要求其每一个组成部分可以通过特定的URIs访问到。本节将讨论每个的URIs。
2.1. /login as credential requestor
/login URI通过两种行为运转：一是作为一个凭证索取者，二是作为凭证接收者。根据它对凭证的反应来区分他是作为凭证索取者还是凭证接收者。
如果客户端已经与CAS建立了一个单点登录的session，Web浏览器给CAS一个安全的cookie，里面包含有一个以字符串形式存在的身份信息—TGT（Ticket-Granting Ticket），存储这个身份信息TGT的cookie就被称为票证授予的cookie（TGC- Ticket-G里面包含具体那些协议?ranting Cookie）。如果TGC里面有一个有效的TGT，CAS可以发出一个服务门票（Service Ticket，ST），这个ST可以在本规范内的其他任何情况下使用。本规范的要求。见第3.6节提供更多的资料，TGC。
2.1.1. parameters
下面的HTTP请求的参数可通过/login，这时它作为凭证索取者。他们都是区分大小写的，他们都必须处理/login。
∙service[可选] -客户端尝试访问的应用的标识符。在几乎所有情况下，这将是应用的URL。请注意，作为一个HTTP请求的参数，此URL的值必须是符合RFC 中URL编码的描述。（详情参见RFC 1738 [ 4 ]的第2.2节）。如果没有指定service并且单点登录session尚不存在，CAS应要求具有凭证的用户发起一个单点登录session。如果没有指定service但单点登录session已经存在，CAS应显示一条消息，通知客户，这是已经登录
∙Renew[可选] -如果此参数设置，单点登录将被绕过。在这种情况下，CAS将要求客户提交证书，不论是否存在一个CAS的单点登录session。这个参数与“gateway”参数不兼容。服务重定向到/login的URI和登录表单视图，张贴在/login的URI中的值不应同时出现在“renew”和“gateway”请求参数。两个参数都设置这种行为是未定义的。CAS推荐：在实施时，如果设置“renew”参数则忽略“gateway”参数。推荐：当设置“renew”参数时，其值应该为“true”。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。