后退 返回首页
中国科学技术大学统一身份认证系统简介
因个人能力有限，本文档难免疏漏错误，勘误请联系 邮件 。
身份认证，就是判断一个用户是否合法的过程。所谓统一身份认证，就是指在信息化的工作体系中，为各应用系统提供用户统一身份认证和管理的系统。我校统一身份认证采用中央认证服务(Central Authentication Service,下文简称CAS)，CAS的官方网站为 https://www.apereo.org/projects/cas 。
CAS是一套完整的统一身份认证解决方案。CAS包括对应的网络协议(CAS Protocol)、协议的实现(CAS Server)和与CAS服务交互的软件包(CAS Client) 。
考虑到学校的实际情况，以及二次开发的需求，我校 统一身份认证系统 遵循了 CAS Protocol 的相关规范，自主实现了CAS Server的逻辑。我们并未重新实现CAS Client，推荐使用官方的CAS Client接入服务。
更新日志 返回顶部
# Changelog
All notable changes to this project will be documented in this file.
The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
##
[2019-06-21]
Finish this doc first time.
CAS简介及基本业务流程 返回顶部
CAS涉及至少三方：使用Web应用程序的用户浏览器端（User），接入CAS的Web应用程序（Web Server）和CAS服务器端（CAS Server）。下文简单描述CAS协议实现的过程。
从用户角度（User）来看，当客户端访问需要身份验证的Web应用程序时，Web应用程序会将其重定向到CAS服务器端（CAS Server）。 CAS通常通过检查数据库（例如Kerberos，LDAP或Active Directory）的用户名和密码来验证客户端的真实性，参考下图：
从Web应用程序(Web Server)的角度来看，当User浏览器端拿到票据后，Web应用程序（Web Server）将携带票据去CAS Server校验并获取用户信息：
需要注意的是，此时在Step4 用户端登录成功后，CAS Server会在在用户浏览器端（User）放置Cookie：TGC(Ticket Granting Cookie)，该Cookie是用以单点登陆(Single-sign On，简称SSO) Session的键值(Session Key)。
从CAS服务器(CAS Server)的角度来看，除了响应User的登录请求外，还需要响应票据校验：
在完成上述基本流程的同时，使用Web应用程序的用户浏览器端（User），当他需要访问另外一个接入CAS的Web应用程序（Web Server）时，再次涉及到和CAS服务器端（CAS Server）进行身份认证时，将直接使用SSO Session来完成。也就是说，用户只有在与CAS服务器未建立SSO Session时需要提交有效的身份凭证（如username & password）用以建立SSO Session，在建立SSO Session之后，用户不再需要重复提交身份凭证。一般情况下，SSO Session除了会在设定的有效期结束后失效，也会随着浏览器关闭而失效
完整得时序图参考下图：
CAS协议 返回顶部
点击下载CAS协议官方文档(V5.2.x)的中文翻译版： CAS Protocol 3.0 Specification.docx 。
如需英文文档(V5.2.x)，请访问官网 CAS-Protocol-Specification.html 。
文档详细介绍了每一项协议以及该协议的参数规范，以下介绍我校实现统一身份认证的协议以及相应描述。
我校仅实现了 CAS 1.0 和 CAS 2.0 的相关协议，CAS 3.0 规范中的 /p3/serviceValidate 和 /p3/proxyValidate 并未实现。
version
protocol
method
parameters
REQUIRED
description
response[*:any][-:none]
CAS 1.0
/login
GET
service
OPTIONAL
当用户到CAS服务器请求身份认证时，CAS服务器首先会根据浏览器Cookie中TGC的有效性来判断用户登陆状态，并做出响应。其中service参数用来告知CAS服务器用户当前请求登录的服务内容，renew参数则控制是否强制用户重新授权，gateway参数则要求CAS服务器不向用户索要授权。renew和gateway是互斥的，如果同时传递则CAS服务器会认为两个参数都没有传递。推荐在传递renew或gateway参数时value设置为"true"。
TGC
service
renew
gateway
响应内容
有效
非法
*
*
service非法
有效
合法
-
-
颁发ST，重定向至service?ticket=ST
有效
合法
true
-
不颁发ST，要求用户重新登录
有效
合法
-
true
颁发ST，重定向至service?ticket=ST
有效
合法
true
true
颁发ST，重定向至service?ticket=ST
无效
非法
*
*
service非法
无效
合法
-
-
不颁发ST，要求用户重新登录
无效
合法
true
-
不颁发ST，要求用户重新登录
无效
合法
-
true
不颁发ST，重定向至service
无效
合法
true
true
不颁发ST，要求用户重新登录
renew
OPTIONAL
gateway
OPTIONAL
/login
-
service
OPTIONAL
在/login[METHOD=GET]，且响应结果包含"要求用户重新登录"的情况时，/login会展示一个账号密码登陆页面（我校目前支持两种授权方式：账号密码和微信企业号Oauth认证，此处介绍账号密码方式，微信认证见下文）。
用户需要输入username和password密码，可能需要输入lt验证码进行登录校验，CAS服务器会根据校验结果做出响应。
username
password
响应内容
不合法
不合法
提示验证失败，仍在当前页面
不合法
*
提示验证失败，仍在当前页面
*
不合法
提示验证失败，仍在当前页面
合法
合法
设置/更新Cookie TGC，颁发ST，重定向用户到service?ticket=ST
renew
OPTIONAL
gateway
OPTIONAL
POST
username
REQUIRED
password
REQUIRED
lt
OPTIONAL
/logout
GET
service
OPTIONAL
当用户请求登出时使用，用户可以选择传递url或者service参数，CAS服务器根据TGC的有效性以及url/service参数做出响应。注意url和service只是兼容不同版本的CAS而定，只需传任一即可。如果同时传递，CAS服务器将只响应url参数
TGC
service || url
响应内容
有效
-
登出成功，停留在CAS的登出页面
有效
非法
登出成功，Alert提示用户将访问url/service。
有效
合法
登出成功，将用重定向至url/service
无效
-
登出成功，停留在CAS的登出页面
无效
非法
登出成功，Alert提示用户将访问url/service。
无效
合法
登出成功，将用重定向至url/service
url
OPTIONAL
/validate
GET
service
REQUIRED
【不推荐使用】
service
ticket
renew
响应内容
非法 || -
*
*
认证失败
合法
无效 || -
*
认证失败
合法
有效
-
认证成功，并返回xml格式用户信息
合法
有效
true
账号密码登录则认证成功，SSO session认证失败，返回xml
ticket
REQUIRED
renew
OPTIONAL
CAS 2.0
/serviceValidate
GET
service
REQUIRED
serviceValidate作用与validate类似，用以验证ST的合法性，同时支持代理票据的相关业务。service和ticket参数必须传递，pgtUrl(一般为被代理的应用服务器)用以传递代理回调地址，renew参数要求ST必须时用户的主凭发出的时认证才会成功，而method参数定义了返回数据的格式。CAS服务器根据相应参数做出响应。
service
ticket
pgtUrl
响应内容
非法 || -
*
*
认证失败，返回xml(format=json则json)格式错误信息
*
无效 || -
*
认证失败，返回xml(format=json则json)格式错误信息
合法
有效
-
认证成功，返回xml(format=json则json)格式用户信息
合法
有效
无效
认证失败，返回xml(format=json则json)格式提示ST成功但pgtUrl异常
合法
有效
有效
认证成功，返回xml(format=json则json)格式用户信息和pgtIou信息
ticket
REQUIRED
pgtUrl
OPTIONAL
renew
OPTIONAL
format
OPTIONAL
/proxyValidate
GET
service
REQUIRED
proxyValidate作用与serviceValidate作用与validate类似类似，用以验证ST的合法性，同时支持验证代理票据PT。service和ticket参数必须传递，pgtUrl(一般为被代理的应用服务器)用以传递代理回调地址，renew参数要求ST必须时用户的主凭发出的时认证才会成功，而method参数定义了返回数据的格式。CAS服务器根据相应参数做出响应。
service
ticket
pgtUrl
响应内容
非法 || -
*
*
认证失败，返回xml(format=json则json)格式错误信息
*
无效 || -
*
认证失败，返回xml(format=json则json)格式错误信息
合法
有效
-
认证成功，返回xml(format=json则json)格式用户信息
合法
有效
无效
认证失败，返回xml(format=json则json)格式提示ST/PT成功但pgtUrl异常
合法
有效
有效
认证成功，返回xml(format=json则json)格式用户信息和pgtIou信息
ticket
REQUIRED
pgtUrl
OPTIONAL
renew
OPTIONAL
format
OPTIONAL
/proxy
GET
pgt
OPTIONAL
当service服务在浏览器发出/serviceValidate或/proxyValidate请求携带pgtUrl时，CAS服务器会向回调地址pgtUrl(一般为被代理的应用服务器)发送PGT和pgtIou，成功后会将pgtIou发送给浏览器，通过浏览器，被代理应用的服务器获得了pgtIou，检索回调地址接收的数据可以获得PGT，应用服务器将使用PGT通过/proxy协议校验PGT的有效性并请求用户数据。CAS服务器会根据传递的targetService和PGT响应请求。
targetService
pgt
响应内容
非法 || -
*
认证失败，xml响应
合法
无效
认证失败，xml响应
合法
有效
认证成功，xml响应
targetService
OPTIONAL
针对/logout协议，我校统一身份认证在实现时调整如下：/logout时，先完成logout行为，然后检查有没有url或service参数：如果没有，使用logout页面提示用户登出成功；如果有，检查url或service的合法性， 合法则直接重定向至url或service，不合法则使用alert提示跳转 。
需要注意的是，我校统一身份认证系统实现了校内业务系统的SSO(Single Sign On)单点登录业务，但是并不支持Single Sign Out 单点登出。用户注销时，还是需要在特定的服务内逐一注销，或是关闭浏览器注销登录状态。
名词解释：
TGC和TGT，分别指Ticket-granting Cookie和Ticket-granting Ticket。TGC和TGT是用来维持SSO登录状态的Session Key和Session Value，用户登录成功后，CAS服务器在浏览器设置CookieTGC，在服务器留存TGC和TGT。当用户登录其他service时，CAS会检索浏览器Cookie的TGC，发送给CAS服务器，以判断用户的SSO登陆状态。TGT过期会销毁。
ST和PGT，分别指Service Ticket和Proxy-granting Ticket。当CAS服务器完成TGC的校验后，并不会直接把用户数据返回浏览器，而是向用户颁布授权票据，根据授权类型分为ST和PGT。浏览器拿到票据后会将票据交由应用服务器，由应用服务器持有票据访问CAS服务器获得用户身份信息。
PGTURL指Proxy-granting Ticket URL，是CAS业务中代理服务的回调地址，一般为被代理的应用服务器提供，当使用代理服务时，CAS服务器会把PGT和PGT的key值PGTIOU发送到PGTURL，同时把PGTIOU响应给浏览器，浏览器会将携带PGTIOU访问被代理的服务器，由被代理的应用服务器匹配PGT后向CAS服务器请求用户信息，并根据响应的用户信息给浏览器返回数据。
更多详细描述请参考官方文档。
校内Web应用程序对接统一身份认证系统流程 返回顶部
CAS Client下载 返回顶部
CAS官方提供了常见的Web应用程序用到的CAS Client，使用这些Clients，可以降低接入难度，提升接入效率。完整的CAS Clients可以 查看官网 。
我们建议在接入时选择最新的稳定版本CAS Client版本，以降低系统的安全风险。
更多非官方的CAS Client可以查看这里 ，但是他们可能已经过期或是不再维护了。
接入指南 返回顶部
下文将以php和Java为例，通过详细的配置来描述我校的统一身份认证登录接入过程。
TBC
在企业号内通过CAS获取用户信息 返回顶部
有关中国科学技术大学信息服务微信企业号(以下简称企业号)的介绍，可以 查看这里 。从用户角度来说，用户在关注微信企业号之后需要完成一次身份认证的过程（使用校内邮箱绑定将个人微信信息与校园身份绑定），完成认证之后，用户可以在企业号内查询个人在校内业务系统的数据。从应用/服务角度来说，可以通过企业号获取用户身份信息为用户提供服务。目前已经接入微信企业号的应用和服务包括财务系统、校园百科、个人信息、图书馆、公共信息和服务大厅等。
我校CAS系统与企业号用户身份信息是相通的。对于应用和服务来说，如果业务系统对接了CAS系统，并且业务本身对移动设备做了适配，可以直接通过CAS系统将业务部署在微信企业服务，为校内师生提供更加集中和便捷的服务。我们通过微信Oauth认证于CAS协同工作获取用户身份，以下通过时序图和一个Demo来演示这个过程。
时序图：
值得注意的是，对于接入的应用和服务，仅需要构造Oauth URL即可在微信内获取用户身份信息。
Oauth
parameters
description
https://open.weixin.qq.com/connect/oauth2/authorize
appid
接入时联系管理员索取
redirect_url
CAS链接，https://passport.ustc.edu.cn/login，需要urlencode
response_type
配置为'code'
scope
配置为'SCOPE'
agentid
接入时联系管理员索取
state
配置为'fromWeiXin-' + 服务/应用URL
其他
在所有参数后完成后url添加#wechat_redirect
演示：
TBC
完
