您的位置:首页 > 其它

一文搞懂CAS

2021-09-01 19:02 260 查看

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

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: