Kerberos認證原理簡介，kerberos認證原理

Kerberos認證原理簡介，kerberos認證原理

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，其組成形式為primary/instance@realm。
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