1.1 What is Kerberos

1.1.1 簡單介紹
　　Kerberos是一個用於鑒定身份（authentication）的協議， 它采取對稱密鑰加密（symmetric-key cryptography），這意味著密鑰不會在網絡上傳輸。在Kerberos中，未加密的密碼（unencrypted password）不會在網絡上傳輸，因此攻擊者無法通過嗅探網絡來偷取用戶的密碼。

　　Kerberos利用對稱加密和受信任的第三方（即KDC, key distribution center）來鑒別要求使用網絡服務的用戶的身份。所有有KDC和secondary KDC管理的主機構成了一個域（realm）。

　　當一個用戶的身份通過了KDC的驗證後，KDC會向該用戶發送一個證書/票據（該證書/票據是與這次會話綁定的），其他kerberized services會在該用戶的主機上搜索該ticket，而不是要求用戶使用密碼來驗證他的身份。
1.1.2 關於Kerberos的一些概念
Principal
一個用戶會以一個獨一無二的身份來被KDC認證，該身份被稱為principal。一個Principal由三個部分組成：primary, instance以及realm，[email protected]
primary : 可以是OS中的username，也可以是service name；
instance : 用於區分屬於同一個user或者service的多個principals，該項為optional；
realm : 類似於DNS中的domain，定義了一組principals
1.1.3 認證過程
　　1、當用戶在一個kerberos-aware網絡中登錄到他的workstation之後，authentication server將向KDC發送一個TGT請求（a request for a ticket-granting ticket），而他的principal將作為其中的組成部分。該請求可以由登錄程序來負責發送（這樣該過程對用戶透明），也可以在用戶登錄後通過執行kinit來發送。

　　2、KDC在其數據庫中檢查該pricipal。

　　3、如果找到了該principal，則KDC將創建一個TGT，並用user key進行加密，然後將加密後的TGT發送給該用戶。這裏，user key並不是用戶的密碼，而是由用戶密碼計算而來（例如hash）。

　　4、用戶所在主機的Kerberos client的登錄程序或者kinit程序在收到加密的TGT後，用該用戶的user key進行解密。user key只會在client主機上被使用，絕不會在網絡上傳輸。KDC發送的ticket將被保存在一個本地文件中（credentials cache），它可以被kerberized services查驗。

　　5、用戶的身份驗證完成後，servers（運行著kerberized applciations & services）可以查驗被識別的principals及其keys（這將被保存在keytab中），而不必用kinit來查驗。

　　TGT有一個可設定的失效期（通常為10~24小時），這會被保存在client所在主機的credential cache中。在ticket過期之前，用戶在請求kerberized services的服務時不需要再次輸入用戶密碼，除非他們登出後再登錄。

　　每當用戶需要訪問一個network service時，client會利用TGT向TGS（ticket-granting server）請求獲得針對該特定網絡服務的一個新的ticket。之後，用戶可以利用該service ticket來向該network service實現authentication。
1.1.4 How Kerberos works
　　KDC就是受信任的第三方（trusted third party arbitrator），KDC上運行著2個重要的Kerberos daemons，即 kadmind 和 krb5kdc。
　　Kadmind: 這是管理Kerberos server的進程，一個名為kadmin 的程序使用 kadmind 來維護principal database和policy configuration。
　　Krb5kdc: 在Kerberos authentication的過程中擔負trusted third party arbitrator的職責。

1.2 認證原理
1.2.1 知識準備
　　為了使讀者更加容易理解，在這裏我們先給出兩個重要的概念：
　　? Long-term Key/Master Key：在Security的領域中，有的Key可能長期內保持不
變，比如你在密碼，可能幾年都不曾改變，這樣的Key、以及由此派生的Key被稱為Long-term Key。對於Long-term Key的使用有這樣的原則：被Long-term Key加密的數據不應該在網絡上傳輸。原因很簡單，一旦這些被Long-term Key加密的數據包被惡意的網絡監聽者截獲，在原則上，只要有充足的時間，他是可以通過計算獲得你用於加密的Long-term Key的——任何加密算法都不可能做到絕對保密。

