資訊安全越來越重要，企業裡面越來越多的開始重視資訊安全。其中在java/大資料領域很容易遇到SASL/Kerberos這些概念。比如：hadoop，kafka等常見的大資料元件。本文試圖理清楚這些概念之間的真正聯系。
Kerberos: 一種基于中心認證伺服器的中心化認證協定和架構。應用程式通路服務前需使用此架構進行登入認證，以在應用程式之間形成動态可控的受信。中心化登入伺服器稱為KDC。
GSSAPI: 在jdk中，作為對kerberos認證實作的一部分。
Krb5LoginModule: 在jdk中，負責從KDC擷取登入憑證，是kerberos認證實作的一部分。
SASL: 在jdk中定義的一種通用的基于用戶端和服務端的認證架構，GSSAPI是其實作之一。
Krb5LoginModule
為了說清楚問題，我們自底向上來看。登入kerberos，顯然要跟KDC互動，可以從網上查到這個流程的具體定義，這裡不贅述。這個登入的動作實作在com.sun.security.auth.module.Krb5LoginModule（不同的jdk-vendor可以有不同的實作）。Krb5LoginModule是一個實作了LoginModule。
LoginContext作為入口，會初始化LoginModule，預設地，它基于jaas配置檔案來執行個體化LoginModule的具體實作。jaas檔案長這個樣子：
一個名字和一對{}組成了一個Entry，可以同時寫多個Entry，隻要告訴LoginContext你要初始化哪個Entry名字即可。
為什麼說"預設基于jaas配置"呢。因為預設LoginContext是從java.security.auth.login.config指向的jaas檔案讀取Entry的。但使用者可以自己實作這種provider。
我們可以自定義實作LoginModule：JAAS LoginModule Developer's Guide
LoginContext提供login方法來登入，内部就是調用執行個體化的LoginModule來登入的。于是Krb5LoginModule作為LoginModule的實作，也是在login被調用的時候跟KDC發生互動的。
登入的成果被稱為Subject，可以了解為各種Token之類的東西的封裝。基于Subject.doAs系列方法進行授權代碼的調用。這塊是jdk一貫的API風格：
doAs這個代碼塊，我們稱為Context，其中的代碼可以利用某種機制
參考：
Java Authentication and Authorization Service (JAAS) Reference Guide
JAAS Authentication
GSSAPI
到這裡應該搞清楚了如何通過KDC拿到Subject，現在輪到GSSAPI了。登入隻是擷取了某種Token，但是Token的合法性必需通過通信雙方進行至少一次互動才能确定，這就是GSSAPI做的事情。然而，必需事先區分的是，在GSSAPI中并沒有涉及到具體的通信協定和方式！通信可以是直接通過tcp自己設計包封裝，也可以通過http遵循SPNEGO...
下面代碼都需要寫在
GSSAPI用戶端首先調用initSecContext，将得到的byte[]發給服務端（任何方式），服務端用收到的byte[]，調用acceptSecContext，将得到的byte[]發還給用戶端，用戶端再次調用initSecContext，一般到這裡就結束了。完成了認證，“交換了token”。
JDK文檔中的包含的用戶端和服務端的示例如下
https://docs.oracle.com/javas...
當用戶端和服務端都完成以後，後續的通信應該使用wrap和unwrap對資料進行“加密”後發送。
SASL
SASL作為高層次架構，定義的是一套接口，看一下接口定義，就能體會到其實GSSAPI是其中一種實作，這個事實：
換句話說，在進行基于kerberos認證的時候，既可以直接使用GSSAPI層接口，也可以使用sasl層的接口。
結論
基于本文的讨論，需要明确下面幾個概念：
kerberos的登入流程，是由LoginContet/LoginModule完成的，成果是Subject
在Subject的doAs代碼塊中，需要使用GSSAPI或SASL接口，二選其一
GSSAPI或SASL并不定義，也不實作通信，使用者代碼自己設計協定來互傳token
GSSAPI下基于http的token互傳其實就是SPNEGO協定