开源认证组件Kerberos和CAS简介

水深无声 2023-02-16 06:54 28阅读 0赞

参考文章：[CAS登录认证][CAS]

[Kerberos身份验证流程][Kerberos]

# 一、Kerberos #

## 1. Kerberos介绍： ##

> 概述：Kerberos的工作围绕着票据展开，票据类似于人的驾驶证，驾驶证标识了人的信息，以及其可以驾驶的车辆等级。
> 
> Kerberos 是一种由 MIT（麻省理工大学）提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。
> 
> 在 Kerberos 认证中，最主要的问题是如何证明「你是你」的问题，如当一个 Client 去访问 Server 服务器上的某服务时，Server 如何判断 Client 是否有权限来访问自己主机上的服务，同时保证在这个过程中的通讯内容即使被拦截或篡改也不影响通讯的安全性，这正是 Kerberos 解决的问题。在域渗透过程中 Kerberos 协议的攻防也是很重要的存在。
> 
> Kerberos 主要是用在**域环境下的身份认证协议**。

### 2 Kerberos 协议框架： ###

在 Kerberos 协议中主要是有三个角色的存在：

> 1.  **访问服务的 Client；**
> 2.  **提供服务的 Server；**
> 3.  **KDC（Key Distribution Center）密钥分发中心**

**注意：**

> 1.  KDC 服务默认会安装在一个域的域控中
> 2.  从物理层面看，AD(account database)与KDC均为域控制器(Domain Controller)
> 3.  AD其实是一个类似于本机SAM的一个数据库，全称叫account database，存储所有client的白名单，只有存在于白名单的client才能顺利申请到TGT
> 4.  KDC 服务框架中包含一个 KRBTGT 账户，它是在创建域时系统自动创建的一个账号，你可以暂时理解为他就是一个无法登陆的账号，在发放票据时会使用到它的密码 HASH 值。

![8e44475ac45e4c1f38480e4611c8118a.png][]

### 3.Kerberos粗略的验证流程：  ###

先来举个例子：如果把 Kerberos 中的票据类比为一张火车票，那么 Client 端就是乘客，Server 端就是火车，而 KDC 就是就是车站的认证系统。如果Client端的票据是合法的（由你本人身份证购买并由你本人持有）同时有访问 Server 端服务的权限（车票对应车次正确）那么你才能上车。当然和火车票不一样的是 Kerberos 中有存在两张票，而火车票从头到尾只有一张。

**在KDC中又分为两个部分：Authentication Service**和**Ticket Granting Service**

**Authentication Service：**AS 的作用就是验证 Client 端的身份（确定你是身份证上的本人），验证通过就会给一张 **TGT**（Ticket Granting Ticket）票给 Client。

**Ticket Granting Service：**TGS 的作用是通过 AS 发送给 Client 的票（TGT）换取访问 Server 端的票（上车的票 ST）。ST（ServiceTicket）也被称之为 **TGS Ticket**，为了和 TGS 区分，在这里就用 ST 来说明，所以TGS Ticket和ST的意思是一样的。

这就说明了为什么在Kerberos中存有两种票，其实就是更加细分了其中的验证，简单的描述就是首先你拿身份证验证头像是不是一样，是的话就返回一张TGT，然后在通过验证车票获得上车的资格，这里就有对TGT的验证，通过的话再返回一张ST/TGS Ticket的票，如果都可以那么就验证成功了。

--------------------

###  4.Kerberos 详解认证流程： ###

当 Client 想要访问 Server 上的某个服务时，需要先向 AS 证明自己的身份，然后通过 AS 发放的 TGT 向 Server 发起认证请求，这个过程分为三块：

> 1.  The Authentication Service Exchange：Client 与 AS 的交互，
> 2.  The Ticket-Granting Service (TGS) Exchange：Client 与 TGS 的交互，
> 3.  The Client/Server Authentication Exchange：Client 与 Server 的交互。

![e872496254fafab9e9786db6577053b9.png][]

**(1)TheAuthentication Service Exchange**

**KRB\_AS\_REQ(请求)：**

