CAS-认证流程详解
基础知识
名词解释
AS
Authentication Service
:认证服务,发放TGT
KDC
Key Distribution Center
:**发放中心
TGS
Ticket-Granting Service
:票据授权服务,索取TGT
,发放ST
TGC
ticket-granting cookie
:授权的票据证明,由CAS Server
通过SSL
方式发送给终端用户。该值存在Cookie中,根据TGC
可以找到TGT
。
TGT
Ticket Granting tieckt
:俗称大令牌,或者票根,由KDC
和AS
发放,获取该票据后,可直接申请其他服务票据ST
,不需要提供身份认证信息
ST
Service Ticket
:服务票据,由KDC
的TGS
发放,ST
是访问server
内部的令牌
CAS
认证流程
CAS (Central Authentication Service)
*身份验证服务认证流程如下:
- 访问服务:由于
CAS client
和WEB
应用部署在一起,当用户访问WEB
应用时,CAS client
就会处理请求 - 定向认证:
CAS client
客户端校验HTTP
请求中是否包含ST
和TGT
,如果没有则会重定向到CAS server
地址进行用户认证 - 用户认证:用户通过浏览器填写用户信息,提交给
CAS Server
认证 - 发放票据:
CAS Server
校验过用户信息后,为CAS client
发放ST
,并在浏览器cookie
中设置TGC
,下次访问CAS Server
时会根据TGC
和TGT
验证,判断是否已经登录 - 验证票据:
CAS Client
拿到ST
后,再次请求CAS Server
验证ST
合法性,验证通过后允许客户端访问 - 传输用户信息:
CAS Server
校验过ST
后,传输用户信息给CAS client
代码示例
phpCAS
库: https://github.com/apereo/phpCAS
使用phpCAS
实现对于访问www.baidu.com
的访问控制
<?php
require_once './vendor/apereo/phpcas/CAS.php';
$home = 'http://www.baidu.com/';
$login_url = 'http://10.91.156.174:8080/cas/login?service='.urlencode($home);
$logout_url = 'http://10.91.156.174:8080/cas/logout';
$service_validate_url = 'http://10.91.156.174:8080/cas/serviceValidate';
phpCAS::setDebug();
//设置client属性
phpCAS::client(CAS_VERSION_2_0, "10.91.156.174", 8080, "/cas");
// 设置 Login url
phpCAS::setServerLoginURL($login_url);
// 设置 logout url
phpCAS::setServerLogoutURL($logout_url);
// 设置 validate url
phpCAS::setServerServiceValidateURL($service_validate_url);
// cas server 设置不校验 ssl 证书
phpCAS::setNoCasServerValidation();
// 这个方法确保用户是否验证过,如果没有验证则跳转到验证界面。
phpCAS::forceAuthentication();
通过php -S localhost:8080
启动服务
首次登陆流程
受访问控制的资源地址为:http://www.baidu.com/
1.访问服务
通过访问localhost:8080
访问本地WEB
服务,发现没有用户登录信息,便会生成login url
,并重定向到该地址。其中login_url
中service
参数代表受访问控制的资源
2.定向认证
浏览器收到重定向响应后,请求login_url
,等待用户输入用户名密码
3.用户认证
用户输入用户名密码提交表单后,CAS server
对提交信息进行校验。通过校验后,会将浏览器重定向到service
参数后的url
,并且后面携带了一个ticket
令牌,该参数就是ST
。同时在Cookie
中设置CASTGC
,该Cookie
是访问service_url
的cookie
,只有访问该地址才会携带这个cookie
。
向Cookie
中添加CASTGC
的目的是为了下次访问service_url
时,浏览器请求时携带TGC
参数,服务器根据该TGC
查找对应的TGT
,从而判断用户是否登录过了,是否需要展示登录页面。TGT
与TGC
的关系就像SESSION
与Cookie
中SESSIONID
的关系。
4.发放票据
CAS server
会生成ST
服务票据,然后将浏览器重定向到$service_url?ticket=$service-ticket
5.验证票据
CAS
客户端取出ticket,生成$service_validate_url
,然后向$service_validate_url
发送请求从而验证ST
。验证ticket
的URL
形如:
http://${cas_server_host}:${cas_server_port}/cas/serviceValidate?ticket=${service-ticket}&service=http://www.baidu.com
当CAS server
校验通过后,会再次重定向回service_url
,展示相关资源到浏览器中
第二次登陆流程
1.访问服务
访问本地WEB
服务,跳转到login_url
2.签发票据
2.由于之前访问过一次,所以此次login_url
中带了之前获取出的CASTGC
,认证中心在收到请求后,发现TGC
对应一个TGT
,于是用TGT
签发一个ST
,并且返回给浏览器
3.验证票据
浏览器向cas server
发出的地址进行重定向,并校验ST
,校验成功后就可访问受控制的资源了
总结
简单点来说整体的流程就是,客户端请求服务端的login_url
,如果携带了TGC
,服务端返回ST
,客户端再次校验ST
即可;若未携带TGC
,则跳转到login_url
输入用户信息,校验成功后,服务端将TGC
设置到Cookie
中返回,并颁发ST
,客户端再次校验ST
即可。
上一篇: DataBase System Concept相关语句 (笔记)
下一篇: C语言入门的学生管理系统