最近 hadoop 一系列軟件都給加上了 kerberos 認證，整體來說還算順利，各組件也都繼續正常工作，唯獨 storm ui，個天殺的在 windows 上打不開。
HTTP ERROR: 403
Problem accessing /index.html. Reason:
GSSException: Defective token detected (Mechanism level: GSSHeader did not find the right tag)
Powered by Jetty://
ok, 現在就需要實現能在 windows 上訪問帶有 kerberos 權限驗證的 storm ui 了。
1. 找個 kerberos 在 windows 上的實現，能 kinit 啥的
我這里找到一個 MIT 的實現. 我下載的是 64-bit MSI Installer kfw-4.1-amd64.msi, 10812k.
安裝完了它就自動的在 PATH 里面加上了自己的目錄，但是！！！ 我這里安裝的 oracle jdk 里面也帶了一些 kinit, ktab, klist 等軟件，而且我這里 jdk 的順序靠前，所以輸入 kinit 、klist 的時候
執行的其實是 jdk 里面的工具，而我沒有留心去找怎么配置 jdk 里面的，我的做法就是把 kfw 的 path 弄得靠前一點。
怎么通過 kinit 登錄就不講了吧。。
2. 配置瀏覽器
參考 http://storm.apache.org/releases/1.1.1/SECURITY.html#ui-logviewer，打開 firefox 瀏覽器 (為啥不是 chrome 及 ie 后面會講), 輸入 about:config 修改配置項 network.negotiate-auth.trusted-uris double-click 如圖
3. 驗證
配置完成后驗證一下還是要有的，使用 firefox 打開 storm ui 的地址試一下吧。
4. chrome 及 IE 目前未能測試通過。先將細節展示出來
4.1. firefox 執行流程
4.1.1 firefox 像對待普通網站一樣去訪問 storm ui 結果服務器拒絕了它並返回了 401 需要授權
4.1.2 firefox 懵了一下並攜帶密鑰再去訪問了一次 storm ui，這次 storm ui 接受了它並告訴它 cookie 是什么以及一個驗證的密鑰
4.1.3 firefox 覺得 storm ui 的密鑰是對的並非常信任他，以后訪問的時候就帶着 cookie 去請求了。
4.2 Chrome 為什么不行呢？
4.2.1 chrome 覺得自己知道 storm ui 需要 kerberos 授權，所以主動帶着不知道哪里來的 很短的 密鑰 去訪問 storm ui，storm 果斷拒絕了 chrome 的請求並返回 403.
4.2.2 over
4.3 IE 比 Chrome 好一點點，但是也是一個悲劇
4.3.1 IE 並不知道 storm ui 需要 kerberos 授權，直接就去訪問了，服務器無情的拒絕它並向它扔了一個 401 狀態碼。
4.3.2 IE 意識到需要表明自己的身份然后拿了一個非常短的密鑰串再次請求服務器並遭到拒絕，這次服務器返回了一個 403 。(chrome: 呵呵)
4.3.3 全劇終
更新：
為什么 chrome 和 IE 的 Auth 串這么短呢？
stackoverflow 上相關討論 https://stackoverflow.com/questions/5597573/how-to-find-if-ntlm-or-kerberos-is-used-from-www-authenticate-negotiate-header 里面說了， 這里貼一下精簡版：
If the Authorization token begins with "YII" then Kerberos is used, but if it begins with "TlR" then Kerberos is not used.
For example Kerberos:
Authorization: Negotiate YIIVDAYGKwYBE...
Not Kerberos:
Authorization: Negotiate TlRMTVNTUA...
所以說 chrome 和 IE 的那個串生成方式不對。。
2017/08/29 更新：
https://www.chromium.org/developers/design-documents/http-authentication 上如是說：
Negotiate external libraries
On Windows, Negotiate is implemented using the SSPI libraries and depends on code in secur32.dll.
On Android, Negotiate is implemented using an external Authentication app provided by third parties. Details are given in Writing a SPNEGO Authenticator for Chrome on Android. The AuthAndroidNegotiateAccountType policy is used to tell Chrome the Android account type provided by the app, hence letting it find the app.
On other platforms, Negotiate is implemented using the system GSSAPI libraries. The first time a Negotiate challenge is seen, Chrome tries to dlopen one of several possible shared libraries. If it is unable to find an appropriate library, Chrome remembers for the session and all Negotiate challenges are ignored for lower priority challenges.The GSSAPILibraryName policy can be used to specify the path to a GSSAPI library that Chrome should use.Otherwise, Chrome tries to dlopen/dlsym each of the following fixed names in the order specified:
- OSX: libgssapi_krb5.dylib
- Linux: libgssapi_krb5.so.2, libgssapi.so.4, libgssapi.so.2, libgssapi.so.1
Chrome OS follows the Linux behavior, but does not have a system gssapi library, so all Negotiate challenges are ignored.
- Support NTLMv2 on Mac and Linux. Our portable NTLM code supports NTLMv1 only.
- Support GSSAPI on Windows [for MIT Kerberos for Windows or Heimdal]
- Warn about Basic authentication scheme over unencrypted channels.
參考：
1. storm ui doc http://storm.apache.org/releases/1.1.1/SECURITY.html#ui-logviewer
2. mit kerberos http://web.mit.edu/kerberos/dist/index.html