kerberos学习系列一：原理

本文主要是介绍kerberos学习系列一：原理，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1、简介

Kerberos 一词来源于古希腊神话中的 Cerberus —— 守护地狱之门的三头犬。

Kerberos 是一种基于加密 Ticket 的身份认证协议。Kerberos 主要由三个部分组成：Key Distribution Center (即KDC)、Client 和 Service。

优势：

密码无需进行网络传输。基于 Ticket 实现身份认证，保障密钥安全性。
双向认证。整个认证过程中，不仅需要客户端进行认证，待访问的服务也需要进行身份认证。
高性能。一旦Client获得用过访问某个Server的Ticket，该Server就能根据这个Ticket实现对Client的验证，而无须KDC的再次参与。

2、核心概念

Kerberos基础概念可以参考本链接
所有概念可以参考上面链接内容，核心概念可以参考下面内容：

Principal：大致可以认为是 Kerberos 世界的用户名，用于标识身份。principal 主要由三部分构成：primary，instance(可选) 和 realm。
- 包含 instance 的principal，一般会作为server端的principal，如：NameNode，HiverServer2，Presto Coordinator等；
- 不含有 instance 的principal，一般会作为客户端的principal，用于身份认证。例子如下图所示：
Keytab：“密码本”。包含了多个 principal 与密码的文件，用户可以利用该文件进行身份认证。
Ticket Cache：客户端与 KDC 交互完成后，包含身份认证信息的文件，短期有效，需要不断renew。
Realm：Kerberos 系统中的一个namespace。不同 Kerberos 环境，可以通过 realm 进行区分。
Key Distribution Center（即 KDC）, 是 Kerberos 的核心组件，主要由三个部分组成：
- Kerberos Database: 包含了一个 Realm 中所有的 principal、密码与其他信息。（默认：Berkeley DB）
- Authentication Service(AS): 进行用户信息认证，为客户端提供 Ticket Granting Tickets(TGT)。
- Ticket Granting Service(TGS): 验证 TGT 与 Authenticator，为客户端提供 Service Tickets。
- KDC Admin Account：
  用法：KDC Admin Account指用于管理Kerberos数据库和执行管理操作的管理员帐户。示例：使用KDC Admin Account登录到Kadmin管理界面，执行各种管理操作。
Authenticator：
用法：Authenticator用于身份验证，并生成Ticket。示例：用户进行身份验证并生成Authenticator：kinit user@EXAMPLE.COM 使用Authenticator进行服务访问：kvno service/host@EXAMPLE.COM
Credential：
用法：Credential是Kerberos中表示用户身份的一种凭据，包含了TGT和相关信息。示例：当用户通过身份验证后，生成一个Credential：kinit user@EXAMPLE.COM 使用Credential访问受保护资源：klist
Ticket：
用法：Ticket是已通过身份验证的用户的许可证，用于访问受保护的资源。示例：用户通过身份验证后，获得一个Ticket：kinit user@EXAMPLE.COM 使用Ticket访问受限资源：klist
Kadmin：
用法：Kadmin用于管理Kerberos数据库和执行管理操作。示例：创建Principal：kadmin -q “addprinc user@EXAMPLE.COM” 生成Keytab文件：kadmin -q “ktadd -k keytabfile principal”
TGT：
用法：TGT是用于获取其他服务票据的票据。示例：用户通过身份验证后，获得一个TGT，用于获取其他受保护资源的许可证。
Kerberos Client：
用法：Kerberos Client指使用Kerberos协议进行身份验证的客户端，可以是用户或服务。示例：配置客户端以支持Kerberos协议，并使用Kerberos客户端与KDC进行身份验证。

3、原理

3.1 前置知识

Kerberos 基于 Ticket 实现身份认证，而非密码。如果客户端无法利用本地密钥，解密出 KDC 返回的加密Ticket，认证将无法通过。
客户端将依次与 Authentication Service, Ticket Granting Service 以及目标Service进行交互，共三次交互。
客户端与其他组件交互时，都将获取到两条信息，其中一条可以通过本地密钥解密出，另外一条将无法解密出。
客户端想要访问的目标服务，将不会直接与KDC交互，而是通过能否正确解密出客户端的请求来进行认证。
KDC Database 包含有所有 principal 对应的密码。
Kerberos 中信息加密方式一般是对称加密（可配置成非对称加密）。

