1. Kerberos簡介
1.1. 功能
-
一個安全認證協議
-
用tickets驗證
-
避免本地保存密碼和在互聯網上傳輸密碼
-
包含一個可信任的第三方
-
使用對稱加密
-
客戶端與服務器（非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再進行驗證：
- 對比TGT中的用戶名與認證器中的用戶名
- 比較時間戳（網上有說認證器中的時間錯和TGT中的時間錯，個人覺得應該是認證器中的時間戳和系統的時間戳），不能超過一定範圍
- 檢查是否過期
- 檢查IP地址是否一致
- 檢查認證器是否已在TGS緩存中（避免應答攻擊）
- 可以在這部分添加權限認證服務
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後，進行檢查
- 對比ST中的用戶名（KDC給的）與認證器中的用戶名
- 比較時間戳（網上有說認證器中的時間錯和TGT中的時間錯，個人覺得應該是認證器中的時間戳和系統的時間戳），不能超過一定範圍
- 檢查是否過期
- 檢查IP地址是否一致
- 檢查認證器是否已在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:門面模式，簡化使用方式。1、獲取請求服務時，如果ST或者TGT還不存在，會自動請求調用。2、其他客戶端請求時，檢查是否合法。3、請求服務返回時，檢查是否合法。
KerberosFacadeMemory:將ST、TGT等信息保存在內存中。
KerberosClient:主要負責和KDC交互
KerberosClientServer:其他客戶端交互，檢查客戶端是否合法，生成應答信息。
FileClientDatabaseProcessor:以文件形式，保存客戶端的賬戶密碼。
加密方式，KDC與客戶端必須一致。我們這裏默認使用AES加密，如果需要採用別的加密方式，需要重新實現。