一文搞懂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 service query parameter here is the URL of the application. This URL value MUST be URL-encoded. In this example, service is http://Fwww.example.org/service Once CAS server authenticated user, it will redirect to this URL with a serviceTicket query parameter.
/logout destroys a client’s single sign-on CAS session. The ticket-granting cookie is destroyed, and subsequent requests to /login will 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. /validate is 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. /serviceValidate MUST also generate and issue proxy-granting tickets when requested. /serviceValidate MUST NOT return a successful authentication if it receives a proxy ticket. It is RECOMMENDED that if /serviceValidate receives 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 /serviceValidate and additionally validate proxy tickets. /proxyValidate MUST 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 /serviceValidate and additionally return user attributes in the CAS response.
/p3/proxyValidate [CAS 3.0] MUST perform the same validation tasks as /p3/serviceValidate and 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 service query 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 ticket in 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 /serviceValidate API.
The request is a GET request with service and ticket query 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 /serviceValidate to 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 /serviceValidate ticket 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 /serviceValidate ticket 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 next query 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完整的示例。