3.2 原理图

参考文章
在这里插入图片描述

3.3 整体流程

下面，我们将以客户端访问 http 服务为例，解释整个认证过程。

1. 客户端与 Authentication Service

第一步，客户端通过kinit USERNAME或其他方式，将客户端ID, 目标HTTP服务ID, 网络地址（可能是多个机器的IP地址列表，如果想在任何机器上使用，则可能为空），以及TGT有效期的寿命等信息发送给 Authentication Service。
在这里插入图片描述
第二步，Authentication Server 将检查客户端ID是否在KDC数据库中。

在这里插入图片描述
如果 Authentication Server 检查操作没有异常，那么KDC将随机生成一个 key，用于客户端与 Ticket Granting Service(TGS) 通信。这个Key，一般被称为 TGS Session Key。随后 Authentication Server 将发送两条信息给客户端。示意图如下：

在这里插入图片描述
其中一条信息被称为TGT，由TGS的密钥加密，客户端无法解密，包含客户端ID, TGS Session Key等信息。另一条信息由客户端密钥加密，客户端可以正常解密，包含目标 HTTP 服务ID，TGS Session Key等信息。

第三步，客户端利用本地的密钥解密出第二条信息。如果本地密钥无法解密出信息，那么认证失败。示意图如下：
在这里插入图片描述

2. 客户端与 Ticket Granting Service

这时候，客户端有了 TGT（由于本地没有TGS的密钥，导致无法解密出其数据）与 TGS Session Key。

第四步，客户端将做如下操作：
1、“无脑”将 AS 发送过来的TGT（由TGS密钥加密）转发给TGS
2、将包含自身信息的Authenticator(由TGS Session Key加密)发送给TGS

在这里插入图片描述
第五步，TGS 将利用自身的密钥从TGT中解密出TGS Session Key，然后利用TGS Session Key从Authenticator 中解密出客户端的信息。

在这里插入图片描述
TGS 解密出所有信息后，将进行身份检查，进行认证：

将客户端ID与TGT的客户端ID进行比较
比较来自 Authenticator 的时间戳和TGT的时间戳 (典型的Kerberos系统的容忍度是2分钟，但也可以另行配置)
检查TGT是否过期
检查Authenticator是否已经在TGS的缓存中（为了避免重放攻击）

当所有检查都通过后， TGS 随机生成一个 Key 用于后续客户端与 HTTP 服务交互时进行通信加密使用，即 HTTP Session Key。同样地，TGS 将发送两条信息给客户端: 其中一条是 HTTP Ticket，由 HTTP 服务的密钥进行加密；另一条则由TGS Session Key加密，包含了客户端信息与时间戳。

在这里插入图片描述
第六步，客户端将利用TGS Session Key解密出其中一条信息，另一条信息由于是由目标HTTP服务加密，无法解密。

3. 客户端与 HTTP Service

这时候，客户端有了HTTP Ticket（由于本地没有HTTP服务的密钥，导致无法解密出其数据）与 HTTP Session Key。

第七步，客户端将:
1、“无脑”将 AS 发送过来的 HTTP Ticket（由HTTP 密钥加密）转发给目标 http 服务。
2、将包含自身信息的Authenticator(由HTTP Session Key加密)发送给 http 服务。
在这里插入图片描述
第八步，HTTP服务首先利用自身的密钥解密出 HTTP Ticket 的信息，得到 HTTP Session Key；随后，利用HTTP Session Key解密出用户的Authenticator信息。

在这里插入图片描述
信息解密完成后，HTTP 服务同样需要做一些信息检查：

将 Authenticator 中的客户端ID与HTTP Ticket中的客户端ID进行比较
比较来自 Authenticator 的时间戳和 HTTP Ticket 的时间戳 (典型的 Kerberos 系统对差异的容忍度是 2 分钟，但也可以另行配置)
检查Ticket是否过期
检查 Authenticator 是否已经在HTTP服务器的缓存中（为了避免重播攻击）

至此，所有的认证过程通过，客户端即可与远程HTTP服务完成了身份认证，可以进行后续的信息通信。