Nội dung
- Dịch vụ folder là gì? - LDAP là gì? - Thành phần dữ liệu LDAP cơ bản - Xác định thành phần dữ liệu LDAP - Tổ chức dữ liệu - Kế thừa LDAP - Các biến thể giao thức LDAP - Kết luận

Thứ sáu, 29/05/2015 | 00:00 GMT+7

Hiểu giao thức LDAP, Cấu trúc phân cấp dữ liệu và các thành phần mục nhập

LDAP, hoặc Giao thức truy cập folder hạng nhẹ, là một giao thức mở được sử dụng để lưu trữ và truy xuất dữ liệu từ cấu trúc folder phân cấp. Thường được sử dụng để lưu trữ thông tin về một tổ chức và tài sản cũng như user của tổ chức đó, LDAP là một giải pháp linh hoạt để xác định bất kỳ loại thực thể nào và chất lượng của nó.

Đối với nhiều user , LDAP có vẻ khó hiểu vì nó dựa trên thuật ngữ đặc biệt, sử dụng một số từ viết tắt không phổ biến và thường được triển khai như một thành phần của hệ thống lớn hơn gồm các bộ phận tương tác. Trong hướng dẫn này, ta sẽ giới thiệu cho bạn một số kiến thức cơ bản về LDAP để bạn có nền tảng tốt để làm việc với công nghệ.

Dịch vụ folder là gì?

Dịch vụ folder được sử dụng để lưu trữ, sắp xếp và trình bày dữ liệu ở định dạng kiểu key-value . Thông thường, các folder được tối ưu hóa cho các thao tác tra cứu, tìm kiếm và đọc hơn các thao tác ghi, vì vậy chúng hoạt động cực kỳ tốt đối với dữ liệu được tham chiếu thường xuyên nhưng thay đổi không thường xuyên.

Dữ liệu được lưu trữ trong một dịch vụ folder thường có tính chất mô tả và được sử dụng để xác định chất lượng của một thực thể. Một ví dụ về một đối tượng vật lý sẽ được biểu diễn tốt trong dịch vụ folder là sổ địa chỉ. Mỗi người có thể được đại diện bởi một mục nhập trong folder , với các cặp key-value mô tả thông tin liên hệ của họ, địa điểm kinh doanh, v.v. Dịch vụ folder hữu ích trong nhiều trường hợp mà bạn muốn cung cấp thông tin mô tả, định tính có thể truy cập được.

LDAP là gì?

LDAP, hay giao thức truy cập folder nhẹ, là một giao thức truyền thông xác định các phương thức mà một dịch vụ folder có thể được truy cập. Nói một cách rộng rãi hơn, LDAP định hình cách thức mà dữ liệu trong dịch vụ folder sẽ được đại diện cho user , xác định các yêu cầu đối với các thành phần được sử dụng để tạo mục nhập dữ liệu trong dịch vụ folder và phác thảo cách mà các phần tử nguyên thủy khác nhau được sử dụng để soạn mục.

Vì LDAP là một giao thức mở nên có nhiều cách triển khai khác nhau. Dự án OpenLDAP là một trong những biến thể open-souce được hỗ trợ tốt nhất.

Thành phần dữ liệu LDAP cơ bản

Ở trên ta đã thảo luận về cách LDAP là một giao thức được sử dụng để giao tiếp với database folder để truy vấn, thêm hoặc sửa đổi thông tin. Tuy nhiên, định nghĩa đơn giản này mô tả sai sự phức tạp của các hệ thống hỗ trợ giao thức này. Cách LDAP hiển thị dữ liệu cho user phụ thuộc rất nhiều vào sự tương tác và mối quan hệ giữa một số thành phần cấu trúc xác định.

Thuộc tính

Bản thân dữ liệu trong hệ thống LDAP chủ yếu được lưu trữ trong các phần tử được gọi là thuộc tính . Các thuộc tính về cơ bản là các cặp key-value . Không giống như trong một số hệ thống khác, các khóa có tên được định nghĩa được quy định bởi các Lớp đối tượng được chọn để nhập ( ta sẽ thảo luận về điều này một chút). Hơn nữa, dữ liệu trong thuộc tính phải trùng với kiểu được xác định trong định nghĩa ban đầu của thuộc tính.

Việc đặt giá trị cho thuộc tính được thực hiện với tên thuộc tính và giá trị thuộc tính được phân tách bằng dấu hai chấm và dấu cách. Ví dụ về một thuộc tính được gọi là mail , xác định một địa chỉ email sẽ giống như sau:

