http://www.Sina.com/http://www.Sina.com/1.KDC
全名：密钥分布式中心
角色：整个安全认证过程的票证生成管理服务。 包括AS和TGS两种服务
2. AS
全名：身份验证服务
角色：为客户端生成TGT的服务
3.TGS
全名： ticket granting service
角色：生成客户端服务的ticket
4. AD
全名：会计数据库
角色：保存所有客户端白名单，只有白名单中的客户端才能顺利申请TGT
5. TGT
全名： ticket-granting ticket
角色：获取ticket的票证
6 .客户端
要访问服务器的客户端
7 .服务器
提供某种业务的服务
使用3358www.Sina.com/Tickets验证避免在本地存储密码的安全验证协议和在互联网上传输密码，Kerberos提供的唯一功能是KDC以外的信任不提供许可证功能和审计功能。
kerberos介绍初次请求，3次通信对方
theauthenticationservertheticketgrantingservertheserviceorhostmachinethatyou’rewantingaccessto。
图11角色
其他知识点
每次通信，消息包括两个部分，一部分是可解密的，一些不可解密的服务器端由KDC通信KDC直接向所有机器的帐户名和口令KDC本身发送口令1、重要术语
这里，我们认为获取服务器中表(数据)的服务是http服务。
2、功能
要获得http服务，必须先在KDC表中填写自己的身份。 这个过程可以在你的程序启动时进行。 Kerberos可以从kinit获得。 介绍自己用未加密的信息发送到KDC以获取ticketgrantingticket(TGT )。
(1)信息包括
你的用户名/ID你的IP地址TGT的有效时间Authentication Server收到你的请求后，会去数据库验证你是否存在。 请注意，只验证是否存在，而不验证对错。
如果存在，授权服务器将生成随机的会话密钥。 这可以是64位字符串。 此密钥用于您和Ticketgrantingserver(TGS )之间的通信。
)2)回复信息
"> Authentication Server同样会发送两部分信息给你，一部分信息为TGT，通过KDC自己的密码进行加密，包含： 你的name/IDTGS的name/ID时间戳你的IP地址TGT的生命周期TGS session key另外一部分通过你的密码进行加密，包含的信息有
TGS的name/ID时间戳生命周期TGS session key如果你的密码是正确的，你就能解密第二部分信息，获取到TGS session key。如果，密码不正确，无法解密，则认证失败。第一部分信息TGT，你是无法解密的，但需要展示缓存起来。
图 2‑1 第一次通信
4.2、你和TGS
如果第一部分你已经成功，你已经拥有无法解密的TGT和一个TGS Session Key。
（1） 请求信息
a) 通过TGS Session Key加密的认证器部分：
你的name/ID时间戳b) 明文传输部分：
请求的Http服务名（就是请求信息）HTTP Service的Ticket生命周期c) TGT部分
Ticket Granting Server收到信息后，首先检查数据库中是否包含有你请求的Http服务名。如果无，直接返回错误信息。
如果存在，则通过KDC的密码解密TGT，这个时候。我们就能获取到TGS Session key。然后，通过TGS Session key去解密你传输的第一部分认证器，获取到你的用户名和时间戳。
TGS再进行验证：
对比TGT中的用户名与认证器中的用户名比较时间戳（网上有说认证器中的时间错和TGT中的时间错，个人觉得应该是认证器中的时间戳和系统的时间戳），不能超过一定范围检查是否过期检查IP地址是否一致检查认证器是否已在TGS缓存中（避免应答攻击）可以在这部分添加权限认证服务TGS随机产生一个Http Service Session Key, 同时准备Http Service Ticket(ST)。
（2） 回答信息
a) 通过Http服务的密码进行加密的信息（ST）：
你的name/IDHttp服务name/ID你的IP地址时间戳ST的生命周期Http Service Session Keyb) 通过TGS Session Key加密的信息
Http服务name/ID时间戳ST的生命周期Http Service Session Key你收到信息后，通过TGS Session Key解密，获取到了Http Service Session Key，但是你无法解密ST。
图 2‑2 第二次通信
4.3、你和Http服务
在前面两步成功后，以后每次获取Http服务，在Ticket没有过期，或者无更新的情况下，都可直接进行这一步。省略前面两个步骤。
（1） 请求信息
a) 通过Http Service Session Key，加密部分
你的name/ID时间戳b) ST
Http服务端通过自己的密码解压ST（KDC是用Http服务的密码加密的），这样就能够获取到Http Service Session Key，解密第一部分。
服务端解密好ST后，进行检查
对比ST中的用户名（KDC给的）与认证器中的用户名比较时间戳（网上有说认证器中的时间错和TGT中的时间错，个人觉得应该是认证器中的时间戳和系统的时间戳），不能超过一定范围检查是否过期检查IP地址是否一致检查认证器是否已在HTTP服务端的缓存中（避免应答攻击）（2） 应答信息
a) 通过Http Service Session Key加密的信息
Http服务name/ID时间戳
图 2‑3 第三次通信
你在通过缓存的Http Service Session Key解密这部分信息，然后验证是否是你想要的服务器发送给你的信息。完成你的服务器的验证。
至此，整个过程全部完成。
5. 实现github地址：https://github.com/wukenaihe/KerberosService