在過去幾天中，我已經使用GSS-API和SPNEGO構建了概念驗證演示。其目的是讓用戶通過Http RESTful Web服務單點登錄我們定製應用服務器提供的服務。SPNEGO：成功的談判和身份驗證後的後續調用
持有有效Kerberos票據授予票據（TGT）的用戶可以調用啓用SPNEGO的Web服務，客戶端和服務器將協商， 用戶將通過身份驗證（由Kerberos和應用程序級別），並且將（在成功認證時）在他的票證緩存中爲我的服務負責人提供服務票據。
這可以很好地使用CURL與--negotiate標誌作爲測試客戶端。
第一次通過CURL發出一個正常的HTTP請求，沒有特殊的標題。服務器拒絕此請求， 向響應頭添加「WWW-Authenticate：Negotiate」，表示協商。 CURL然後從KDC獲得一個服務票據，併發出第二個請求，這次是Negotiate +請求頭中包裝好的服務票據（NegTokenInit） 服務器然後解開票據，驗證用戶和（如果驗證是成功）執行所請求的服務（例如登錄）。
問題是，從客戶端到服務器的後續服務調用會發生什麼？ 客戶端現在擁有一個有效的Kerberos服務票據，但使用SPNEGO通過CURL進行的其他呼叫也會生成上述相同的兩個通行證。
在我看來，我有很多的選擇：
1）每一個服務調用重複整整2通SPNEGO談判（如CURL一樣）。 雖然這可能是最簡單的選擇，但理論上至少在理論上會有一些開銷：客戶端和服務器都在創建和拆除GSS上下文，並且該請求在網絡上發送兩次，對於GET可能不錯，對於員額，討論以下問題：
Why does the Authorization line change for every firefox request?
Why Firefox keeps negotiating kerberos service tickets?
不過是架空*明顯在現實生活中？我猜測只有性能測試纔會說明。
2）第一次呼叫使用SPNEGO協商。一旦成功認證，後續調用使用應用程序級別認證。 這似乎是Websphere Application Server採用的方法，它使用輕量級第三方認證（LTPA）安全性令牌進行後續調用。
最初，這似乎有點不可思議。在成功地談過Kerberos可以使用之後，爲什麼會回到其他的東西呢？另一方面，如果GSS-API/SPNEGO可能會導致明顯的開銷/性能損失，則此方法可能有效。
3）第一次呼叫使用SPNEGO協商。一旦成功通過認證和信任，後續調用將使用GSS-API Kerberos。 在這種情況下，我不妨做下面的選項4）。
4）轉儲SPNEGO，使用「純」GSS-API Kerberos。 我可以通過自定義的Http頭或cookie來交換Kerberos票據。
是否有最佳做法？
作爲背景：客戶端和服務器應用程序都在我的控制之下，兩者都在java中實現，並且我都知道「說」Kerberos。 我選擇SPNEGO作爲概念驗證的「一個開始的地方」，並且幫助我進入了Kerberos和Single Sign On的世界，但這並不是一個硬性要求。
概念證明運行在帶有FreeIPA的OEL Linux服務器上（因爲這是我在地下城裏的），但可能的應用程序將是Windows/Active Directory。
*或顯著相比其他性能因素，如數據庫，XML的使用VS JSON的消息體等
**如果在未來，我們希望允許基於瀏覽器的訪問網絡服務，那麼SPNEGO將是最好的選擇。
FYI這是爲Hadoop生態系統的一個現實的問題，因爲Kerberos是爲了再次驗證服務1月1主機，在主機5800不是5個SVCS ......他們實現了什麼（一）RPC調用，委託令牌_ （種MD5散列的同伴SVC主機之間共享）_和（b）爲REST調用和用戶界面，一個簽名餅乾_（除WebHDFS使用了STD令牌）_ –
這是所有開源的，所以你可以檢查他們的代碼 - 而JIRA則詳細解釋了「簽名cookie」的基本原理，並提出異議/論證等。 （我認爲這是有關保護與SPNEGO YARN UI ...） –
或者，你甚至可以安裝霍頓或Cloudera的Hadoop的沙箱，啓用Kerberos內部SVCS，也爲用戶界面，並看到捲曲和朋友發生了什麼_（除了針對WebHDFS - 請參閱上文）_ –