編輯:關於android開發
Kerberos協議:
Kerberos協議主要用於計算機網絡的身份鑒別(Authentication), 其特點是用戶只需輸入一次身份驗證信息就可以憑借此驗證獲得的票據(ticket-granting ticket)訪問多個服務,即SSO(Single Sign On)。由於在每個Client和Service之間建立了共享密鑰,使得該協議具有相當的安全性。
條件
先來看看Kerberos協議的前提條件:
Client與KDC, KDC與Service 在協議工作前已經有了各自的共享密鑰,並且由於協議中的消息無法穿透防火牆,這些條件就限制了Kerberos協議往往用於一個組織的內部, 使其應用場景不同於X.509 PKI。
過程
Kerberos協議分為兩個部分:
1 . Client向KDC發送自己的身份信息,KDC從Ticket Granting Service得到TGT(ticket-granting ticket), 並用協議開始前Client與KDC之間的密鑰將TGT加密回復給Client。
此時只有真正的Client才能利用它與KDC之間的密鑰將加密後的TGT解密,從而獲得TGT。
(此過程避免了Client直接向KDC發送密碼,以求通過驗證的不安全方式)
2. Client利用之前獲得的TGT向KDC請求其他Service的Ticket,從而通過其他Service的身份鑒別。
Kerberos協議的重點在於第二部分,簡介如下:
1. Client將之前獲得TGT和要請求的服務信息(服務名等)發送給KDC,KDC中的Ticket Granting Service將為Client和Service之間生成一個Session Key用於Service對Client的身份鑒別。然後KDC將這個Session Key和用戶名,用戶地址(IP),服務名,有效期, 時間戳一起包裝成一個Ticket(這些信息最終用於Service對Client的身份鑒別)發送給Service, 不過Kerberos協議並沒有直接將Ticket發送給Service,而是通過Client轉發給Service.所以有了第二步。
2. 此時KDC將剛才的Ticket轉發給Client。由於這個Ticket是要給Service的,不能讓Client看到,所以KDC用協議開始前KDC與Service之間的密鑰將Ticket加密後再發送給Client。同時為了讓Client和Service之間共享那個秘密(KDC在第一步為它們創建的Session Key), KDC用Client與它之間的密鑰將Session Key加密隨加密的Ticket一起返回給Client。
3. 為了完成Ticket的傳遞,Client將剛才收到的Ticket轉發到Service. 由於Client不知道KDC與Service之間的密鑰,所以它無法算改Ticket中的信息。同時Client將收到的Session Key解密出來,然後將自己的用戶名,用戶地址(IP)打包成Authenticator用Session Key加密也發送給Service。
4. Service 收到Ticket後利用它與KDC之間的密鑰將Ticket中的信息解密出來,從而獲得Session Key和用戶名,用戶地址(IP),服務名,有效期。然後再用Session Key將Authenticator解密從而獲得用戶名,用戶地址(IP)將其與之前Ticket中解密出來的用戶名,用戶地址(IP)做比較從而驗證Client的身份。
5. 如果Service有返回結果,將其返回給Client。
kinit is used to obtain and cache Kerberos ticket-granting tickets. This tool is similar in functionality to the kinit tool that are commonly found in other Kerberos implementations, such as SEAM and MIT Reference implementations.
The user must be registered as a principal with the Key Distribution Center (KDC) prior to running kinit.
SYNOPSIS
kinit [ commands ] <principal name> [<password>]
概括起來說Kerberos協議主要做了兩件事
1. Ticket的安全傳遞。
2. Session Key的安全發布。
再加上時間戳的使用就很大程度上的保證了用戶鑒別的安全性。並且利用Session Key,在通過鑒別之後Client和Service之間傳遞的消息也可以獲得Confidentiality(機密性), Integrity(完整性)的保證。不過由於沒有使用非對稱密鑰自然也就無法具有抗否認性,這也限制了它的應用。不過相對而言它比X.509 PKI的身份鑒別方式實施起來要簡單多了。
(注意:此流程使用了對稱加密;此流程發生在某一個Kerberos領域中;小寫字母c,d,e是客戶機發出的消息,大寫字母A,B,E,F,G,H是各個服務器發回的消息。)
首先,用戶使用客戶機(用戶自己的機器)上的程序登錄:
隨後,客戶機認證(客戶機從AS獲取票據的票據(TGT)):
然後,服務授權(客戶機從TGS獲取票據(T)):
最後,服務請求(客戶機從SS獲取服務):
缺陷
對Android的惡意吐槽(勿看,有毒) 我認為android系統中有一個特惡心人的大敗筆。就是這個大敗筆造成了android系統的卡卡卡不停。 這個大敗筆就是對ac
谷歌電子市場9--詳情界面,谷歌電子市場9-- 1.詳情頁(HomeDetailActivity) @Override protected void onCreate(
android之sharedpreference的兩種使用方法,sharedpreferencesharedPreferences的介紹: 1.sharedPrefere
Android 異步Http框架簡介和實現原理,android框架在前幾篇文章中《Android 采用get方式提交數據到服務器》《Android 采用post方式提交數