目录
一.简介
Kerberos是由MIT开发的一种基于对称密码体系的网络认证协议，用来为C/S应用程序提供强大的认证服务。
一定注意，Kerberos适用于用户需求非常大的一种环境，因此才需要这样一个分布式环境来将职能分散到三个服务器，从而降低了运维成本和难度，减轻服务器负担。题外话，kerberos的英文释义就是《哈利波特》第一部里看守密室的那种三头犬（地狱看门犬），这样三个服务器的框架是不是就好记多了！
二.相关概念
在正式介绍Kerberos之前有一些重要的相关概念需要我们了解一下：
这里我做一些解释，首先就是Ticket，票据。它是由AS或TGS颁发给用户的一份加密消息，加密的内容大致如上图所示。其中，AS颁发给用户的是由AS用它与TGS两个服务器的对称密钥加密的票据，TGS颁发的是TGS用它与Service server两个服务器的对称密钥加密的票据，因此用户是完全不知道其中的内容的。
AS是认证服务器，是用户首先接触到的服务器，在这里我们需要提交我们的账号和密码来让AS知道我们是合法的用户，然后它就让我们拿着一份票据（Ticket）去找下一台服务器，TGS。
TGS就是票据授权服务器，它的作用非常类似于查看用户权限，即根据我们在后台的权限等级来评判我们是否有使用某种功能的权利，并将它的评判结果也打包成一份票据（Ticket），让我们带去找最后一个服务器，Service server（简称V）。
终于，我们来到了V，应用服务器，它会根据TGS生成的票据来最终决定是否提供此服务，若权限足够，则授权用户的服务请求。
三.认证流程
在了解了一些相关概念后，就可以开始介绍Kerberos的认证流程了，这里分为域内域外两种认证流程来介绍。
首先我们来看Kerberos域内认证流程，即用户申请的是本Kerberos域内的服务请求。假设我们想要上校园网内访问学校的教学在线平台提交Java作业。
可以看到，1.用户首先向AS请求认证， 这里就好比我们打开教学在线平台并填写了用户名和密码，尝试登录进网站当中。之后AS会处理我们提交的用户信息，并在后台数据库中核对，2.之后根据结果颁发给我们Ticket-tgs，注意，这个票据是AS想要TGS知道的信息，所以它是用AS和TGS二者所交换的对称密钥加密的（用户无从得知其中内容）。这样我们就完成了与AS的交互。
在这之后，3.我们便向TGS请求应用服务器的服务，这就好比我们在教学在线庞大的课程库中找到并打开了Java这门课程，并点击了提交作业的链接。此时TGS就要对我们的权限进行核实，即在后台数据库中找到选课名单看看有没有这位同学的信息，4.并将查询结果打包成Ticket-v颁发给用户。
最后，5.我们便向应用服务器发送Ticket-v，应用服务器打开Ticket-v后查询TGS的授权建议，如果权限足够，即我们确实选了Java这门课，6.那么就为我们用户授权提交作业这个功能，至此，整个在Kerberos域内的Kerberos认证流程就结束了！
第二种情况就是我们请求的是Kerberos域外的一个服务。此时我们不能直接向域外的AS申请服务，因为上面没有我们的信息。因此我们还是只能在本域内的AS登录。注意，这种远程服务实现的前提是两地的TGS服务器达成了某种认证协议！
首先1.我们同样向本域AS发出申请，2.并得到本域的Ticket-tgs。3.之后我们就向本域TGS上交Ticket-tgs，注意，这里我们得到的不再是本域V的Ticket-v了，由于我们申请的是域外服务，所以4.本地的TGS给我们提供的是两地TGS之间的票据，从而告知对方我们的用户权限。之后5.我们向域外的TGS提交Ticket-tgstgs，6.并得到远程服务器的票据Ticket-outv，最后7.我们用Ticket-outv向远程服务器请求服务即可！
这里有一个小小的讨论，为什么我们是在两地的TGS服务器上达成某种认证协议呢？
首先我们可以排除V，因为应用服务器这上面没有任何关于用户信息或者权限，它仅仅是按照TGS的指示提供某种服务罢了，两个应用服务器根本实现不了认证交互功能。
那么是AS吗？答案是否定的。如果双方AS有某种协议来实现相互认证，那么我们可以做到的是在域外的AS上登录，但由于这种情况下域外的TGS上是没有我们的信息的，所以域外AS虽然确认了我们是合法用户，但域外TGS却无法查询到我们的权限信息，自然无法进一步为我们提供服务了。
所以我们要在TGS之间创建某种协议，来共享用户的权限信息，这样一来只要用户在域内的TGS上得到远程TGS票据，就可以让远程TGS知道我们的用户权限，就可以为我们提供服务了！
本文到此结束。