一文搞懂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完整的示例。