一文搞懂CAS
CAS是一个单点的登入登出web协议,它允许用户一次登陆,到处访问;CAS协议一种基于ticket的协议(simple and powerful)
CAS概念
- CAS server:负责验证用户和授权访问权限。
- CAS client:通常和web应用集成在一起,通过CAS协议和CAS server交互,负责检索在CAS server已授权用户的标识;
- service ticket:加密字符串,作为凭证被用来从客户端获取服务访问权限。
CAS URIs
CAS 是基于http的协议,所以要求它的每一个组件都可以被url访问到,具体如下.
URI | Description |
---|---|
/login |
credential requestor / acceptor |
/logout |
destroy CAS session (logout) |
/validate |
service ticket validation [CAS 1.0] |
/serviceValidate |
service ticket validation [CAS 2.0] |
/proxyValidate |
service/proxy ticket validation [CAS 2.0] |
/proxy |
proxy ticket service [CAS 2.0] |
/p3/serviceValidate |
service ticket validation [CAS 3.0] |
/p3/proxyValidate |
service/proxy ticket validation [CAS 3.0] |
/login Simple login example:
https://cas.example.org/cas/login?service=http%3A%2F%2Fwww.example.org%2Fservice
The
servicequery parameter here is the URL of the application. This URL value MUST be URL-encoded. In this example,
serviceis
http://Fwww.example.org/serviceOnce CAS server authenticated user, it will redirect to this URL with a
serviceTicketquery parameter.
/logout destroys a client’s single sign-on CAS session. The ticket-granting cookie is destroyed, and subsequent requests to
/loginwill not obtain service tickets until the user again presents primary credentials (and thereby establishes a new single sign-on session).
/validate [CAS 1.0] checks the validity of a service ticket.
/validateis part of the CAS 1.0 protocol and thus does not handle proxy authentication. CAS MUST respond with a ticket validation failure response when a proxy ticket is passed to
/validate.
/serviceValidate [CAS 2.0] checks the validity of a service ticket and returns an XML-fragment response.
/serviceValidateMUST also generate and issue proxy-granting tickets when requested.
/serviceValidateMUST NOT return a successful authentication if it receives a proxy ticket. It is RECOMMENDED that if
/serviceValidatereceives a proxy ticket, the error message in the XML response SHOULD explain that validation failed because a proxy ticket was passed to
/serviceValidate.
/proxyValidate [CAS 2.0] MUST perform the same validation tasks as
/serviceValidateand additionally validate proxy tickets.
/proxyValidateMUST be capable of validating both service tickets and proxy tickets.
/proxy [CAS 2.0] provides proxy tickets to services that have acquired proxy-granting tickets and will be proxying authentication to back-end services.
/p3/serviceValidate [CAS 3.0] MUST perform the same validation tasks as
/serviceValidateand additionally return user attributes in the CAS response.
/p3/proxyValidate [CAS 3.0] MUST perform the same validation tasks as
/p3/serviceValidateand additionally validate proxy tickets.
在最新的CAS3.0中又添加了多个链接,感兴趣的大家可以上CAS官网查看。CAS官网
CAS登陆流程
(注意:图中的第6步中from应该改为form)
Step 1: 用户初始化请求
Step 2: 浏览器返送登陆请求到CAS client
Step 3-4: CAS client 重定向登陆请求到 CAS server
Below are examples response in step 3 and request in step 4:
302 Found Location: https://cas-server/cas/login?service=https%3A%2F%2Fcas-app%2Faccounts%2Flogin%3Fnext%3D%252F GET https://cas-server/cas/login?service=https%3A%2F%2Fcas-app%2Faccounts%2Flogin%3Fnext%3D%252F
Step 5-6: CAS server对用户显示登陆表单
Step 7-8: 用户提交表单
User send login credentials like username, password to CAS server directly. The request include
servicequery parameter to indicate CAS server which service is doing authentication.
POST https://cas-server/cas/login?service=https%3A%2F%2Fcas-app%2Faccounts%2Flogin%3Fnext%3D%252F
Step 9: CAS server 带着ticket重定向到 CAS client
service ticket in query parameter
ticket. CAS Client need validate
ticketin following step.
Below is an example response
302 Found Location: https://cas-app/accounts/login?next=%2F&ticket=ST-1579821158
Step 10: 通过 /serviceValidate 验证 service ticket
CAS Client need validate service ticket (ST) through CAS server
/serviceValidateAPI.
The request is a GET request with
serviceand
ticketquery parameter.
Below is an example request:
GET https://cas-server/cas/serviceValidate?service=https%3A%2F%2Fcas-app%2Faccounts%2Flogin%3Fnext%3D%252F&ticket=ST-1579821158
Step 11: Response to /serviceValidate
CAS response
/serviceValidateto CAS client, the response is in XML format. If validate success, it will include user attributes (like username) in response.
Below is an example of
/serviceValidateticket validation successful XML response:
<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas"> <cas:authenticationSuccess> <cas:user>foo</cas:user> <cas:proxyGrantingTicket>PGTIOU-234749-5d3e...</cas:proxyGrantingTicket> </cas:authenticationSuccess> </cas:serviceResponse>
Below is an example of
/serviceValidateticket validation failure XML response:
<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas"> <cas:authenticationFailure code="INVALID_TICKET"> Ticket PGTIOU-234749-5d3e12d2df87dc not recognized </cas:authenticationFailure> </cas:serviceResponse>
Step 12: CAS client redirect after validate ticket successfully
CAS client redirect according
nextquery parameter in
service.
CAS client also set cookie in browser to store session info.
Step 13: Browser follow redirect request
Browser also add cookie in request header to indicate user is logged in.
Step 14-15: CAS client response content to user
In step 14, CAS client need validate session cookie.
以上就是CAS flow完整的示例。
- 一文彻底搞懂CAS实现原理 & 深入到CPU指令
- 一文彻底搞懂CAS实现原理
- 一文搞懂:词法作用域、动态作用域、回调函数、闭包
- 一文彻底搞懂重载函数匹配
- 一文搞懂深度学习中的梯度下降
- 一文搞懂ES6中的Map和Set
- 【语音识别】一文搞懂hmm
- 一文搞懂HMM(隐马尔可夫模型)
- 一文搞懂算法的时间复杂度与空间复杂度
- 这一文让你搞懂Java 数据结构中的几种接口和类的使用方法
- 数据结构与算法之布隆过滤器(一文搞懂布隆过滤器)
- 一文搞懂 Elasticsearch 之 Mapping
- 一文彻底搞懂 Design 设计的 CoordinatorLayout 和 AppbarLayout 联动,让 Design 设计更简单~
- 谈谈对物理内存和虚拟内存的理解以及内存分配原理,一文彻底搞懂
- 数据结构里各种难啃的“树”,一文搞懂它
- 一文搞懂华为HMS ML Kit文本识别,银行卡识别,通用卡证识别,身份证识别
- 一文搞懂route在windows和linux上的使用方法
- 一文搞懂华为ML Kit拍照购,超简单集成
- 一文彻底搞懂BP算法:原理推导+数据演示+项目实战(上篇)
- 一文搞懂:词法作用域、动态作用域、回调函数、闭包