前段時間，負責elk那哥們兒想把kibana調整成為ldap内部使用者認證，運維這邊了解到這個需求，着手調研。
首先kibana現在隻是用了一個叫search guard的插件來控制通路，但是這個插件需要和jira使用者統一認證，需要手動開通賬戶，維護成本高，并且實施起來的效率也很低，是以才打算搭建一個ldap伺服器，然後同步jira使用者資訊，實作kibana統一認證。 經過讨論方案，大緻的初步方案就是通過結合nginx的auth_request子產品，當使用者請求一個受特定保護的資源時候，auth_request會将請求轉發到ldap驗證服務上，然後根據驗證服務傳回的狀态碼決定重定向或者允許通路等進一步的操作。其中在nginx配置檔案中的ldap認證服務中需要完善ldap伺服器的配置資訊。大概的思路就是這樣，想到這裡的時候，又發現一個問題，如何保證ldap和jira使用者能夠及時同步呢，并且各種權限的資訊也需要相應的對接。 這時候負責jira的哥們兒，說其實我們那邊有個接口，可以通過post使用者名和密碼資訊，驗證是否能夠登入。并且驗證通過會傳回一個有關使用者資訊的json，如果想要進行權限控制的話，也可以通過這個json。是以現在事情就變得簡單了，重新簡單梳理一下解決方案。 如下： 1、使用者請求受保護的nginx反向代理資源 2、nginx的auth_request子產品将請求轉發給自己寫的django的驗證服務中。判斷cookie解密後是否正确。如果都符合條件則傳回200狀态碼，nginx不會攔截請求，而是建構一個subprocess請求受保護的本地資源。 3、如果django驗證服務沒有通過，則會傳回一個401請求，nginx對401請求進行攔截并且重定向到登入頁面，是以就傳回到django的login服務中，展示登入界面。 4、在登入界面中，輸入使用者名和密碼送出，傳到後端時，後端使用内部接口，發送使用者名和密碼，通過傳回的狀态碼驗證是否成功，成功之後将使用者名加密之後放入cookie并且重定向到受保護的資源中；驗證失敗則傳回提示使用者名或者密碼失敗。
版本選擇： nginx 1.14.1 django 1.9.13 kibana 6.5.1 python 2.7
nginx 1.4.1下載下傳位址： http://nginx.org/download/nginx-1.14.1.tar.gz requests 子產品安裝： pip install requests crypto子產品安裝： pip install crypto
安裝成功後，可分别通過nginx -v、pip show requests、pip show crypto驗證：
最開始設計後端的驗證服務時參考了nginx官網上，nginx結合ldap的身份驗證demo，demo位址： https://github.com/nginxinc/nginx-ldap-auth demo中大緻的思路就是接受請求，首次通路将會重定向到login頁面上，loging登入後，将接收到的使用者名和密碼，去查詢ldap伺服器上的資訊，成功後将把使用者名和密碼以 ; 号連接配接後做 base64 寫入 cookie，下一次通路受保護的資源時，然後寫 location 裡寫入 target 的值，來實作重定向跳回。 但是demo中首先的問題就是使用者和密碼這種敏感的資訊不應該放入cookie中，并且在demo中用到了簡單的basehttpserver ，用這個子產品就會出現幾個問題： 1、不支援url的解析和轉發，需要使用者自己解析 2、回寫的響應需要自己維護格式，容易出錯 3、沒有模闆支援，如果需要寫html頁面，也需要自己維護。 是以為了解決以上的缺點，剛好對于django有一定的了解，就打算基于django架構實作使用者驗證的服務，以及登入時模闆頁面。廢話不多說來看看代碼。代碼詳解：首先是驗證服務，通過檢查是否存在cookie，不存在的話就傳回狀态碼401；如果存在的話，通過将cookie解密，擷取其中關鍵的字段，判斷是否登入，如果解密成功的話，傳回狀态碼200，解密失敗的話，傳回狀态碼401。基于Django設計Kibana使用者認證方案
代碼詳解： 這段加密操作通過 aes 子產品進行加密，大概原理首先傳入一個 key 值，作為執行個體化 aes對象的密鑰 。然後将需要加密的文本補足成 16的倍數 進行加密操作，最後将加密後的文本 base64 進行轉換。解密的話 逆操作 即可。
代碼詳解：首先前面一部分代碼是接收前端傳來的使用者名和密碼，并且通過requests子產品post到指定的接口位址，然後解析傳回的結果，根據傳回結果的狀态碼判斷是否能登陸成功。 第二部分通過判斷登入成功後，将使用者名和登入狀态加密，設定cookie，指定逾時時間一小時，隻能由http協定傳輸。然後重定向到受保護的資源，受保護的資源就會再次請求驗證服務，驗證服務對cookie進行判斷正确後就會允許通路受保護資源；如果登入失敗則會傳回無效使用者名和密碼到登入界面。
前端登入界面：
上面就是主要的nginx配置檔案
對應django項目的urls檔案
其實這個使用者認證的解決方案不難了解，比較麻煩就是最初需求了解确定以及和其他項目負責人溝通的問題。在技術上單純的沒什麼難點。 通過在網上查資料，還有nginx官網上的一些demo有助于你迅速了解到子產品的用處，以及對一些問題的解決方案，不少網友也遇到了類似的問題，在他們身上多總結經驗，有助于自己解決問題，是以一句話“多動手，多溝通，知行合一”。 以下是我參考的一些網站和部落格，大家有興趣可以看看: nginx官網上利用auth_request結合ldap的認證方案： https://www.nginx.com/blog/nginx-plus-authenticate-users/ 用 nginx 的 auth_request 子產品內建 ldap 認證: https://www.jianshu.com/p/9f2da3cf5579 python的aes加密和解密： https://my.oschina.net/u/1458120/blog/648350