前言
上次的kerberos效果不錯，所以這次繼續介紹安全領域中另一個重要的協議---ldap。
ldap全稱是輕型目錄訪問協議（lightweight directory access protocol),它是一種建立在TCP/IP基礎上的應用協議 ，因爲ldap協議的特性，現在一般用於SSO單點登陸，成爲安全認證中比較常見且重要的部分。上期kerberos解決了一個域中你自己的身份強認證，ldap做的就是在另一個角度，即可以通過節點方式存儲用戶身份來進行用戶認證的工具。其實網上關於ldap的資料不算少，但大多剛理解起來也是一頭霧水，這篇文章也是先從理解的角度 幫助你知道ldap究竟是做什麼的，以及爲什麼我們會使用它，然後帶出來一些ldap的基礎知識。
值得一提的是本篇只敘述關於ldap的知識，關於其上層應用框架openldap或者apacheds，可能後期會拿一篇繼續補。
一，目錄型數據庫
首先提出一個問題，如果你的系統需要加身份認證的功能，你會怎麼做？
當然，如果不是集羣間強認證需求，你可能用不到kerberos。往往想到的是把用戶的權限信息存儲到後端數據庫中，用戶請求發送過來先從數據庫中判斷下權限認證，然後再繼續進行下去。所以這部分權限信息要如何存儲，如何制定權限信息規範，如何支持可擴展 讓多個系統可以用一套權限系統。這都是我們要面對的問題。
那爲什麼是目錄型數據庫？
目錄型數據庫是一種從關係型數據庫分離出來用於特製需求的數據庫，它的一個重要特徵是讀的次數比寫多很多。一個經典例子是電話本，我們可能經常查閱電話本，但每個人電話號碼是很少更換的，所以它的查閱次數會比寫入次數多很多，這就產生了需求我們可不可以用一個特製數據庫去存儲靜態數據，而不適合快速大量修改的數據應用場景。一方面因爲傳統關係型數據庫在大量修改的場景下，你不得不考慮一些分佈式問題，針對CAP進行設計，我們用這種目錄型特製化數據庫就變得很輕量級，而且易部署易使用，這就很好理解爲什麼ldap會是lightweight的。
另一方面，目錄型數據庫可以避免事務的操作，權限這部分完全可以在數據庫事務中分離出產生兩階段，而不需要通過一個事務進行控制，這樣也會減少對主數據庫的壓力。
當業務量上來之後，我們的目的是簡化並優化整個系統，無論是客戶端還是服務端。這就要求在一些簡單的場景下避免去使用用不到的複雜邏輯。再比如SQL是很強大的查詢語言，但在查權限這種頻繁簡單的場景下也會顯得冗餘，如果我們使用目錄型數據庫，通過一種特製化的通信協議去滿足這種簡單的需求，客戶端服務端也容易部署，是不是會解決問題呢？於是ldap就誕生了。
二，LDAP框架概念
ldap的使用普及並不是因爲它的功能有多麼強大，而是它規範了一套各種服務都可以用的模板，讓每個應用都可以輕鬆接入。
這部分我們從網絡大框架介紹到ldap的節點設計：
圖1 ldap傳輸過程
之前說過ldap是建立在tcp/ip層上的協議，當我們客戶端請求通過應用層轉發到傳輸層的過程通過調用client的api封裝，並通過tcp/ip轉發到directory server，調用後臺的目錄存儲返回認證信息。圖中展現的是一個ldap client和server以及存儲介質在網絡中的傳輸過程。
可見，ldap的設計其實是遵循了osi網絡架構的規範，在其之上實現的網絡協議，並基於一些基礎協議模型比如x.500的規範建立起的一個新網絡協議。那麼ldap究竟規範了一個怎樣的世界呢？
以下內容我會盡量中英文都有標註，概念較多有利於理解消化。
三，ldap信息模型
fig.2 一個ldap DIT的例子
ldap目錄的組織方式是一種有層次有結構的樹形結構DIT，其中條目(entry)由屬性(attribute)的一個聚集組成，並每個entry都有一個唯一性的名字引用，即專有名稱(DN)。
fig3. 在apacheds上看到的ldap一個節點的內容
由此可見，在ldap中信息以樹的形式組織，在樹狀信息中的基本數據單元是條目，而每個條目由屬性構成，屬性中存儲有屬性值。
fig.4 entry與attribute定義
由於ldap中可能條目很多，我們改動的時候會很費力，所以ldap支持ldif(LDAP Data Interchange Format )有效管理這些條目。
四，ldap命名模型
ldap中的條目中定位是每個條目都有自己的DN，DN是該條目在整個樹中的唯一名稱標識，相當於文件系統中的絕對路徑。
以下是概念總結（不限於ldap命名模型）：
DIT : ldap的樹結構，每個樹上的節點叫entry
Entry: 條目, 每個條目就是一條記錄，每個條目有自己的唯一可區別的名稱（DN）。
DN (Distinguished Name)：從特定節點到樹的根的直接下級的節點的路徑序列爲DN，區別於其他節點的名字，相當於節點的絕對路徑，由不同部分的rdn組成, 比如"uid=songtao.xu,ou=oa組,dc=example,dc=com”，一條記錄的位置（唯一）
RDN（Relative Distinguished Name): 區別於同層節點的名字叫RDN，相對辨別名，類似於文件系統中的相對路徑，它是與目錄樹結構無關的部分，如“uid=tom”或“cn= Thomas Johansson”
Attribute：每個節點屬性都有相應的value，存放在ldif文件中
objectClass: 對象類（ObjectClass）是屬性的集合，LDAP預想了很多人員組織機構中常見的對象，並將其封裝成對象類。對象類是可以繼承的，這樣父類的必須屬性也會被繼承下來。
schema: 對象類、屬性類型、語法分別約定了條目、屬性、值。這些構成了模式(Schema)，模式中的每一個元素都有唯一的OID編號
Cursor：遊標，指向查找的目前節點，有向前插入和向後插入兩種方式，通過此遊標可以存/取/刪除數據項
search scope：查詢範圍，默認有三種。baseObject：作用域僅限於由命名的條目；singleLevel：baseobject的直接子節點一層；wholeSubtree： baseObject及其所有子樹集合
其他一些常見的規範：
dc: Domain Component 域名的部分，其格式是將完整的域名分成幾部分，如域名爲example.com變成dc=example,dc=com（一條記錄的所屬位置）
uid: User Id, 用戶ID songtao.xu（一條記錄的ID）
ou: Organization Unit, 組織單位，組織單位可以包含其他各種對象（包括其他組織單元），如“oa組”（一條記錄的所屬組織）
cn: Common Name, 公共名稱，如“Thomas Johansson”（一條記錄的名稱）
sn: Surname 姓，如“許”
o: organization
值得一提的是ldap屬性中有很多是定製化的比如entryuuid，oid等特殊標識了一個節點的信息，需要通過特定的協議規範去生成。關於一些string和url格式也要符合RFC規範。
如此一來，以上的命名規範形成屬性存儲在條目中，一系列的條目繼承各不相同的objectclass擴展並整理在ldif文件中在後端存儲，訪問時通過條目的dn查詢已定義好的屬性得到想要的內容。
五，ldap功能模型與安全模型
ldap定義瞭如何去獲取或者修改條目的操作，基本上分三個類別：查找/修改/認證。在此之上我們可以直接用ldap命令（http://benjr.tw/27676）實現對條目的操作。關於安全模型，和mysql一樣，ldap後端也支持各種安全模型（無認證模式/基本認證/sasl/ssl&tls)
最後，爭議比較多的是ldap實現認證方式是否真的比http+mybatis+關係型數據庫要好也值得討論，我會在之後的系列有時間會詳細分析下，針對於ldap協議其實不存在認證方式對比性，只能說ldap提供了一種輕量級，多擴展地認證實現方式，這種方式雖然可能有點過於定製化使得前期學習門檻或者維護過高，不過不得不說解決了實際中的後端認證問題並大量應用於生產環境中，現在成爲安全認證中一種可選且不能忽視的一種方式。
參考：
1. Understanding LDAP Design and Implementation， June 2004， IBM
2. geeksforgeeks， https://www.geeksforgeeks.org/lightweight-directory-access-protocol-ldap/