1. KDC
    全称：key distributed center
    作用：整个安全认证过程的票据生成管理服务，其中包含两个服务，AS和TGS
  2. AS
    全称：authentication service
    作用：为client生成TGT的服务
  3. TGS
    全称：ticket granting service
    作用：为client生成某个服务的ticket
  4. AD
    全称：account database
    作用：存储所有client的白名单，只有存在于白名单的client才能顺利申请到TGT
  5. TGT
    全称：ticket-granting ticket
    作用：用于获取ticket的票据
  6. client
    想访问某个server的客户端
  7. server
    提供某种业务的服务

认证流程

spark kerberos 续约 kerberos协议步骤_kerberos


图1 kerberos认证流程

图1展示了kerberos的认证流程，总体分为3步。

client与AS交互
client与TGS交互
client与server交互

详细分析
kerberos为什么要采用3步交互的形式来完成安全认证，那就要从kerberos的使用场景说起。

相比kerberos，https可能更为熟悉一点，通过证书和非对称加密的方式，让客户端可以安全的访问服务端，但这仅仅是客户端安全，通过校验，客户端可以保证服务端是安全可靠的，而服务端却无法得知客户端是不是安全可靠的。这也是互联网的一种特性。而kerberos可以支持双向认证，就是说，可以保证客户端访问的服务端是安全可靠的，服务端回复的客户端也是安全可靠的。

想证明client和server都是可靠的，必然要引入第三方公证平台，这里就是AS和TGS两个服务。

client向kerberos服务请求，希望获取访问server的权限。kerberos得到了这个消息，首先得判断client是否是可信赖的，也就是白名单黑名单的说法。这就是AS服务完成的工作，通过在AD中存储黑名单和白名单来区分client。成功后，返回AS返回TGT给client。
client得到了TGT后，继续向kerberos请求，希望获取访问server的权限。kerberos又得到了这个消息，这时候通过client消息中的TGT，判断出了client拥有了这个权限，给了client访问server的权限ticket。
client得到ticket后，终于可以成功访问server。这个ticket只是针对这个server，其他server需要像TGS申请。
通过这3步，一次请求就完成了。当然这里会有个问题，这样也没比https快啊。解释一下

  1. 整个过程TGT的获取只需要一次，其中有超时的概念，时间范围内TGT都是有效的，也就是说一般情况访问server只需要直接拿到ticket即可
  2. 整个过程采用的是对称加密，相对于非对称加密会有性能上的优势
  3. kerberos的用户管理很方便，只需要更新AD中的名单即可

当然整个过程的通信都是加密的，这里设计到两层加密，因为所有的认证都是通过client，也就是说kerberos没有和server直接交互，这样的原因是kerberos并不知道server的状态，也无法保证同时和server，client之间通信的顺序，由client转发可以让client保证流程顺序。

第一层加密，kerberos对发给server数据的加密，防止client得到这些信息篡改。

第二层加密，kerberos对发给client数据的加密，防止其他网络监听者得到这些信息。

client和server的通信也是如此
该协议主要分为两大步骤。

第一步:Client获取TGT（ticket-grantingticket）

  1. 客户端输入身份信息向KDC(密钥分配中心)发送请求，KDC根据客户端发送的身份信息向Ticket granting service请求取得TGT。然后KDC采用其与请求Client约定的加密策略对TGT进行加密，将TGT发送到Client。
  2. Client收到KDC响应后，使用约定的解密策略对反馈的TGT进行解密，得到TGT。

第二步:使用第一步得到TGT请求服务

  1. Client将第一步取得的TGT与请求的服务发送给KDC服务器。KDC根据请求信息为Client和请求的Service直接生成一个Session Key，用于Cilent 与Service直接的身份鉴别。
    然后KDC将Session key发送给Service,但KDC不会直接将Session Key发给Service。而是将Session key和请求用户的用户名，IP,请求过期时间，以及时间戳等信息使用与该Service约定的加密算法将这些信息加密成一个Ticket，进行加密。并发给Client，由转发给Service。由于Session Key是Client与Service通信的依据，所以要将Session Key再与之前加密生成的Ticket采用KDC与Client之间的加密算法进行加密，加密后发送个客户端。
  2. Client收到服务器响应后，采用解密算法获取Session key。由于客户端不知道KDC与Service之间的解密策略，自然无法将Ticket解密，无法篡改Tieket中的信息。Client将用户名，IP等需要的相关信息使用Session Key将其打包加密为一个Authenticator和Ticket一起发送到Service。
  3. Service收到Tiket后使用约定的解密策略进行解密，取得Session Key，用户名，IP等封装的信息。然后使用Session Key将Authenticator解密，获取用户名，IP等信息与Tieket中取得的信息比较验证用户信息。如果匹配，向Client返回信息。