mail: admin@example.com

Khi đề cập đến một thuộc tính và dữ liệu của nó (khi không đặt nó), hai bên thay vào đó được nối bằng dấu bằng:

mail=example.com

Các giá trị thuộc tính chứa hầu hết dữ liệu thực tế mà bạn muốn lưu trữ và truy cập trong hệ thống LDAP. Các phần tử khác trong LDAP được sử dụng cho cấu trúc, tổ chức, v.v.

Mục

Bản thân các thuộc tính không hữu ích lắm. Để có ý nghĩa, chúng phải được liên kết với một cái gì đó. Trong LDAP, bạn sử dụng các thuộc tính trong một mục nhập . Mục nhập về cơ bản là một tập hợp các thuộc tính dưới tên được sử dụng để mô tả một cái gì đó.

Ví dụ: bạn có thể có một mục nhập cho user trong hệ thống của bạn hoặc cho từng mục trong repository . Điều này gần giống với một hàng trong hệ thống database quan hệ hoặc một trang trong sổ địa chỉ (các thuộc tính ở đây sẽ đại diện cho các trường khác nhau trong mỗi mô hình này). Trong khi một thuộc tính xác định chất lượng hoặc đặc tính của một thứ gì đó, một mục nhập mô tả chính mặt hàng đó bằng cách chỉ cần thu thập các thuộc tính này dưới một tên.

Một mục nhập ví dụ được hiển thị trong LDIF (Định dạng trao đổi dữ liệu LDAP) sẽ trông giống như sau:

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com objectclass: person sn: Ellingwood cn: Justin Ellingwood

Ví dụ trên có thể là một mục nhập hợp lệ trong hệ thống LDAP.

DIT

Khi bạn bắt đầu làm quen với LDAP, bạn sẽ dễ dàng nhận ra rằng dữ liệu được xác định bởi các thuộc tính chỉ thể hiện một phần thông tin có sẵn về một đối tượng. Phần còn lại được tìm thấy vị trí của mục nhập trong hệ thống LDAP và các mối quan hệ mà điều này ngụ ý.

Ví dụ: nếu có thể có các mục nhập cho cả user và mục hàng tồn kho, làm thế nào để ai đó có thể phân biệt chúng? Một cách để phân biệt giữa các mục nhập thuộc các loại khác nhau là cài đặt các mối quan hệ và group . Đây phần lớn là một chức năng về nơi đặt mục nhập khi nó được tạo. Tất cả các mục nhập đều được thêm vào hệ thống LDAP dưới dạng các nhánh trên cây được gọi là Cây thông tin dữ liệu , hoặc DIT .

DIT đại diện cho một cấu trúc tổ chức tương tự như một hệ thống file trong đó mỗi mục nhập (không phải mục nhập cấp cao nhất) có chính xác một mục nhập mẹ và có thể có bất kỳ số lượng mục nhập con nào bên dưới nó. Vì các mục nhập trong cây LDAP có thể đại diện cho mọi thứ, một số mục nhập sẽ được sử dụng chủ yếu cho mục đích tổ chức, tương tự như các folder trong hệ thống file .

Bằng cách này, bạn có thể có một mục nhập cho "người" và một mục nhập cho "hàng tồn kho". Các mục dữ liệu thực tế của bạn có thể được tạo dưới dạng con của chúng để phân biệt rõ hơn loại của chúng. Các mục nhập tổ chức của bạn có thể được xác định tùy ý để thể hiện tốt nhất dữ liệu .

Trong mục nhập ví dụ ở phần cuối cùng, ta thấy một dấu hiệu của DIT trong dòng dn :

dn: sn=Ellingwood,ou=people,dc=digitalocean,dc=com

Dòng này được gọi là tên phân biệt của mục nhập (sẽ nói thêm về điều này ở phần sau) và được sử dụng để xác định mục nhập. Nó hoạt động giống như một đường dẫn đầy đủ trở lại root của DIT. Trong trường hợp này, ta có một mục nhập tên là sn=Ellingwood , mà ta đang tạo. Phụ huynh trực tiếp là một mục nhập có tên ou=people , được dùng như một containers cho các mục mô tả người. Cha mẹ của mục nhập này bắt nguồn từ domain digitalocean.com , có chức năng như root của DIT của ta .

Xác định thành phần dữ liệu LDAP

