一文搞定Kerberos

本文由康强同学总结分享

Kerberos 是一种身份认证协议，被广泛运用在大数据生态中，甚至可以说是大数据身份认证的事实标准。本文将详细说明 Kerberos 原理。

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

一句话来说，Kerberos 是一种基于加密 Ticket 的身份认证协议。Kerberos 主要由三个部分组成：Key Distribution Center (即KDC)、Client 和 Service。大致关系如下图所示：

客户端会先访问两次KDC，然后再访问目标Service，如：HTTP服务。

Key Distribution Center（即 KDC）, 是 Kerberos 的核心组件，主要由三个部分组成：

在深入了解 Kerberos 原理之前，先介绍一下 Kerberos 协议的几个大前提，帮助大家理解：

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

第一步，客户端通过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等信息。

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

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

第四步，客户端将:

第五步，TGS 将利用 自身的密钥从TGT中解密出TGS Session Key，然后利用TGS Session Key从Authenticator 中解密出客户端的信息。

TGS 解密出所有信息后，将进行身份检查，进行认证：

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

第六步，客户端将利用TGS Session Key解密出其中一条信息，另一条信息由于是由目标HTTP服务加密，无法解密。

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

第七步，客户端将:

第八步，HTTP服务首先利用自身的密钥解密出 HTTP Ticket 的信息，得到 HTTP Session Key；随后，利用HTTP Session Key解密出用户的Authenticator信息。

信息解密完成后，HTTP 服务同样需要做一些信息检查：

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