Kerberos安全體系詳解---Kerberos的簡單實現

1.  Kerberos簡介

1.1. 功能

1. 一個安全認證協議

2. 用tickets驗證

3. 避免本地保存密碼和在互聯網上傳輸密碼

4. 包含一個可信任的第三方

5. 使用對稱加密

6. 客戶端與服務器（非KDC）之間可以相互驗證

Kerberos只提供一種功能——在網絡上安全的完成用戶的身份驗證。它並不提供受權功能或者審計功能。

1.2. 概念

首次請求，三次通訊方

• the Authentication Server
• the Ticket Granting Server
• the Service or host machine that you’re wanting access to.

 

圖 1‑1 角色

其餘知識點

• 每次通訊，消息包含兩部分，一部分可解碼，一部分不可解碼
• 服務端不會直接有KDC通訊
• KDC保存全部機器的帳戶名和密碼
• KDC自己具備一個密碼

2.  3次通訊

 

　　咱們這裏已獲取服務器中的一張表（數據）的服務覺得，爲一個http服務。

2.1. 你和驗證服務

　　若是想要獲取http服務，你首先要向KDC表名你本身的身份。這個過程能夠在你的程序啓動時進行。Kerberos能夠經過kinit獲取。介紹本身經過未加密的信息發送至KDC獲取Ticket Granting Ticket (TGT)。

（1）信息包含

• 你的用戶名/ID
• 你的IP地址
• TGT的有效時間

　　Authentication Server收到你的請求後，會去數據庫中驗證，你是否存在。注意，僅僅是驗證是否存在，不會驗證對錯。

　　若是存在，Authentication Server會產生一個隨機的Session key(能夠是一個64位的字符串)。這個key用於你和Ticket Granting Server (TGS)之間通訊。

（2）回送信息

　　Authentication Server一樣會發送兩部分信息給你，一部分信息爲TGT，經過KDC本身的密碼進行加密，包含：

• 你的name/ID
• TGS的name/ID
• 時間戳
• 你的IP地址
• TGT的生命週期
• TGS session key

另一部分經過你的密碼進行加密，包含的信息有

• TGS的name/ID
• 時間戳
• 生命週期
• TGS session key

 

圖 2‑1 第一次通訊

　　若是你的密碼是正確的，你就能解密第二部分信息，獲取到TGS session key。若是，密碼不正確，沒法解密，則認證失敗。第一部分信息TGT，你是沒法解密的，但須要展現緩存起來。

2.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再進行驗證：

1. 對比TGT中的用戶名與認證器中的用戶名
2. 比較時間戳（網上有說認證器中的時間錯和TGT中的時間錯，我的以爲應該是認證器中的時間戳和系統的時間戳），不能超過必定範圍
3. 檢查是否過時
4. 檢查IP地址是否一致
5. 檢查認證器是否已在TGS緩存中（避免應答攻擊）
6. 能夠在這部分添加權限認證服務

　　TGS隨機產生一個Http Service Session Key, 同時準備Http Service Ticket(ST)。

（2）    回答信息

　　a)        經過Http服務的密碼進行加密的信息（ST）：

• 你的name/ID
• Http服務name/ID
• 你的IP地址
• 時間戳
• ST的生命週期
• Http Service Session Key

　　b)       經過TGS Session Key加密的信息

• Http服務name/ID
• 時間戳
• ST的生命週期
• Http Service Session Key

　　你收到信息後，經過TGS Session Key解密，獲取到了Http Service Session Key，可是你沒法解密ST。

 

圖 2‑2 第二次通訊

2.3. 你和Http服務

　　在前面兩步成功後，之後每次獲取Http服務，在Ticket沒有過時，或者無更新的狀況下，均可直接進行這一步。省略前面兩個步驟。

（1）    請求信息

　　a)        經過Http Service Session Key，加密部分

• 你的name/ID
• 時間戳

　　b)       ST

　　　Http服務端經過本身的密碼解壓ST（KDC是用Http服務的密碼加密的），這樣就可以獲取到Http Service Session Key，解密第一部分。

服務端解密好ST後，進行檢查

1. 對比ST中的用戶名（KDC給的）與認證器中的用戶名
2. 比較時間戳（網上有說認證器中的時間錯和TGT中的時間錯，我的以爲應該是認證器中的時間戳和系統的時間戳），不能超過必定範圍
3. 檢查是否過時
4. 檢查IP地址是否一致
5. 檢查認證器是否已在HTTP服務端的緩存中（避免應答攻擊）

（2）    應答信息

a)        經過Http Service Session Key加密的信息

• Http服務name/ID
• 時間戳

 

圖 2‑3 第三次通訊

　　你在經過緩存的Http Service Session Key解密這部分信息，而後驗證是不是你想要的服務器發送給你的信息。完成你的服務器的驗證。

至此，整個過程所有完成。

3.  實現

github地址：https://github.com/wukenaihe/KerberosService

 

　　github上面的程序暫時尚未詳細的說明。本身感受設計的稍微有點亂。本身之因此要從新實現的緣由就是如今MIT的kerberos、apache directory、Windows AD配置都至關麻煩，使用起來也很是麻煩。因此想重新設計一個簡單易用的，可是同時又考慮到靈活性(又不想依賴於spring)因此，整體感受略亂。如今，加密經過AES方式，密碼保存用文件，序列化經過kryo.

　　項目中使用後，準備再添加使用說明，和程序結構。若是有任何疑問，歡迎詢問。

3.1.  項目組成及功能

