Kerberos认证是什么？Kerberos简介

　　在希腊神话中Kerberos是守护地狱之门的一条凶猛的三头神犬，而在本文中主要介绍的Kerberos认证是由美国麻省理工学院（MIT）首先提出并实现的，是该校的雅典娜计划的一部分。
　　Kerberos协议主要用于计算机网络的身份鉴别（Authentication）,其特点是用户只需输入一次身份验证信息就可以凭借此验证获得的票据（ticket-granting ticket）访问多个服务，即SSO（single sign on）。由于在每个Client和Service之间建立共享密钥，使得该协议具有相当的安全性。
　　在网络中，认证主要用来解决各个通讯实体之间相互证明彼此身份的问题。对于如何进行认证，我们通常会采用这样的方法：如果一个秘密仅仅有认证方和被认证方知道，认证方可以通过让被认证方提供这个秘密来证明对方的身份。这个过程实际上涉及到认证的三个重要方面：秘密如何表示、被认证方如何向认证方提供秘密、认证方如何识别秘密。
　　基于这三个方面，Kerberos认证可以进行最大限度的简化成Client和Server两个通讯实体，他们之间共同的秘密用KServer-Client来表示。Client在认证过程中向Server提供以明文形式表示的Client标识和使用KServer-Client加密的Client标识以便于让Server进行有效的认证：
　　由于这个秘密仅仅被Client和Server知晓，所以被 Client加密过的Client标识只能被Client和Server解密。Server接收到Client传送的这两组信息，先通过KServer-Client对后者进行解密，随后将解密的数据同前者进行比较，如果完全一样，则可以证明Client能够提供正确的KServer-Client，而这个世界上，只有真正的Client和自己知道KServer-Client，这样就可以证明对方的真实性。
　　
　　整个过程看起来非常简单，但是实际上Kerberos认证远比这个过程复杂的多，在了解Kerberos真实的认证过程之前我们先给出两个重要的概念：
　　长期密钥：在安全领域中，有的密钥可能长期内保持不变，比如密码，可能几年都不曾改变。这样的密钥以及由此派生的其他密钥被称为长期密钥。长期密钥有这样的原则：被长期密钥加密的数据不应该在网络上传输。因为任何加密算法都不可能做到绝对保密，一旦这些被长期密钥加密的数据包被黑客截获，在理论上，只要有充足的时间，都是可以通过计算获得用户用于加密的密钥的。
　　对于一个账户来说，密码仅限于该账户的所有者知晓，甚至对于管理员都应该是保密的。但是密码却又是证明身份的凭据，所以必须通过基于密码的派生信息来证明用户的真实身份，在这种情况下，一般将账户密码进行Hash运算得到一个Hash值，也可以称之为主密钥。由于Hash算法是不可逆的，同时可以保证密码和主密钥派生的确定性，这样既保证了密码的保密性，同时又保证主密钥和密码本身在证明用户身份时具有相同的效力。
　　短期密钥：由于被长期密钥加密的数据包不能在网络上传送，所以需要使用另一种密钥来加密需要进行网络传输的数据。这种密钥只在一段时间内有效，即使加密过的数据包被黑客截获，等他把密钥计算出来的时候，这个密钥早就已经过期了。我们把这种密钥称为短期密钥。
　　先来看看Kerberos协议的前提条件：
　　如图所示，Client与KDC， KDC与Service 在协议工作前已经有了各自的共享密钥，并且由于协议中的消息无法穿透防火墙，这些条件就限制了Kerberos协议往往用于一个组织的内部， 使其应用场景不同于X.509 PKI。
　　
　　过程
　　Kerberos协议分为两个部分：
　　1 . Client向KDC发送自己的身份信息，KDC从Ticket Granting Service得到TGT(ticket-granting ticket)， 并用协议开始前Client与KDC之间的密钥将TGT加密回复给Client。
　　此时只有真正的Client才能利用它与KDC之间的密钥将加密后的TGT解密，从而获得TGT。
　　（此过程避免了Client直接向KDC发送密码，以求通过验证的不安全方式）
　　2. Client利用之前获得的TGT向KDC请求其他Service的Ticket，从而通过其他Service的身份鉴别。
　　Kerberos协议的重点在于第二部分，简介如下：
　　
　　1． Client将之前获得TGT和要请求的服务信息(服务名等)发送给KDC，KDC中的Ticket Granting Service将为Client和Service之间生成一个Session Key用于Service对Client的身份鉴别。然后KDC将这个Session Key和用户名，用户地址（IP），服务名，有效期, 时间戳一起包装成一个Ticket(这些信息最终用于Service对Client的身份鉴别)发送给Service， 不过Kerberos协议并没有直接将Ticket发送给Service，而是通过Client转发给Service.所以有了第二步。
　　2． 此时KDC将刚才的Ticket转发给Client。由于这个Ticket是要给Service的，不能让Client看到，所以KDC用协议开始前KDC与Service之间的密钥将Ticket加密后再发送给Client。同时为了让Client和Service之间共享那个秘密(KDC在第一步为它们创建的Session Key)， KDC用Client与它之间的密钥将Session Key加密随加密的Ticket一起返回给Client。
　　3． 为了完成Ticket的传递，Client将刚才收到的Ticket转发到Service. 由于Client不知道KDC与Service之间的密钥，所以它无法算改Ticket中的信息。同时Client将收到的Session Key解密出来，然后将自己的用户名，用户地址（IP）打包成Authenticator用Session Key加密也发送给Service。
　　4． Service 收到Ticket后利用它与KDC之间的密钥将Ticket中的信息解密出来，从而获得Session Key和用户名，用户地址（IP），服务名，有效期。然后再用Session Key将Authenticator解密从而获得用户名，用户地址（IP）将其与之前Ticket中解密出来的用户名，用户地址（IP）做比较从而验证Client的身份。
　　5． 如果Service有返回结果，将其返回给Client。
　　kerberos在hadoop上的应用
　　Hadoop集群内部使用Kerberos进行认证
　　
　　具体的执行过程可以举例如下：
　　
　　在分析了整个Kerberos认证过程之后，Kerberos的优点也体现出来了。首先它具有较高的性能，一旦Client获得用于访问某个Server的票据，则该Server就能根据票据实现对Client的验证，不再需要KDC的参与；其次Kerberos可以进行双向验证，Client在访问Server的资源之前可以要求对Server的身份进行验证；第三就是互操作性，Kerberos最初由MIT提出并实现的，现在已经成为计算机领域一个被广泛接受的标准，所以使用Kerberos可以轻松实现不同平台之间的互操作。
　　但是Kerberos的缺点同样存在，比如Kerberos身份认证采用的是对称加密机制，加密和解密使用相同的密钥，安全性有所降低；Kerberos中身份认证服务和票据授权服务时集中式管理的，容易形成瓶颈，系统的性能和安全性也过分依赖于这两个服务的性能和安全。