Kerberos认证协议认证授权流程-白话解读

本文参考了Wikipedia上面的Kerberos词条,对Kerberos的用户认证、服务授权、服务请求过程,用大白话解读。

1前言

我相信有很多人看不懂Kerberos协议,所以我终于看懂以后用大白话说一遍,让那些看不懂的人看懂,让我忘了以后变成看不懂的人的时候再次看懂。

Kerberos是一种计算机网络认证协议,它允许某实体在非安全网络环境下通信,向另一个实体以一种安全的方式证明自己的身份。

这是Wikipedia上面的解释。
不知道什么是Kerberos的请先读一遍Wikipedia上面的Kerberos词条(自备梯子),这个词条我认为是写得最明白的,看完后再来看本文可以加深理解,看蒙了也正常,看本文也能了解个大概。

2 Kerberos核心思想

2.1 基于密码学

Kerberos是一个基于密码学的认证体系。什么是基于密码学?在我的理解,就是

能用密钥解开内容,就说明你具有这个密钥。

我举个例子说明。
当我们进行登录时,需要将UsernamePassword传输到服务端,服务端根据用户名找到用户信息后,再核对密码是否正确,核对正确以后,给用户颁发一个UserToken,作为今后用户使用系统的临时凭据。
而在Kerberos登录过程中,用户将UsernamePassword输入到登录界面中,客户端只是将Username传送到服务端,服务端找到用户信息以后,直接给用户一个UserToken,但这个UserToken是用用户的Password加密的。因此,如果用户想得到这个UserToken,那么,用户必须输入正确的Password才能解开。
也就是说,当用户输入错误的Password时,他无法得到UserToken,就无法完成登录使用系统。当输入正确的Password时,他就得到了UserToken,可以使用系统。
在Kerberos认证协议中,大量使用了这种方式和思想。这种方式的好处就是,用户的Password不会在网络上传输,并且层层的加密保证了系统即使在一个非安全的网络(可能被监听)中也不会泄露信息。

2.2 后端服务私有密钥

这里的私有密钥指的不是公钥密码体制里面的公钥和私钥,指的是

每个服务都有一个独立的密钥

基于2.1中提到的密码学认证方式,当进行服务授权时,授权中心服务授权票据使用服务的私有密钥加密,如果服务用私有密钥解开了票据内容,则证明这个票据是由授权中心提供的,则可以信任其中的内容。

3 认证过程解读

总的认证过程我画了这张时序图。
(由于本文基础是Wikipedia上的Kerberos词条,所以命名沿用了该词条的命名)
Kerberos协议认证时序图
在这张图中,加密内容这样表示

【被加密的内容】(加密密钥)

为了在中文中醒目,客户端用Client表示,认证中心用TGS表示,后端服务器用Service表示,其他变量尽可能用英文表示。

3.1 用户认证

用户认证过程如下:

  • 用户输入UsernamePassword后,ClientUsername发送到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,得到UserIDTimestrap
    • 验证TGTAuthenticator,如是否过期,两者包含的UserID是否相同等
  • 当以上消息均验证成功后,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已经有了这两条内容:

    1. Client/TGS SessionKey
    2. TGT
  • 此时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 TicketAuthenticator,如是否过期,两者包含的UserID是否相同等
  • 当以上消息均验证成功后,Service开始信任Client,返回如下消息:
"欢迎信息"
【以上内容用"Client/Service SessionKey"加密】
  • ClientClient/Service SessionKey解开消息得到欢迎信息
  • 服务请求完成,双方开始交流。

4 总结

当你把TGS看成一个普通的服务的时候,你会发现所有的服务都有这些共同点

  • 服务提供一个由服务SecretKey加密一个包含SessionKeyTicket
  • 服务SecretKey解开Ticket得到SessionKey
  • 用户信息是用SessionKey加密的

Kerberos实际上是双方在认证中心指导下进行的双方认证,因为:

  • 服务认证:用户的信息只能被拥有正确的SecretKey的服务解开,因为有SecretKey才能得到SessionKey,而真正的服务才拥有正确的SecretKey
  • 用户必须拿着用正确的SecretKey加密的Ticket才能去请求服务,否则服务解不开Ticket也就得不到SessionKey

这个认证过程,实际上就是对SecretKey的认证,并且认证方法体现了密码学的思想,即能用密钥解开内容,就说明你具有这个密钥。

5 后话

自认为写得不能再白话,总比一些学术流的文章用符号,甚至数学符号表示内容要白话。
如果文中有什么不足,请大神在评论区指导。

发布了5 篇原创文章 · 获赞 2 · 访问量 8483
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 编程工作室 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览