子項目名	功能	依賴
ks-parent	Pom類型，定義依賴與版本
ks-common	傳輸的bean，異常體系，基本工具類	ks-parent
ks-server	KDC服務端	ks-parent、ks-common
ks-client	KDC客戶端	ks-parent、ks-common
ks-tool	KDC工具類，服務端database文件管理，客戶端密碼文件管理。能夠擴展數據庫	ks-parent、ks-common
ks-example	例子

3.2. Ks-common

　　基礎的JavaBean，主要包含6次傳輸過程當中的javabean，還有ServiceTicket與TicketGrantingTicket。

　　Kerberos部分錯誤經過異常進行傳輸，所以涉及到的全部異常較多。在該系統中全部的異常均爲runtime異常，避免強制catch。

　　工具類，主要包含Kryo序列化工具（非線程安全）、安全工具類（AES、DES加密算法）、時間比較類。

3.2.1.    基礎類（com.cgs.kerberos.bean）

這裏的類均爲2章中，3次通訊過程當中的信息封裝。全部的類均是可序列化的，在該項目中經過Kryo進行序列化。

 

圖 4‑1通訊間的信息封裝

除了第一次請求和最後一次應答，其餘部分均包含能解析部分與不可解析部分。持有者不可能對不可解析部分修改，因此不可解析部分包含着進行驗證的信息及用於解密的鑰匙。

TGT包含的是客戶端信息，及一把鑰匙；主要用戶KDC驗證，請求者是否合法。ST包含客戶端信息，及一把鑰匙；主要用於請求服務器（非KDC），驗證客戶端。

1.2.2.    異常體系

 

圖 4‑2 異常體系

　　異常體系主要由Kerberos的異常系列和加密算法異常體系兩部分組成。

3.2.3.    工具類

　　KryoSerializer：將對象轉化爲byte[]二進制，將二進制轉化爲對象。

　　Kryo在持久化速度和持久化後的空間上，都有無可比擬的速度。它的缺點：只能在java語言中使用、不能作兼容性。考慮到，調用該kerberos的系統使用的持久化方式爲kryo，咱們這裏默認的也採用kryo持久化。Bug較多，不過在該系統使用到的功能中，均無bug。

　　在該框架中，不須要用到對象之間的引用。同時，由於是經過網絡傳輸的，因此不能進行註冊。（會把類的全限定麼所有持久化進去）。

　　KryoSerializer聽說是非線程安全的。

　　SecurityUtil：經過DES或者AES進行加密與解密。DES經過64位密碼加密，因此若是字符串少於8個，則後面加0填充，若是多餘則截取前面8位。AES經過128位加密，若是字符串少於16，則後面加0填充，多餘則截取。

　　在該項目中，使用AES進行加解密。

3.3. Ks-server

　　KDC中心，主要包含Authentication Server、Ticket Granting Server。Authentication Server認證請求服務器是否合法（A請求B，KDC驗證A的合法性），服務票據請求服務（Ticket Granting Server），授予服務請求票據（經過Ticket，B能肯定A的合法性）。

 

圖 4‑3 KDC服務器監聽服務

　　監聽到Socket請求後，交由具體類進行處理。具體類由對應的對象生成器生成。經過對象生成器生成，能夠方便的替換持久化方式、加密方式、數據保存方式（該系統不依賴於Spring）。

 

圖 4‑4 生成器結構

　　經過構建者模式，生成複雜的類結構。TGT處理類生成器與TGS處理類生成器，均包含數據庫處理器生成器與序列化生成器。數據庫處理類生成器如今只實現了文件數據庫生成器、之後必定會添加數據庫數據庫生成器（將用戶名與密碼保存至數據庫）。序列化生成器，目前只包含Kryo序列化生成器。

3.3.1.    Authentication Server

　　BaseTgtProcessor類進行處理，服務端是無狀態的，每次請求過來都不須要保存信息。FirstResponse check(FirstRequest firstRequest) throws NoSuchUser方法檢查請求是否合法，並生成對應的應答信息。

 

圖 4‑5 檢查合法性及應答信息生成

3.3.2.    Ticket Granting Server

　　服務票據授予服務，A請求B的服務。KDC給A一張票據，這樣B可以確認A的合法性。

 

圖 4‑6檢查合法性及應答信息生成

3.3.3.    ServletContextListener

　　Servlet Context監聽器，在tomcat啓動的時候，也將KDC的服務啓動起來。在關閉的時候，一塊兒關閉，不須要單獨成爲一個應用程序。同時，可以在web.xml裏面配置簡單的參數。

3.4. Ks-client

　　KerberosClient接口中包含了，全部的基礎方法。詳見裏面註釋。客戶端須要保存KDC返回的各種信息，JavaBean結構以下所示：

 

圖 4‑7 客戶端javabean

 

圖 4‑8 客戶端架構

　　KerberosFacade:門面模式，簡化使用方式。一、獲取請求服務時，若是ST或者TGT還不存在，會自動請求調用。二、其餘客戶端請求時，檢查是否合法。三、請求服務返回時，檢查是否合法。

　　KerberosFacadeMemory:將ST、TGT等信息保存在內存中。

　　KerberosClient:主要負責和KDC交互

　　KerberosClientServer:其餘客戶端交互，檢查客戶端是否合法，生成應答信息。

　　FileClientDatabaseProcessor:以文件形式，保存客戶端的帳戶密碼。

　　加密方式，KDC與客戶端必須一致。咱們這裏默認使用AES加密，若是須要採用別的加密方式，須要從新實現。

 

4.  參考

http://www.roguelynn.com/words/explain-like-im-5-kerberos/

http://www.cnblogs.com/artech/archive/2011/01/24/kerberos.html