Kerberos安全认证过程
1 Kerberos
Kerberos是诞生于上个世纪90年代的计算机认证协议，被广泛应用于各大操作系统和Hadoop生态系统中。了解Kerberos认证的流程将有助于解决Hadoop集群中的安全配置过程中的问题。
2 Kerberos可以用来做什么
简单地说，Kerberos提供了一种单点登录(SSO)的方法。考虑这样一个场景，在一个网络中有不同的服务器，比如，打印服务器、邮件服务器和文件服务器。这些服务器都有认证的需求。很自然的，不可能让每个服务器自己实现一套认证系统，而是提供一个中心认证服务器（AS-Authentication Server）供这些服务器使用。这样任何客户端就只需维护一个密码就能登录所有服务器。
因此，在Kerberos系统中至少有三个角色：**分发中心（KDC），客户端（Client）和普通服务器（Server）。客户端和服务器将在AS的帮助下完成相互认证。在Kerberos系统中，客户端和服务器都有一个唯一的名字，叫做Principal。同时，客户端和服务器都有自己的密码，并且它们的密码只有自己和认证服务器AS知道。
图解
1. 客户端（A）向服务端（B）发送信息时，会附加一个Authenticator(认证码，该数据结构=身份信息+时间戳)来进行彼此的身份验证。开始验证之前，客户端和服务端已经有一个有且只有二人知晓的**。
下面是工作流程：
a. A用**加密了【信息+Authenticator（身份信息+时间戳）】，将其发给B
b. B用**解密了A发来的Authenticator，并将其中包含的时间戳记录下来。B将这个时间戳与自己的当前时间进行比较，如果这个时间差大于某个值（windows下默认是5分钟），B认为信息不是A发来的，拒绝后续验证。如果这个时间差小于设定值，B要检查在过去5分钟内，是否存在含有更早时间戳的Authenticator，如果没有，B认为信息确实是A发来了。至此，完成了B对A的验证。
c. B用**加密Athenticator里的时间戳，然后将其发回给A，以证明自己确实是B.
d. A收到后，解密出时间戳，经过自己的对比，确认了对方确实是B. 至此，完成了A对B的验证
2. 引入session key和**分发中心KDC
实现简单相互身份验证有一个前提，即，A和B必须有一个有且只有二人知晓的**。在2中，我们要设计一个**分发机制来完善1的流程。这里引入key distribution center, KDC**分发中心。当A尝试向B发信息时，KDC会分别向A、B发放一个加密过的session key，这相当于1中那个有且只有AB双方知晓的**（注意，在传输过程中，session key要再包裹一层**进行加密，下面将具体说到）。
3. 引入secret key（**的加密）
session key在传输过程中需要加密。因此我们又引入了一个加***，叫做secret key(或者叫long term key，在用户账号验证中，这个key是衍生自账号密码）. 这个key是KDC和A(或B)之间有且只有双方知晓的一个**。KDC与A之间进行传输时，是由仅有A与KDC双方知晓的key加密。KDC与B之间进行传输时，是由仅有B与KDC双方知晓的key加密。
4. 引入session ticket（**的识别）
实际应用中，一个KDC对应着许许多多的客户端和服务端，每个客户端与服务端之间都有一个共享的session key（**）。为了区别这些session key，我们引入session ticket的概念，它是一种内嵌了session key和客户端身份信息（原文authorization data for the client）的数据结构。相当于session key与客户端的1对1表。
下面是具体工作过程：
a. 客户端向KDC提交客户端身份信息（这个传输过程使用客户端secretkey进行加密），要求与服务端进行相互身份验证。
b. KDC生成一个仅有客户端与服务端知晓的session key。
c. KDC将session key附加上客户端身份信息形成了session ticket，并用服务端secret key加密session ticke后传给服务端。服务端收到了KDC回复，使用服务端secret key解密，获得了有且只有客户端和服务端二者知晓的**session key。
d. KDC将【session key+服务端secret key加密后的session ticket】用客户端secret key加密后，传给客户端。客户端收到了KDC的回复，用客户端secret key解密出【session key+服务端secret key加密后的session ticket】。解密出的两部分内容分开地放在一个安全的缓存中（一块隔离的内存空间，而不是硬盘上）。当客户端再次向服务端发送信息时，客户端就可以直接向服务端发送【要发送的信息+服务端secret key加密后的session ticket+用session key加密的Authenticator(身份信息+时间戳)】
e. 服务端收到了来自客户端的以上凭据，先用服务端secret key将session ticket解密，取得内嵌在session ticket里的session key，用其将Authenticator解密，得到了客户端发送消息的时间戳。之后按照1中简单相互身份验证过程中的步骤b, c, d继续进行。