Trong phần trước, ta đã thảo luận về cách dữ liệu được biểu diễn trong hệ thống LDAP. Tuy nhiên, ta cũng phải nói về cách các thành phần lưu trữ dữ liệu được định nghĩa. Ví dụ: ta đã đề cập rằng dữ liệu phải trùng với kiểu được xác định cho từng thuộc tính. Những định nghĩa này đến từ đâu? Hãy bắt đầu lại từ dưới cùng về độ phức tạp và làm việc theo cách của ta .

Định nghĩa thuộc tính

Các thuộc tính được định nghĩa bằng cú pháp tương đối liên quan. Chúng phải chỉ ra tên cho một thuộc tính, bất kỳ tên nào khác được dùng để tham chiếu đến thuộc tính, loại dữ liệu có thể được nhập, cũng như nhiều loại metadata khác. Siêu dữ liệu này có thể mô tả thuộc tính, cho LDAP biết cách sắp xếp hoặc so sánh giá trị của thuộc tính và cho biết nó có liên quan như thế nào với các thuộc tính khác.

Ví dụ: đây là định nghĩa cho thuộc tính name :

attributetype ( 2.5.4.41 NAME 'name' DESC 'RFC4519: common supertype of name attributes'         EQUALITY caseIgnoreMatch         SUBSTR caseIgnoreSubstringsMatch         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

'name' là tên của thuộc tính. Số ở dòng đầu tiên là OID (ID đối tượng) duy nhất trên phạm vi global được gán cho thuộc tính để phân biệt nó với mọi thuộc tính khác. Phần còn lại của mục nhập xác định cách mục nhập có thể được so sánh trong khi tìm kiếm và có một con trỏ cho biết nơi tìm thông tin cho các yêu cầu kiểu dữ liệu của thuộc tính.

Một phần quan trọng của định nghĩa thuộc tính là liệu thuộc tính có thể được xác định nhiều lần trong một mục nhập hay không. Ví dụ: định nghĩa có thể xác định rằng họ chỉ có thể được xác định một lần cho mỗi mục nhập, nhưng một thuộc tính cho "cháu gái" có thể cho phép thuộc tính đó được xác định nhiều lần trong một mục nhập. Các thuộc tính là nhiều giá trị theo mặc định và phải chứa cờ SINGLE-VALUE nếu chúng chỉ có thể được đặt một lần cho mỗi mục nhập.

Định nghĩa thuộc tính phức tạp hơn nhiều so với việc sử dụng và cài đặt thuộc tính. May mắn là về phần lớn, bạn sẽ không phải xác định các thuộc tính của riêng mình vì các thuộc tính phổ biến nhất có trong hầu hết các triển khai LDAP và các thuộc tính khác có sẵn để nhập dễ dàng.

Định nghĩa ObjectClass

Các thuộc tính được thu thập trong các thực thể được gọi là objectClasses . Lớp đối tượng chỉ đơn giản là group các thuộc tính liên quan sẽ hữu ích trong việc mô tả một thứ cụ thể. Ví dụ: “person” là một objectClass.

Các mục nhập có khả năng sử dụng các thuộc tính của objectClass bằng cách đặt một thuộc tính đặc biệt gọi là objectClass , đặt tên cho objectClass mà bạn muốn sử dụng. Trên thực tế, objectClass là thuộc tính duy nhất bạn có thể đặt trong một mục nhập mà không cần chỉ định thêm objectClass.

Vì vậy, nếu bạn đang tạo một mục nhập để mô tả một người, bao gồm cả objectClass person (hoặc bất kỳ đối tượng nào cụ thể hơn. Các lớp được lấy từ người - ta sẽ đề cập đến vấn đề này sau) cho phép bạn sử dụng tất cả các thuộc tính trong objectClass đó:

dn: . . . objectClass: person

Sau đó, bạn sẽ có khả năng đặt các thuộc tính này trong mục nhập:

cn : Tên thông thường
mô tả : Mô tả mục nhập có thể đọc được của con người
seeAlso : Tham chiếu đến các mục liên quan
sn : Họ
phoneNumber : Một số điện thoại
userPassword : Mật khẩu cho user

Thuộc tính objectClass được dùng nhiều lần nếu bạn cần các thuộc tính từ các objectClass khác nhau, nhưng có những luật chỉ định những gì được chấp nhận. Các lớp đối tượng được định nghĩa là một trong một số “kiểu”.

Hai loại ObjectClass chính là cấu trúc hoặc backend . Một mục nhập phải có chính xác một lớp cấu trúc, nhưng có thể không có hoặc nhiều lớp bổ trợ được sử dụng để tăng cường các thuộc tính có sẵn cho lớp. Đối tượng cấu trúcClass được sử dụng để tạo và xác định mục nhập, trong khi đối tượng backend Classes bổ sung thêm chức năng thông qua các thuộc tính bổ sung.

Các định nghĩa của ObjectClass xác định liệu các thuộc tính mà chúng cung cấp là bắt buộc (được chỉ ra bởi một đặc tả MUST ) hay tùy chọn (được chỉ ra bởi một đặc tả MAY ). Nhiều lớp đối tượng có thể cung cấp các thuộc tính giống nhau và cách phân loại MAY hoặc MUST của thuộc tính có thể thay đổi từ lớp đối tượng này sang lớp đối tượng.

Ví dụ, person personClass được định nghĩa như sau:

objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL   MUST ( sn $ cn )   MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Đây được định nghĩa là một objectClass cấu trúc, nghĩa là nó được dùng để tạo một mục nhập. Mục tạo phải cài đặt các surname và commonname thuộc tính, và có thể chọn để cài đặt các userPassword , telephoneNumber , seeAlso , hoặc description các thuộc tính.

Lược đồ

Lần lượt, các định nghĩa ObjectClass và các định nghĩa thuộc tính được group lại với nhau trong một cấu trúc được gọi là lược đồ . Không giống như database quan hệ truyền thống, các schemas trong LDAP chỉ đơn giản là tập hợp các Lớp đối tượng và thuộc tính có liên quan. Một DIT đơn lẻ có thể có nhiều schemas khác nhau để nó có thể tạo các mục nhập và thuộc tính mà nó cần.

Các schemas thường sẽ bao gồm các định nghĩa thuộc tính bổ sung và có thể yêu cầu các thuộc tính được xác định trong các schemas khác. Ví dụ: person objectClass mà ta đã thảo luận ở trên yêu cầu thuộc tính surname hoặc sn được đặt cho bất kỳ mục nhập nào bằng cách sử dụng person objectClass. Nếu chúng không được định nghĩa trong chính server LDAP, một schemas chứa các định nghĩa này được dùng để thêm các định nghĩa này vào từ vựng của server .

Định dạng của một schemas về cơ bản chỉ là sự kết hợp của các mục trên, như sau:

. . .  objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL   MUST ( sn $ cn )   MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )  attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' )   DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )  attributetype ( 2.5.4.4 NAME ( 'cn' 'commonName' )   DESC 'RFC4519: common name(s) for which the entity is known by' SUP name )  . . .