　　在一般情況下，對於一個Account來說，密碼往往僅僅限於該Account的所有者知曉，甚至對於任何Domain的Administrator，密碼仍然應該是保密的。但是密碼卻又是證明身份的憑據，所以必須通過基於你密碼的派生的信息來證明用戶的真實身份，在這種情況下，一般將你的密碼進行Hash運算得到一個Hash code, 我們一般管這樣的Hash Code叫做Master Key。由於Hash Algorithm是不可逆的，同時保證密碼和Master Key是一一對應的，這樣既保證了你密碼的保密性，又同時保證你的Master Key和密碼本身在證明你身份的時候具有相同的效力。
　　? Short-term Key/Session Key：由於被Long-term Key加密的數據包不能用於網絡傳送，所以我們使用另一種Short-term Key來加密需要進行網絡傳輸的數據。由於這種Key只在一段時間內有效，即使被加密的數據包被黑客截獲，等他把Key計算出來的時候，這個Key早就已經過期了。
1.2.2 認證詳細原理
　　Kerberos實際上一個基於Ticket的認證方式。Client想要獲取Server端的資源，先得通過Server的認證；而認證的先決條件是Client向Server提供從KDC獲得的一個有Server的Master Key進行加密的Session Ticket（Session Key + Client Info）。可以這麽說，Session Ticket是Client進入Server領域的一張門票。而這張門票必須從一個合法的Ticket頒發機構獲得，這個頒發機構就是Client和Server雙方信任的KDC，同時這張Ticket具有超強的防偽標識：它是被Server的Master Key加密的。對Client來說，獲得Session Ticket是整個認證過程中最為關鍵的部分。
　　為了更好的說明整個Ticket Distribution的過程，我在這裏做一個類比。現在的股事很火爆，上海基本上是全民炒股，我就舉一個認股權證的例子。有的上市公司在股票配股、增發、基金擴募、股份減持等情況會向公眾發行認股權證，認股權證的持有人可以憑借這個權證認購一定數量的該公司股票，認股權證是一種具有看漲期權的金融衍生產品。
而我們今天所講的Client獲得Ticket的過程也和通過認股權證購買股票的過程類似。如果我們把Client提供給Server進行認證的Ticket比作股票的話，那麽Client在從KDC那邊獲得Ticket之前，需要先獲得這個Ticket的認購權證，這個認購權證在Kerberos中被稱為TGT：Ticket Granting Ticket，TGT的分發方仍然是KDC。
我們現在來看看Client是如何從KDC處獲得TGT的：首先Client向KDC發起對TGT的申請，申請的內容大致可以這樣表示：“我需要一張TGT用以申請獲取用以訪問所有Server的Ticket”。KDC在收到該申請請求後，生成一個用於該Client和KDC進行安全通信的Session Key（SKDC-Client）。為了保證該Session Key僅供該Client和自己使用，KDC使用Client的Master Key和自己的Master Key對生成的Session Key進行加密，從而獲得兩個加密的SKDC-Client的Copy。對於後者，隨SKDC-Client一起被加密的還包含以後用於鑒定Client身份的關於Client的一些信息。最後KDC將這兩份Copy一並發送給Client。這裏有一點需要註意的是：為了免去KDC對於基於不同Client的Session Key進行維護的麻煩，就像Server不會保存Session Key（SServer-Client）一樣，KDC也不會去保存這個Session Key（SKDC-Client），而選擇完全靠Client自己提供的方式。

　　通過上面的過程，Client實際上獲得了兩組信息：一個通過自己Master Key加密的Session Key，另一個被Sever的Master Key加密的數據包，包含Session Key和關於自己的一些確認信息。

　　Client通過自己的Master Key對KDC加密的Session Key進行解密從而獲得Session Key，隨後創建Authenticator（Client Info + Timestamp）並用Session Key對其加密。最後連同從KDC獲得的、被Server的Master Key加密過的數據包（Client Info + Session Key）一並發送到Server端。我們把通過Server的Master Key加密過的數據包稱為Session Ticket。
　　當Server接收到這兩組數據後，先使用他自己的Master Key對Session Ticket進行解密，從而獲得Session Key。隨後使用該Session Key解密Authenticator，通過比較Authenticator中的Client Info和Session Ticket中的Client Info從而實現對Client的認證。

1.2.3kafka認證過程
　　總結起來也很簡單，Broker啟動時，需要使用配置文件中的身份和密鑰文件向KDC（Kerberos服務器）認證，認證通過則加入Kafka集群，否則報錯退出。
Producer（或Consumer）啟動後需要經過如下步驟與Broker建立安全的Socket連接：
　　1.Producer向KDC認證身份，通過則得到TGT（票證請求票證），否則報錯退出
　　2.Producer使用TGT向KDC請求Kafka服務，KDC驗證TGT並向Producer返回SessionKey（會話密鑰）和ServiceTicket（服務票證）
　　3.Producer使用SessionKey和ServiceTicket與Broker建立連接，Broker使用自身的密鑰解密ServiceTicket，獲得與Producer通信的SessionKey，然後使用SessionKey驗證Producer的身份，通過則建立連接，否則拒絕連接。

轉載：http://www.cnblogs.com/xiaodf/p/5968086.html

Kerberos認證原理簡介