> Client->AS：Client 先向 KDC 的 AS 发送 Authenticator1(内容为Client hash加密的时间戳）

**KRB\_AS\_REP(应答)：**

> AS-> Client：  
> AS根据用户名在AD中寻找是否在白名单中，然后根据用户名提取到对应的NTLM Hash，  
> 然后会生成一个由 Client 密码 HASH 加密的 SessionKey-as，  
> 和TGT（由 KRBTGT HASH 加密的 SessionKey-as 和 TimeStamp 等信息），  
> AS将这两个数据返还给Client

> **AS验证的简述：**在 KDC(AD) 中存储了域中所有用户的密码 HASH，当 AS 接收到 Client 的请求之后会根据 KDC 中存储的密码来解密，解密成功并且验证信息。  
> 验证成功后返回给 Client两个东西，一个是由 Client 密码 HASH 加密的 session key-as 和 TGT（由 KRBTGT HASH 加密的 session key 和 TimeStamp 等信息）。

![db9d207cf590a29390931df0e2830518.png][]

**(2)TheTicket-Granting Service (TGS) Exchange**

**KRB\_TGS\_REQ(请求)：**

> Client 接收到了加密后的session key-as 和 TGT 之后，先用**自身密码 HASH解密**得到session key ，**TGT 是由 KDC 中KRBTGT的HASH加密**，所以Client 无法解密。这时 Client 再用session key加密的TimeStamp，然后再和TGT 一起发送给 KDC 中的 TGS（TicketGranting Server）票据授权服务器换取能够访问 Server 的票据。

**KRB\_TGS\_REP(应答)：**

> TGS 收到 Client 发送过来的 TGT 和 Session key 加密的 TimeStamp 之后，首先会检查自身是否存在 Client 所请求的服务。如果服务存在，则用 **KRBTGT的HASH解密 TGT**。
> 
> **一般情况下 TGS 会检查 TGT 中的时间戳查看 TGT 是否过期，且原始地址是否和 TGT 中保存的地址相同**。

验证成功之后将返回Client两个东西，一个是用 **session key 加密的 session key-tgs**，然后另一个是 **Client要访问的Server的密码 HASH 加密的 session key-tgs（前面和session key加密生成的）**生成就是ST（TGS）

![fb323cd63088c7802d9aa261263234b8.png][]

**(3)TheClient/Server Authentication Exchange**

**KRB\_AP\_REQ(请求)：**

> Client -> Server 发送 Authenticator3(session key-tgs 加密 TimeStamp) 和票据 ST(Server 密码 HASH 加密 session key-tgs)
> 
> Client 收到 session key 加密生成的 session key-tgs 和 Server 密码 HASH 加密 session key-tgs生成的TGS 之后，用 session key 解密得到 session key-tgs，然后把 sessionkey-tgs 加密的 TimeStamp 和 ST（也就是TGS）一起发送给 Server。

**KRB\_AP\_REP(应答)：**

> Server-> Client
> 
> server 通过自己的密码解密 ST，得到 sessionkey-tgs, 再用 sessionkey-tgs 解密 Authenticator3 得到 TimeStamp，验证正确返回验证成功。

![e07f9547e7ac536d5d6c163abe3a97ff.png][]

## 5. Kerberos原理和工作机制 ##

### 5.1 客户机初始验证 ###

![format_png][]

### 5.2获取对服务的访问 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RscGY_size_16_color_FFFFFF_t_70][]

## 6.kerberos中的几个概念 ##

>  *  KDC：密钥分发中心，负责管理发放票据，记录授权。
>  *  域：kerberos管理领域的标识。
>  *  principal：当每添加一个用户或服务的时候都需要向kdc添加一条principal，principl的形式为 主名称／实例名@领域名。
>  *  主名称：主名称可以是用户名或服务名，还可以是单词host，表示是用于提供各种网络服务（如ftp，rcp，rlogin）的主体。
>  *  实例名：实例名简单理解为主机名。
>  *  领域：Kerberos的域。

# 二、CAS 统一认证中心 #

> CAS是Central Authentication Service的缩写，中央认证服务，一种独立开放指令协议。CAS 是 [Yale][] 大学发起的一个开源项目，旨在为 Web 应用系统提供一种可靠的单点登录方法，CAS 在 2004 年 12 月正式成为 JA-SIG 的一个项目。

## 特点 ##

> 1、开源的企业级单点登录解决方案。
> 
> 2、CAS Server 为需要独立部署的 Web 应用。
> 
> 3、CAS Client 支持非常多的客户端(这里指单点登录系统中的各个 Web 应用)，包括 Java, .Net, PHP, Perl, Apache, uPortal, Ruby 等。
> 
> 4、CAS属于Apache 2.0许可证，允许代码修改，再发布（作为开源或商业软件）。

## 原理和协议 ##

从结构上看，CAS 包含两个部分： CAS Server 和 CAS Client。

> 1.  CAS Server 需要独立部署，主要负责对用户的认证工作；
> 2.  CAS Client 负责处理对客户端受保护资源的访问请求，需要登录时，重定向到 CAS Server。

**图1 是 CAS 最基本的协议过程：**

![format_png 1][]

## 名词解释： ##

>  *  **Ticket Grangting Ticket(TGT)** ：  
>     TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。TGT封装了Cookie值以及此Cookie值对应的用户信息。用户在CAS认证成功后，CAS生成cookie（叫TGC），写入浏览器，同时生成一个TGT对象，放入自己的缓存，TGT对象的ID就是cookie的值。当HTTP再次请求到来时，如果传过来的有CAS生成的cookie，则CAS以此cookie值为key查询缓存中有无TGT，如果有的话，则说明用户之前登录过，如果没有，则用户需要重新登录。
>  *  **Ticket-granting cookie(TGC)**：  
>     存放用户身份认证凭证的cookie，在浏览器和CAS Server间通讯时使用，并且只能基于安全通道传输（Https），是CASServer用来明确用户身份的凭证。
>  *  **Service ticket(ST)** ：服务票据，服务的惟一标识码 , 由 CASServer 发出（ Http 传送），用户访问Service时，service发现用户没有ST，则要求用户去CAS获取ST.用户向CAS发出获取ST的请求，CAS发现用户有TGT，则签发一个ST，返回给用户。用户拿着ST去访问service，service拿ST去CAS验证，验证通过后，允许用户访问资源

## 组成： ##

>  *  CAS 服务端  
>     CASServer 负责完成对用户的认证工作 , 需要独立部署 , CAS Server 会处理用户名 /密码等凭证 (Credentials) 。
>  *  CAS 客户端  
>     负责处理对客户端受保护资源的访问请求，需要对请求方进行身份认证时，重定向到 CAS Server 进行认证。（原则上，客户端应用不再接受任何的用户名密码等 Credentials ）。  
>     CASClient 与受保护的客户端应用部署在一起，以 Filter 方式保护受保护的资源。

## CAS Web工作流程： ##

![format_png 2][]

## CAS登录认证： ##

**步骤 1**：浏览器向CAS客户端发起登陆请求，CAS客户端生成“登陆URL”,并把浏览器重定向到该URL 登陆URL:[https://$\{cas-server-host\}:$\{cas-server-port\}/cas-server/login?service=$\{client-service-url\}][https_cas-server-host_cas-server-port_cas-server_login_service_client-service-url]

*  其中
    
     *  cas-server-host: cas认证服务器域名
     *  cas-server-port: cas认证服务器端口号
     *  client-service-url: 用于登陆成功后，浏览器重定向的URL

> java举例:  
> [https://cas-server.domain.com/cas/login?service=http%3A%2F%2Fcas.domain.com%3A8080][https_cas-server.domain.com_cas_login_service_http_3A_2F_2Fcas.domain.com_3A8080]

**步骤 2**: 浏览器向“登陆URL”发起重定向请求，CAS服务端创建会话，把TGT（Ticket Granting Ticket）放入cookie，并返回登陆页面

**步骤 3**：用户输入用户名和密码,然后提交登陆表单. CAS服务端通过登陆验证后，会生成一个ST(service ticket,简称ticket), 然后把浏览器重定向到$\{client-service-url\}?ticket=$\{service-ticket\}

**步骤 4**：浏览器重定向到$\{client-service-url\}?ticket=$\{service-ticket\}发起重定向请求

> java举例:  
> [http://cas.domain.com/8080?ticket=$][http_cas.domain.com_8080_ticket]\{service-ticket\}

**步骤 5**: CAS客户端取出ticket，生成“ticket验证URL”,然后向"ticket验证URL"发起http GET请求 "ticket验证URL":　[http://$\{cas-server-host\}:$\{cas-server-port\}/cas-server/serviceValidate?ticket=$\{service-ticket\}&service=$\{client-service-url\}][http_cas-server-host_cas-server-port_cas-server_serviceValidate_ticket_service-ticket_service_client-service-url]

> java举例:  
> [https://cas-server.domain.com/cas/serviceValidate?ticket=$][https_cas-server.domain.com_cas_serviceValidate_ticket]\{service-ticket\}&service=[http://cas.domain.com/8080][http_cas.domain.com_8080]

**步骤 6**: 如果CAS服务器通过ticket的有效性检查，那么会返回类似如下格式的XML片段

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
        <cas:authenticationSuccess> 
            <cas:user>AAAA</cas:user>
        </cas:authenticationSuccess> 
    </cas:serviceResponse>

*  其中AAAA是登陆的用户名

否则返回：

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'> 
        <cas:authenticationFailure code='XXX'> YYY </cas:authenticationFailure> 
    </cas:serviceResponse>

*  其中：
    
     *  XXX的可能取值是INVALID\_REQUEST, INVALID\_TICKET, INVALID\_SERVICE, INTERNAL\_ERROR
     *  YYY是错误描述信息

至此CAS的登陆流程结束

登陆成功后，CAS客户端应该在会话中保存登陆状态信息。CAS服务器通常在步骤 6会建立ticket和$\{client-service-url\}的映射关系，以便在登出时通知其业务系统清除缓存中的状态信息

### CAS登出流程 ###

浏览器或CAS客户端向“登出URL”发起GET请求： "登出URL"： [https://$\{cas-server-host\}:$\{cas-server-port\}/cas-server/logout][https_cas-server-host_cas-server-port_cas-server_logout] CAS服务器销毁TGT和ST，并向所有已登陆的业务系统发出登出通知请求

> java举例:  
> [https://cas-server.domain.com/cas/logout?service=http://cas.domain.com:8080][https_cas-server.domain.com_cas_logout_service_http_cas.domain.com_8080]

请求方法：POST  
请求URL: $\{client-service-url\} ( [http://cas.domain.com/8080][http_cas.domain.com_8080])  
请求头： `Content-Type：application/x-www-form-urlencoded`  
请求正文：

logoutRequest=
    <samlp:LogoutRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="#LR_TICKET_ID#" Version="2.0" IssueInstant="#CURRENT_DATETIME#"> 
        <saml:NameID xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">@NOT_USED@</saml:NameID> 
        <samlp:SessionIndex>#ST#</samlp:SessionIndex> 
    </samlp:LogoutRequest>

*  其中
    
     *  LR\_TICKET\_ID:　　 CAS服务器为每个登出通知请求所生成的一个值
     *  ST　　　　　　　　 之前登陆成功后CAS服务端传回来的Service Ticket
     *  CURRENT\_DATETIME 发出该请求时，CAS服务器的日期/时间  
        </strike>

## 登录认证过程： ##

> 1.  CAS Client 与受保护的客户端应用部署在一起, 以 Filter 方式保护受保护的资源。
> 2.  对于访问受保护资源的每个 Web 请求, CAS Client 会分析该请求的 Http 请求中是否包含 Service Ticket.
> 3.  如果没有, 则说明当前用户尚未登录, 于是将请求重定向到指定好的 CAS Server 登录地址, 并传递 Service （也就是要访问的目的资源地址），以便登录成功过后转回该地址。
> 4.  用户在第 3 步中输入认证信息, 如果登录成功, CAS Server 随机产生一个相当长度、唯一、不可伪造的 Service Ticket, 并缓存以待将来验证, 之后系统自动重定向到 Service 所在地址, 并为客户端浏览器设置一个 Ticket Granted Cookie（TGC），CAS Client 在拿到 Service 和新产生的 Ticket 过后, 在第 5, 6 步中与 CAS Server 进行身份核实, 以确保 Service Ticket 的合法性。

>     在该协议中, 所有与 CAS 的交互均采用 SSL 协议, 确保, ST 和 TGC 的安全性。协议工作过程中会有 2 次重定向的过程, 但是 CAS Client 与 CAS Server 之间进行 Ticket 验证的过程对于用户是透明的。  
>     另外, CAS 协议中还提供了 Proxy （代理）模式, 以适应更加高级、复杂的应用场景, 具体介绍可以参考 CAS 官方网站上的相关文档。

[CAS]: https://www.jianshu.com/p/8daeb20abb84
[Kerberos]: https://www.cnblogs.com/zpchcbd/p/11707302.html
[8e44475ac45e4c1f38480e4611c8118a.png]: https://img-blog.csdnimg.cn/img_convert/8e44475ac45e4c1f38480e4611c8118a.png
[e872496254fafab9e9786db6577053b9.png]: https://img-blog.csdnimg.cn/img_convert/e872496254fafab9e9786db6577053b9.png
[db9d207cf590a29390931df0e2830518.png]: https://img-blog.csdnimg.cn/img_convert/db9d207cf590a29390931df0e2830518.png
[fb323cd63088c7802d9aa261263234b8.png]: https://img-blog.csdnimg.cn/img_convert/fb323cd63088c7802d9aa261263234b8.png
[e07f9547e7ac536d5d6c163abe3a97ff.png]: https://img-blog.csdnimg.cn/img_convert/e07f9547e7ac536d5d6c163abe3a97ff.png
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9pbWcyMDE4LmNuYmxvZ3MuY29tL2Jsb2cvNDIyMTcxLzIwMTkwOC80MjIxNzEtMjAxOTA4MDgxMDExNDMxNDEtMTgzMDkyMzYzMC5wbmc?x-oss-process=image/format,png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RscGY_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200609111706260.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2p1c3RscGY=,size_16,color_FFFFFF,t_70
[Yale]: https://baike.baidu.com/item/Yale/10754982
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy81OTAzOTktMjUwZDQ3MTQyMzE1YzRmZC5wbmc?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly91cGxvYWQtaW1hZ2VzLmppYW5zaHUuaW8vdXBsb2FkX2ltYWdlcy81OTAzOTktZDBhYzA4MmZjMTYxM2U2OC5wbmc?x-oss-process=image/format,png
[https_cas-server-host_cas-server-port_cas-server_login_service_client-service-url]: https://link.jianshu.com?t=https://%24%7Bcas-server-host%7D:%24%7Bcas-server-port%7D/cas-server/login?service=%24%7Bclient-service-url%7D
[https_cas-server.domain.com_cas_login_service_http_3A_2F_2Fcas.domain.com_3A8080]: https://link.jianshu.com?t=https://cas-server.domain.com/cas/login?service=http%3A%2F%2Fcas.domain.com%3A8080
[http_cas.domain.com_8080_ticket]: https://link.jianshu.com?t=http://cas.domain.com/8080?ticket=%24
[http_cas-server-host_cas-server-port_cas-server_serviceValidate_ticket_service-ticket_service_client-service-url]: https://link.jianshu.com?t=http://%24%7Bcas-server-host%7D:%24%7Bcas-server-port%7D/cas-server/serviceValidate?ticket=%24%7Bservice-ticket%7D&service=%24%7Bclient-service-url%7D
[https_cas-server.domain.com_cas_serviceValidate_ticket]: https://link.jianshu.com?t=https://cas-server.domain.com/cas/serviceValidate?ticket=%24
[http_cas.domain.com_8080]: https://link.jianshu.com?t=http://cas.domain.com/8080
[https_cas-server-host_cas-server-port_cas-server_logout]: https://link.jianshu.com?t=https://%24%7Bcas-server-host%7D:%24%7Bcas-server-port%7D/cas-server/logout
[https_cas-server.domain.com_cas_logout_service_http_cas.domain.com_8080]: https://link.jianshu.com?t=https://cas-server.domain.com/cas/logout?service=http://cas.domain.com:8080