Tổ chức dữ liệu

Ta đã đề cập đến các phần tử phổ biến được sử dụng để xây dựng các mục nhập trong hệ thống LDAP và nói về cách các khối xây dựng này được xác định trong hệ thống. Tuy nhiên, ta vẫn chưa nói nhiều về cách thông tin được tổ chức và cấu trúc trong LDAP DIT.

Đặt các mục trong DIT

DIT đơn giản là hệ thống phân cấp mô tả mối quan hệ của các giá trị đã nhập . Sau khi tạo, mỗi mục nhập mới phải “kết nối” với DIT hiện có bằng cách đặt chính nó làm phần tử con của mục nhập hiện có. Điều này tạo ra một cấu trúc giống như cây được sử dụng để xác định mối quan hệ và gán ý nghĩa.

Phần trên cùng của DIT là phân loại rộng nhất mà theo đó mỗi nút tiếp theo là con cháu. Thông thường, mục nhập cao nhất chỉ đơn giản được sử dụng làm nhãn cho biết tổ chức mà DIT được sử dụng. Các mục nhập này có thể thuộc bất kỳ Lớp đối tượng nào mong muốn, nhưng thông thường chúng được xây dựng bằng cách sử dụng các thành phần domain ( dc=example,dc=com cho thông tin quản lý LDAP được liên kết với example.com ), vị trí ( l=new_york,c=us cho tổ chức hoặc phân khúc ở NY), hoặc phân khúc tổ chức ( ou=marketing,o=Example_Co ).

Các mục nhập được sử dụng cho tổ chức (được sử dụng giống như các folder ) thường sử dụng đối tượng OrganizationUnit, cho phép sử dụng nhãn thuộc tính mô tả đơn giản được gọi là ou= . Chúng thường được sử dụng cho các danh mục chung trong mục nhập DIT cấp cao nhất (những thứ như ou=people , ou=groups và ou=inventory là phổ biến). LDAP được tối ưu hóa để tìm kiếm thông tin theo chiều dọc theo cây thay vì lên và xuống trong cây, vì vậy tốt nhất là nên giữ cho hệ thống phân cấp DIT khá nông, với các nhánh tổ chức chung và sự phân chia nhỏ hơn được chỉ ra thông qua việc gán các thuộc tính cụ thể.

