Kerberos认证协议认证授权流程-白话解读
本文参考了Wikipedia上面的Kerberos词条，对Kerberos的用户认证、服务授权、服务请求过程，用大白话解读。
1前言
我相信有很多人看不懂Kerberos协议，所以我终于看懂以后用大白话说一遍，让那些看不懂的人看懂，让我忘了以后变成看不懂的人的时候再次看懂。
Kerberos是一种计算机网络认证协议，它允许某实体在非安全网络环境下通信，向另一个实体以一种安全的方式证明自己的身份。
这是Wikipedia上面的解释。
不知道什么是Kerberos的请先读一遍Wikipedia上面的Kerberos词条（自备梯子），这个词条我认为是写得最明白的，看完后再来看本文可以加深理解，看蒙了也正常，看本文也能了解个大概。
2 Kerberos核心思想
2.1 基于密码学
Kerberos是一个基于密码学的认证体系。什么是基于密码学？在我的理解，就是
能用密钥解开内容，就说明你具有这个密钥。我举个例子说明。
当我们进行登录时，需要将Username和Password传输到服务端，服务端根据用户名找到用户信息后，再核对密码是否正确，核对正确以后，给用户颁发一个UserToken，作为今后用户使用系统的临时凭据。
而在Kerberos登录过程中，用户将Username和Password输入到登录界面中，客户端只是将Username传送到服务端，服务端找到用户信息以后，直接给用户一个UserToken，但这个UserToken是用用户的Password加密的。因此，如果用户想得到这个UserToken，那么，用户必须输入正确的Password才能解开。
也就是说，当用户输入错误的Password时，他无法得到UserToken，就无法完成登录使用系统。当输入正确的Password时，他就得到了UserToken，可以使用系统。
在Kerberos认证协议中，大量使用了这种方式和思想。这种方式的好处就是，用户的Password不会在网络上传输，并且层层的加密保证了系统即使在一个非安全的网络（可能被监听）中也不会泄露信息。
2.2 后端服务私有密钥
这里的私有密钥指的不是公钥密码体制里面的公钥和私钥，指的是
每个服务都有一个独立的密钥基于2.1中提到的密码学认证方式，当进行服务授权时，授权中心将服务授权票据使用服务的私有密钥加密，如果服务用私有密钥解开了票据内容，则证明这个票据是由授权中心提供的，则可以信任其中的内容。
3 认证过程解读
总的认证过程我画了这张时序图。
（由于本文基础是Wikipedia上的Kerberos词条，所以命名沿用了该词条的命名）
在这张图中，加密内容这样表示
【被加密的内容】(加密密钥)为了在中文中醒目，客户端用Client表示，认证中心用TGS表示，后端服务器用Service表示，其他变量尽可能用英文表示。
3.1 用户认证
用户认证过程如下：
- 用户输入
Username和Password后，Client将Username发送到TGS； TGS根据Username找出用户信息，取出Password，返回两条消息：
消息1
Client与TGS之间通信的密钥: "Client/TGS SessionKey"
【以上内容用"Password"加密】消息2 "TGT"
"Client/TGS SessionKey"(与上条消息的Client/TGS SessionKey相同), "UserID", "UserIP", "Expires"
【以上内容用TGS自己的服务密钥"TGS's SecretKey"加密】Client用用户输入的Password解开用Password加密的Client/TGS SessionKey就得到了他的用户凭据Client/TGS SessionKey。
此时Client就拥有了
1. "Client/TGS SessionKey" 原文
2. "TGT" 密文Client拥有了用TGS的私有密钥TGS's SecretKey加密的TGT，就可以使用TGS服务。因此，Client到此处就完成了用户认证。
3.2 服务授权
服务授权过程如下：
- 用户发送如下三条消息给
TGS
消息1
"TGT"
【记住该内容是"TGS"用"TGS's SecretKey"加密的】消息2
"ServiceID" 要请求的服务的ID消息3 "Authenticator":
"UserID"，"Timestrap"
【以上内容用"Client/TGS SessionKey"加密】TGS收到消息后，作如下处理：
- 查找是否有ID为
ServiceID的服务 - 用
TGS's SecretKey解开TGT，得到Client/TGS SessionKey,UserID,Expires - 用
Client/TGS SessionKey解开Authenticator，得到UserID和Timestrap - 验证
TGT和Authenticator，如是否过期，两者包含的UserID是否相同等
- 查找是否有ID为
- 当以上消息均验证成功后，
TGS返回如下两条消息：
消息1 "Client-Service Ticket":
"Client/Service SessionKey"(Client与Service通信的密钥), "UserID", "UserIP", "Expires"
【以上内容用"Service's SecretKey"加密】消息2
"Client/Service SessionKey"
【以上内容用"Client/TGS SessionKey"加密】- Client用
Client/TGS SessionKey解开消息2就得到了Client/Service SessionKey Client拥有了用私有密钥Service's SecretKey加密的Client-Service Ticket，就可以使用Service服务。因此，Client到此处就完成了服务授权。回想一下，在进行服务授权之前Client已经有了这两条内容：
Client/TGS SessionKeyTGT
此时
Client就拥有了
1. "Client/TGS SessionKey" 原文
2. "TGT" 密文
3. "Client-Service Ticket" 密文
4. "Client/Service SessionKey" 原文3.3 服务请求
Client发送如下两条消息给Service
消息1
"Client-Service Ticket"
【记住该内容是"TGS"用"Service's SecretKey"加密的】消息2 "Authenticator":
"UserID", "Timestrap"
【以上内容用"Client/Service SessionKey"加密】Service收到后，作如下处理
- 用
Service's SecretKey解开Client-Service Ticket得到Client/Service SessionKey,UserID,UserIP,Expires - 用
Client/Service SessionKey解开Authenticator得到UserID, Timestrap - 验证
Client-Service Ticket和Authenticator，如是否过期，两者包含的UserID是否相同等
- 用
- 当以上消息均验证成功后，
Service开始信任Client，返回如下消息：
"欢迎信息"
【以上内容用"Client/Service SessionKey"加密】Client用Client/Service SessionKey解开消息得到欢迎信息。- 服务请求完成，双方开始交流。
4 总结
当你把TGS看成一个普通的服务的时候，你会发现所有的服务都有这些共同点
- 向
服务提供一个由服务SecretKey加密一个包含SessionKey的Ticket 服务用SecretKey解开Ticket得到SessionKey- 用户信息是用
SessionKey加密的
Kerberos实际上是双方在认证中心指导下进行的双方认证，因为：
- 对
服务认证：用户的信息只能被拥有正确的SecretKey的服务解开，因为有SecretKey才能得到SessionKey，而真正的服务才拥有正确的SecretKey。 - 用户必须拿着用正确的
SecretKey加密的Ticket才能去请求服务，否则服务解不开Ticket也就得不到SessionKey。
这个认证过程，实际上就是对SecretKey的认证，并且认证方法体现了密码学的思想，即能用密钥解开内容，就说明你具有这个密钥。
5 后话
自认为写得不能再白话，总比一些学术流的文章用符号，甚至数学符号表示内容要白话。
如果文中有什么不足，请大神在评论区指导。