LDAP有什麼用？

對ldap最直白的解釋：

認證的煩惱

小明的公司有很多it系統，比如郵箱、svn、jenkins , jira,vpn, wifi...... 等等。

新人入職時需要在每個系統中申請一遍賬號，每個系統對使用者名稱和密碼的要求還不一樣，實在是煩人。

這還不算，按照公司的策略，這些密碼每隔三個月還得更改一次，每次都是一次大折騰。

離職的時候，各個賬號又都得刪除一遍，太折磨了。

能不能讓這些系統用同一套使用者名稱和密碼呢？申請一次，到處使用！

「嗯，這其實是乙個使用者統一認證的問題」小明做了乙個總結。

怎麼去實現？當然是開發一套系統了，關鍵是要把賬號統一起來用mysql 資料庫來保管，然後用自己擅長的springmvc對外提供json介面，別的系統比如svn想做使用者認證的時候，呼叫一下這個介面，把使用者名稱和密碼傳過來，系統就會判斷認證是否成功。

被這麼乙個美好的前景激勵著，小明像打了雞血，充滿激情地、迅速地把這個系統開發出來了。

推廣

他先找了svn的管理員，結果栽了跟頭，人家根本不買賬，理由很簡單：「你這個系統穩定性、效能怎麼樣？還有，你這介面是自己定義的，也不是業界標準，我甚至得開發**和你做整合，太麻煩。對了，你怎麼不用ldap啊？」

ldap ? 這是什麼鬼？小明沒放在心上，又去找郵箱和vpn的負責人，都被殘忍地拒絕了，甚至連理由都一樣。

最後的希望集中在jenkins身上，管理jenkins的是自己的哥們張大胖，中午吃飯的時候小明向**哭訴了自己的悲慘遭遇，希望能博得一點同情。

「我覺得你的想法很好啊，我們就缺你這樣的實幹家，你說說介面是什麼樣的？」大胖路見不平，決定為好**兩肋插刀。

「其實我這裡提供了乙個http+json的介面，你的jenkins呼叫一下就行了」小明滿懷期望。

「這個.... 雖然我沒有仔細研究過，但是jenkins 好像只支援自定義的使用者認證，還沒有ldap。」大胖的刀還沒拔出來就放回去了。

看來推廣又要失敗了。

ldap

「這個ldap是什麼東西，你們的系統為什麼都要支援它？」小明憤憤不平地問道。

「ldap是lightweight directory access protocol ，即輕量級目錄訪問協議，用這個協議可以訪問提供目錄服務的產品，例如openldap。」

「目錄服務？」

「對，比如公司有個員工列表名單，對於乙個員工，你能查到他的**，工位，部門等各種資訊，這就是乙個目錄啊。」

「聽起來很適合儲存乙個公司員工的賬號和密碼啊」小明說。

「是啊，這個目錄服務啊，儲存資料的方式有點特殊，完全不像我們熟知的關聯式資料庫，資料都在表中，一行一行的，一目了然，這個openldap是以樹的方式儲存的。比如乙個人的資訊是這樣的：

小明說：「有點古怪，不過這很像檔案系統的目錄樹，每個目錄都有屬性，可以儲存資訊，比如使用者名稱和秘密，但是查詢的時候還得一層一層的來，多麻煩，為啥不用關係型資料庫，直接乙個select 不就出來了」

張大胖說：「我對ldap研究不深，但是我知道ldap速度快，非常快，比當今最快的資料庫還要快。「

「怎麼可能，現在的關聯式資料庫多強悍啊。」

「其實ldap主要的應用場景是查詢多而修改極少，查詢和修改的比率是10:1 甚至更高，那就充分發揮ldap的優勢了，因為沒有事務處理，那資料庫的速度可是比不上。還有ldap能儲存海量的資料，還可以輕鬆地在各個系統之間複製，可用性超高。」

小明想想確實是這樣，公司員工資訊變化本來就很少，我們把使用者名稱密碼存進去，三個月才改一次，查詢的操作遠遠高於修改，如果ldap專注於優化查詢，又沒有事務處理，就像乙個快取一樣，肯定要更快了，怪不得很多軟體都支援ldap做使用者認證，這是個重要原因啊。

小明有點沮喪，覺得自己在沒有充分調查研究的情況下，又造了乙個輪子。

既然如此，那就搭建乙個支援ldap的目錄伺服器吧，小明這一次吸取了教訓，先說服了領導，在領導的支援下，進行了跨部門的溝通，經過艱苦的努力，各個系統終於搞成了統一認證，現在的結構是這樣的：

小明的努力沒有白費，除了學到技術外，還得到了公司的認可，年底的時候給他發了乙個領導力的獎，獎勵他勇於走出自己的工作崗位、跨部門的與同事溝通，用自己的專業能力帶來大家完成了使用者的統一認證，極大提高了工作的效率。