Đặt tên và tham chiếu các mục trong DIT

Ta đề cập đến các mục nhập theo thuộc tính của chúng. Điều này nghĩa là mỗi mục nhập phải có một thuộc tính hoặc một group thuộc tính rõ ràng ở cấp của nó trong phân cấp DIT. Thuộc tính hoặc group thuộc tính này được gọi là tên phân biệt tương đối của mục nhập hoặc RDN và nó có chức năng giống như tên file .

Để tham chiếu đến một mục nhập một cách rõ ràng, bạn sử dụng RDN của mục nhập kết hợp với tất cả các RDN của mục nhập chính của nó. Chuỗi RDN này dẫn ngược lên đầu phân cấp DIT và cung cấp một đường dẫn rõ ràng đến mục nhập được đề cập. Ta gọi chuỗi RDN này là tên phân biệt của mục nhập hoặc DN . Bạn phải chỉ định DN cho một mục nhập trong quá trình tạo để hệ thống LDAP biết nơi đặt mục nhập mới và có thể đảm bảo RDN của mục nhập không bị mục nhập khác sử dụng.

Tương tự như vậy, bạn có thể coi RDN như một file hoặc tên folder tương đối, như bạn sẽ thấy trong hệ thống file . Mặt khác, DN tương tự hơn với đường dẫn tuyệt đối. Một khác biệt quan trọng là DNS LDAP chứa giá trị cụ thể nhất ở phía bên trái tay, trong khi đường dẫn file chứa các thông tin cụ thể nhất ở phía bên tay phải. Các DN phân tách các giá trị RDN bằng dấu phẩy.

Ví dụ: một mục nhập cho một người tên là John Smith có thể được đặt bên dưới mục nhập “Mọi người” cho một tổ chức trong example.com . Vì có thể có nhiều John Smith trong tổ chức, nên ID user có thể là lựa chọn tốt hơn cho RDN của mục nhập. Mục nhập có thể được chỉ định như thế này:

dn: uid=jsmith1,ou=People,dc=example,dc=com objectClass: inetOrgPerson cn: John Smith sn: Smith uid: jsmith1

Ta phải sử dụng objectClass inetOrgPerson để có quyền truy cập vào thuộc tính uid trong trường hợp này ( ta vẫn có quyền truy cập vào tất cả các thuộc tính được xác định trong person objectClass, như ta sẽ thấy trong phần tiếp theo).

Kế thừa LDAP

Khi nói đến nó, phần lớn cách mà dữ liệu trong hệ thống LDAP liên quan đến nhau là vấn đề phân cấp, kế thừa và lồng ghép. LDAP ban đầu có vẻ không bình thường đối với nhiều người vì nó thực hiện một số khái niệm hướng đối tượng trong thiết kế của bạn . Điều này chủ yếu đến từ việc sử dụng các lớp, như ta đã thảo luận trước đây và tính khả dụng của tính kế thừa, mà ta sẽ nói đến bây giờ.

Kế thừa ObjectClass

Mỗi objectClass là một lớp mô tả các đặc điểm của các đối tượng thuộc kiểu đó.

Tuy nhiên, không giống như kế thừa đơn giản, các đối tượng trong LDAP có thể và thường là các thể hiện của nhiều lớp (một số ngôn ngữ lập trình cung cấp chức năng tương tự thông qua đa kế thừa). Điều này là có thể vì quan niệm của LDAP về một lớp chỉ đơn giản là một tập hợp các thuộc tính mà nó PHẢI hoặc CÓ THỂ có. Điều này cho phép nhiều lớp được chỉ định cho một mục nhập (mặc dù chỉ có thể và phải có một lớp đối tượng STRUCTURAL ), dẫn đến đối tượng chỉ cần truy cập vào tập hợp các thuộc tính đã hợp nhất với khai báo MUST hoặc MAY nghiêm ngặt nhất được ưu tiên.

Theo định nghĩa của nó, một objectClass có thể xác định một objectClass cha để từ đó kế thừa các thuộc tính của nó. Điều này được thực hiện bằng cách sử dụng SUP theo sau là objectClass để kế thừa. Ví dụ, đối tượng organizationalPerson bắt đầu như thế này:

objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL  . . .

