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)中央身份验证服务认证流程如下：

image-20200608144426800

  1. 访问服务：由于CAS client和WEB应用部署在一起，当用户访问WEB应用时，CAS client就会处理请求
  2. 定向认证：CAS client客户端校验HTTP请求中是否包含ST和TGT，如果没有则会重定向到CAS server地址进行用户认证
  3. 用户认证：用户通过浏览器填写用户信息，提交给CAS Server认证
  4. 发放票据：CAS Server校验过用户信息后，为CAS client发放ST，并在浏览器cookie中设置TGC，下次访问CAS Server时会根据TGC和TGT验证，判断是否已经登录
  5. 验证票据：CAS Client拿到ST后，再次请求CAS Server验证ST合法性，验证通过后允许客户端访问
  6. 传输用户信息：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参数代表受访问控制的资源

image-20200608214233860


2.定向认证

浏览器收到重定向响应后，请求login_url，等待用户输入用户名密码

image-20200608214248361


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的关系。

image-20200608214703432


4.发放票据

CAS server会生成ST服务票据，然后将浏览器重定向到$service_url?ticket=$service-ticket

image-20200608161934466


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，展示相关资源到浏览器中

image-20200608214834183

第二次登陆流程

1.访问服务

访问本地WEB服务，跳转到login_url

image-20200608215145472


2.签发票据

2.由于之前访问过一次，所以此次login_url中带了之前获取出的CASTGC，认证中心在收到请求后，发现TGC对应一个TGT，于是用TGT签发一个ST，并且返回给浏览器

image-20200609095147550


3.验证票据

浏览器向cas server发出的地址进行重定向，并校验ST，校验成功后就可访问受控制的资源了

image-20200608215220660

总结

简单点来说整体的流程就是，客户端请求服务端的login_url，如果携带了TGC，服务端返回ST，客户端再次校验ST即可；若未携带TGC，则跳转到login_url输入用户信息，校验成功后，服务端将TGC设置到Cookie中返回，并颁发ST，客户端再次校验ST即可。