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完整的示例。