Lớp đối tượng theo sau định danh SUP là lớp đối tượng mẹ. Cha mẹ phải chia sẻ kiểu objectClass của objectClass đang được định nghĩa (ví dụ: STRUCTURAL hoặc AUXILIARY ). Đối tượng con tự động kế thừa các thuộc tính và các yêu cầu thuộc tính của cấp độ root .

Khi chỉ định một objectClass trong một mục nhập, bạn chỉ cần chỉ định con cháu cụ thể nhất của chuỗi kế thừa để có quyền truy cập vào các thuộc tính từ đầu đến cuối. Trong phần cuối cùng, ta đã sử dụng điều này để chỉ định inetOrgPerson làm lớp đối tượng duy nhất cho mục nhập John Smith của ta trong khi vẫn có quyền truy cập vào các thuộc tính được xác định trong lớp person và organizationalPerson . Hệ thống phân cấp kế thừa inetOrgPerson trông giống như sau:

inetOrgPerson -> organizationalPerson -> person -> top

Hầu hết tất cả các cây kế thừa objectClass đều kết thúc bằng một objectClass đặc biệt được gọi là “top”. Đây là một objectClass trừu tượng có mục đích duy nhất là yêu cầu bản thân objectClass đó được cài đặt . Nó được sử dụng để chỉ ra phần trên cùng của chuỗi kế thừa.

Kế thừa thuộc tính

Theo cách tương tự, bản thân các thuộc tính có thể liệt kê một thuộc tính cha trong quá trình định nghĩa của chúng. Sau đó, thuộc tính sẽ kế thừa các thuộc tính đã được đặt trong thuộc tính cha.

Điều này thường được sử dụng để tạo các version cụ thể hơn của một thuộc tính chung. Ví dụ, họ là một loại tên và có thể sử dụng tất cả các phương pháp giống nhau để so sánh và kiểm tra sự bình đẳng. Nó có thể kế thừa những phẩm chất này để có được dạng chung của thuộc tính "name". Trên thực tế, định nghĩa họ thực có thể chứa nhiều hơn một con trỏ quay lại thuộc tính cha.

Điều này rất hữu ích vì nó cho phép tạo ra một thuộc tính cụ thể hữu ích cho mọi người giải thích phần tử, ngay cả khi hình thức chung của nó không thay đổi. Sự kế thừa của thuộc tính surname mà ta đã thảo luận ở đây giúp mọi người phân biệt giữa họ và tên tổng quát hơn, nhưng ngoài ý nghĩa của giá trị, có rất ít sự khác biệt giữa họ và tên đối với hệ thống LDAP.

Các biến thể giao thức LDAP

Ta đã đề cập ở phần đầu rằng LDAP thực chất chỉ là giao thức xác định giao diện truyền thông để làm việc với các dịch vụ folder . Điều này thường được gọi là giao thức LDAP hoặc ldap.

Điều đáng nói là bạn có thể thấy một số biến thể trên định dạng thông thường:

ldap: // : Đây là giao thức LDAP cơ bản cho phép truy cập có cấu trúc vào dịch vụ folder .
ldaps: // : Biến thể này được sử dụng để chỉ LDAP qua SSL / TLS. Lưu lượng LDAP bình thường không được mã hóa, mặc dù hầu hết các triển khai LDAP đều hỗ trợ điều này. Phương pháp mã hóa kết nối LDAP này thực sự không được dùng nữa và thay vào đó, bạn nên sử dụng mã hóa STARTTLS. Nếu bạn đang vận hành LDAP qua một mạng không an toàn, bạn nên mã hóa.
ldapi: // : Điều này được sử dụng để chỉ ra LDAP qua IPC. Điều này thường được sử dụng để kết nối an toàn với hệ thống LDAP local cho các mục đích quản trị. Nó giao tiếp qua các socket bên trong thay vì sử dụng một cổng mạng tiếp xúc.

Cả ba định dạng đều sử dụng giao thức LDAP, nhưng hai định dạng cuối cùng chỉ ra thông tin bổ sung về cách nó đang được sử dụng.

Kết luận

Bạn nên hiểu khá rõ về giao thức LDAP và cách triển khai LDAP biểu thị dữ liệu cho user . Việc hiểu các yếu tố của hệ thống có liên quan với nhau như thế nào và chúng lấy thuộc tính ở đâu giúp cho việc quản lý và sử dụng hệ thống LDAP đơn giản hơn và dễ dự đoán hơn.

Tags:

Các tin liên quan