安全特性一般包括加密、認證和鑑權。

hadoop的安全認證過程很複雜，但玩大資料的人，總要知道一些基本概念、業務框架和大致業務過程。

我的博文是來自其他高手總結，加上一些書籍摘要和個人理解，彙總而成，不為其他，只為方便自己查閱。若有寫得不對的 ，請大家幫忙指正。

先澄清幾個基本概念：

安全特性一般包括加密、認證和鑑權。 hadoop的安全認證過程很複雜，但玩大資料的人，總要知道一些基本概念、業務框架和大致業務過程。 我的博文是來自其他高手總結，加上一些書籍摘要和個人理解，彙總而成，不為其他，只為方便自己查閱。若有寫得不對的 ，請大家幫忙指正。 先澄清幾個基本概念： 【關於JAAS和Java GSS-API】 （來自

https://docs.oracle.com/javase/1.5.0/docs/guide/security/jgss/tutorials/index.html） JAAS can be used for two purposes: for authentication of users, to reliably and securely determine who is currently executing Java code, and for authorization of users to ensure they have the access control rights (permissions) required to do security-sensitive operations. Java GSS-API is used for securely exchanging messages between communicating applications. The Java GSS-API contains the Java bindings for the Generic Security Services Application Program Interface (GSS-API) defined in RFC 2853. GSS-API offers application programmers uniform access to security services atop a variety of underlying security mechanisms, including Kerberos. Note: JSSE is another API that can be used for secure communication. For the differences between the two, see When to use Java GSS-API vs. JSSE. 簡單總結一下： JAAS用於使用者認證和使用者許可權，判斷其是否為一個合法賬號，是否有許可權執行當前動作； Java GSS-API用於在兩個實體之間安全的互動資訊，等同於JSSE，可以對兩個實體之間的資訊進行加密，也可以讓實體1以實體1的賬號呼叫實體2的某些業務邏輯，它也支援不需從JAAS建立的subject中獲取認證資訊，而是可以從其他渠道獲取，例如本地快取票據，但如果獲取不到，它仍會呼叫JAAS模組去獲取一個新的票據（

https://docs.oracle.com/javase/1.5.0/docs/guide/security/jgss/tutorials/BasicClientServer.html#useSub下的“The useSubjectCredsOnly System Property”章節）； JAAS和Java GSS-API可以兩者結合一起使用，也可以分開使用。 【關於kerberos】 見這個：https://docs.oracle.com/javase/1.5.0/docs/guide/security/jgss/tutorials/KerberosReq.html kerberos是一個用於認證和安全加密的機制，兩個實體之間可以通過這個機制實現安全互動。 一般我們會使用JAAS實現kerberos的認證，而使用Java GSS-API實現kerberos的加密。 【關於SASL】 SASL(Simple Authentication and Security Layer)，SASL stands for Simple Authentication and Security Layer; it's a framework that allows developers to implement different authentication mechanisms, and allows clients and servers to negotiate a mutually acceptable mechanism for each connection (rather than hard-coding or pre-configuring them). SASL僅是提供了一種協議，通過這個協議，可以在網路上的兩個節點之間互動認證和加密的相關資訊，例如，確定具體採用哪種認證機制和加密演算法；而後續如何認證和加密，已經不在SASL範疇內了。一個比較好的示意圖：

而對於SASL和GSSAPI及Kerberos的關係，可以通過如下一個對話簡單概括： （來自：https://serverfault.com/questions/139896/what-is-sasl-gssapi） Here's an example to help make this a little clearer (brutally simplified for clarity's sake): 1.Client connects to server and says, "I support SASL! How should I authenticate myself?" 2.Server receives the connection and responds, "I also support SASL, and can use these mechanisms, in descending order of 3.preference: GSSAPI, CRAM-MD5, PLAIN." 4.Client responds, "Of the choices, I'd like to use GSSAPI." 5.Server responds "GSSAPI? Capital. I support Kerberos and NTLM." ##（微軟提供的一個認證加密機制） 6.Client responds "Let's use Kerberos. Here's my encrypted ticket etc. etc."