LDAP (phần 2)

Chương II: CẤU TRÚC & PHƯƠNG THỨC HOẠT ĐỘNG LDAP

2.1 Tổng quan về kiến trúc LDAP

LDAP định nghĩa nội dung thông điệp trao đổi giữa client LDAP và server LDAP. Client gửi các yêu cầu (tìm kiếm, chỉnh sửa, xóa) cung ứng cho server và server định dạng kiểu dữ liệu trong thông điệp này. Thông điệp của LDAP được thiết lập trên tầng TCP/IP, giao thức này cũng định hướng thiết lập kết nối hoặc ngắt kết nối giữa client và server.

Tuy vậy, LDAP nó không phải là cấu trúc của nhiều liên kết gửi nhận. nó tập trung xác định thông điệp, loại dữ liệu, cấu trúc tổ chức thư mục, thông tin được bảo vệ như thế nào .v.v..

Tóm lại LDAP là một chuẩn mở rộng của giao thức truy cập thư mục  hay là 1 client LDAP và server để giao tiếp với nhau.

Dưới đây là bản tóm tắt quá trình giao nhận của LDAP client à server:

-          Client khởi tạo phiên kết nối với server. Điều này được hiểu như là kết nối tới server. Client lúc này cần xác định tên (hoặc địa chỉ  IP) và port của server để kết nối.

-          Client cần cung cấp username và password để chứng thực với server hoặc client cũng có thể kết nối ẩn danh với mặc định cho phép truy cập. Client và server cũng  thiết lập các phiên kết nối  sử dụng các phương pháp bảo mật mạnh mẽ như kết nối dữ liệu.

-          Sau khi kết nối thành công client có thể thực hiện các thao tác trên thư mục như là đọc và update. Điều này cho phép ta quản lý và truy vấn  thông tin thư mục.

-          Khi hoàn thành kết nối thì client sẻ đóng phiên giao dịch này với server, lúc này ngắt kết nối.

Trong thư viện API LDAP chúng ta tìm ra nó rất đơn giản. Điều này có nghĩa hỗ trợ thêm các thư mục hiện tại cho các ứng dụng với chi phí thấp. LDAP ban đầu cũng dự định thay thế cho chuẩn truy cập thư mục X.500, các kho chứa thư mục và cấu trúc tổ chức thư mục gọi là entry. Một entry nhập thư mục thường mô tả một người, một thiết bị, địa điểm. Mỗi Entry có một tên phân biệt (Distinguished Name - DN) xác định duy nhất. DN bao gồm trình tự các bộ phận được gọi là (Relative Distinguished Names - RDNs) tên liên hệ đặc biệt, nó giống như tên của một đường dẫn truy cập vào cây thư mục trong hệ điều hành Windows và Unix.

Các mục này có thể sắp xếp thành phân cấp cây thư mục giống như cấu trúc dựa theo tên phân biệt của nó. Cái này được gọi là cây thông tin thư mục (Directory Information Tree - DIT).

Mỗi mục chứa một hay nhiều thuộc tính thư mục nhập. Mỗi thuộc tính có một loại giá trị.

LDAP hoạt động truy cập và chỉnh sửa thư mục như:

-          Ràng buộc và không ràng buộc.

-          Tìm kiếm các thư mục người dùng chỉ định.

-          Thêm thư mục.

-          Xóa thư mục.

-          Sửa đổi thư mục.

-          Di chuyển thư mục.

-          So sánh thư mục

Máy chủ  thư mục hiện đại sử dụng là  LDAPv3. LDAPv3 được mô tả trong các RFC của IETF. Các khóa LDAPv3 được sử dụng dưới đây là mô tả ngắn cái nhìn tổng quan về tài liệu kiến trúc LDAP.

RFC 2251 Lightweight Directory Access Protocol (v3)

Mô tả giao thức LDAP được thế kế và truy cập nhanh hỗ trợ mô hình X.500. Các giao thức truy cập nhỏ hỗ trợ trong môi trường nhỏ như là trình duyệt hoặc máy tính để bàn nhỏ.

RFC này là một trong RFC cốt lõi của LDAP. Nó mô tả đặt tên mục là nhưng thế nào với các tên phân biệt. Xác định và định dạng trao đổi giữa client và server, liệt kê các hoạt động được định dạng bởi client. Xác định sử dụng các kí tự UTF-8. RFC qui định cụ thể thư mục có thể đọc được để client có thể xác định loại đối tượng trong cây thư mục. Nó định nghĩa như thế nào nếu client kết nối với máy chủ khác không chưa thông tin mà nó yêu cầu. Nó mô tả cách thức hoạt động cá nhân có thể mở rộng bằng cách điều khiển và phần bổ sung này có thể được xác định bằng cách mở rộng. Nó cũng thảo luận với client làm sao xác thực được với server. Tùy chọn sử dụng các xác thực đơn giản (SASL) để cho phép bổ sung cơ chế xác thực.

RFC 2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions.

LDAP sử dụng các chuỗi octet làm đại diện cho các thuộc tính để truyền giao thức trong LDAP. RFC định nghĩa giá trị nguyên, đảm bảo thời gian, địa chỉ mail và thông số nó đại diện. Ví dụ: số nguyên 123 được đại diện bởi chuỗi “123”. Những định nghĩa này gọi là thuộc tính cú pháp. RFC này mô tả thế nào là 1 thuộc tính với cú pháp như số điện thoại được mã hóa. Nó cụng xác định giá trị có ứng với nguyên tắc tìm kiếm, nó cũng được sử dụng trong trường hơp so sánh các chuỗi trong các trường hợp không quan trọng.

Những thuộc tính cú pháp này được sử dụng xây dựng và mô tả các thuộc tính trong một lớp

RFC 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names

Những loại thuộc tính và cú pháp này sử dụng xây dưng sơ  đồ miêu tả thay đổi tên đối tượng (DNs) là một định danh duy nhất, đôi khi được gọi là khóa chính. Các thư mục X.500 sử dung ASN.1 để mã khóa phân biệt tên LDAP mã hóa và phân biệt tên theo chuỗi. đại diện một chuỗi này dễ dàng mã hóa và giải mã cũng như con người có thể đọc được. DN gồm các chuổi các tên tương đối phân biệt (RDNs) cách nhau bằng dấu “,”.Trình tự của RDNs là một DN cha của một entry thư mục vào thư mục gốc của DIT. RDN mổi bao gồm mỗi giá trị thuộc tính từ 1 thư mục.

Ví dụ các DN cn=Van Dien, ou = 12HTH, o= HUTECH, c = VN. đại diên cho các entry thư mục một  người  tên gọi chung là (cn) Van Dien thuộc đơn vị (ou) 12HTH, trong tổ chức (o)HUTECH  trong Nước (c ) VN.

RFC 2254 The String Representation of LDAP Search Filters

Bộ lọc LDAP cung cấp mạnh mẽ cơ chế tìm kiếm của thư mục  cho mục phù hợp với tiêu chí tìm kiếm cụ thể. Các giao thức LDAP đại diên cho mạng lọc tìm kiếm. Tài liệu này xác định làm thế nào lọc số người có thể đọc được. Các chương trình đại diện có thể sử dụng  hoặc mã nguồn chương trình để xác định tiêu chí tìm kiếm. Thuộc tính giá trị được so sánh sử dụng hoạt động giống nhau, tăng lên hoặc giống như âm thanh cho phù hợp với khoảng thời gian hoặc ngữ âm. Các toán tử tìm kiếm để xây dựng bộ lọc tìm kiếm phức tạp hơn.

Ví dụ sau đâu là thuật toán lọc tìm kiếm cho các mục có tên “Van” hoặc thuộc tính phổ biến bắt đầu bằng “Va”

RFC 2255 The LDAP URL Format

Uniform Resource Locators (URLs) dùng để tìm kiếm các trang web, các tập tin, các nguồn lực khác nhau trên internet. URL LDAP xác định tìm kiếm LDAP tại 1 máy chủ LDAP cụ thể. Một URL LDAP đại diên kết quả cho một đường dẫn  trả về trong quá trình tìm kiếm.

RFC 2256 A Summary of the X.500(96) User Schema for use with LDAPv3

Sơ đồ thuộc tính truy cập của client được  đã sớm được định dạng bởi X.500. RFC cung cấp tổng quan loại thuộc tính và lớp đối tượng mà các server LDAP có thể nhận biết

Các RFC được liệt kê ở trên xây dựng cốt lõi LDAPv3 đặc điểm kỹ thuật. LDAP dễ hiểu hơn ta có thể dựa vào 4 bước sau:

-          Thông tin: mô tả cấu trúc  kho lưu trữ thông tin trong thư mục LDAP

-          Tên: mô tả thông tin về tên tổ chức và định dạng

-          Chức năng: mô tả hoạt động có thể thực hiện trên thông tin lưu trữ của cây LDAP

-          Bảo mật: mô tả thông tin cây thư mục LDAP được bảo vệ chống lại sự xâm nhập trái phép

2.2  Mô hình thông tin (LDAP information model)

Các đơn vị cơ bản của một thông tin được lưu trữ  trong thư mục được gọi là entry. Entry đại diện cho các mối quan tâm trong thế giới thực như con người, máy chủ, tổ chức. Tập hợp các thuộc tính chưa thông tin về đối tượng, mỗi thuộc tính có 1 hoặc nhiều giá trị cú pháp quy định cụ thể loại đối tượng  nào có thể lưu trữ.

Hình 4.  Entry thuộc tính và giá trị của nó

Ngoài việc xác định dữ liệu có thể lưu trữ như giá trị của một thuộc tính, cú pháp cũng xác định thuộc tính xử lý như thế nào trong quá trình tìm kiếm và hoạt động của các thư mục khác.

Ví dụ cú pháp xác định số điện thoại

Thứ tự các ký tự, trường hợp khoảng trắng và gạch ngang được bỏ qua trong quá trình so sánh, giá trị phải là một chuỗi các ký tự. Cho ví dụ khi bạn sử dụng các tên sau thì nó vẫn ra kết quả giống nhau:

            090-888-9999

            090888-9999

            090 888 9999

Bảng 2.1 Một vài thuộc tính cú pháp

Cú pháp	Mô tả
Bin	Thông tin nhị phân
Ces	Còn gọi là trường hợp thư mục chuỗi trường hợp này có ý nghĩa trong so sánh
Cis	Trường hợp này không đáng kể so sánh
Tel	Số điện thoại các ký tự khoảng tráng gạch ngang đều được bỏ qua
DN	Tên phân biệt
Generalized Time	Ngày, tháng, năm đại diện cho chuỗi thời gian
Postal Address	Địa chỉ phân cách nhau bằng ký tự “$”

Bảng 2.2 liệt kê các thuộc tính phổ biến. một số thuộc tính bí danh mà nó dữ dụng được bất kì nơi đâu.

Ví dụ CN được đề cập tới tên thường dùng (common name) của thuộc tính

Bảng 2.2

Thuộc tính, Bí danh	Cú pháp	Mô tả	Ví dụ
Common name, cn	Cis	Tên thường dùng của entry	John Smith
Surname, sn	Cis	Họ của một người	Smith
TelephoneNumber	Tel	Số điện thoại	090-888-9999
OrganizationalUnit Name, ou	Cis	Tên của một tổ chức	12HTH06
Owner	Dn	DN của người sở hữu entry	cn=John Smith,o=HUTECH,c=vn
Organization, o	Cis	Tên của một tổ chức	HUTECH
jpegPhoto	Bin	Đinh dang hình ảnh jpeg	Hình của John Smith

Chúng ta có thể hạn chế số lượng các giá trị  mà có thể lưu trữ của một thuộc tính sẽ làm hạn chế kích thước của một giá trị.

Shemas xác định các đối tưỡng được lưu trữ trong thư mục. Shemas cũng liệt kê thuộc tính của từng loại đối tượng và xem nó là thuộc tính yêu cầu hay tự chọn. Ví dụ Shema của một người, họ “surname” sn là thuộc tính cần thiết. Nhưng mô tả thuộc tính tùy chọn. Schema kiểm tra tất cả các thuộc tính cần thiết của một entry đầy đủ trước khi lưu trữ nó cũng kiểm tra thuộc tính nào  không được lưu trữ trong entry, thuộc tính tùy chọn cũng có thể nhập vào bất kỳ lúc nào. Shema cũng xác định tính kế thừa lớp con của đối tượng nơi đối tượng được lưu trữ (DIT)

Bảng 2.3 liệt kê các Shema thông thường. Trong nhiều trường hợp một mục nhiều hơn một đối tượng.

Lớp đối tượng	Mô tả	Thuộc tính yêu cầu
InetOrgPerson	Xác định entry cho một người	Tên thường dùng (cn) “Surname” họ (sn) Objectclass
organizationalUnit	Định dạng entry cho một bô phận  trong tổ chức	Ou Objectclass
organization	Định dạng entry cho một tổ chức	O Objectclass

Mặc dù mỗi máy chủ có shema riêng nhưng nó vẫn  tuân theo chuẩn (refer to RFC 2252, Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, and RFC 2256, A Summary of the X.500(96) User Schemas for use with LDAPv3).

Thông tin mô tả dữ liệu được lưu trữ theo cấu trúc trong tập tin *.ldif. Cấu trúc file Ldif sẽ được giới thiệu ở phần dưới.

2.2.1 LDIF

Khi LDAP chạy lần đầu tiên hoặc nhiều cái entry cùng thay đổi cùng một thời điểm thì ta không dể dàng thay đổi. Với mục đích này LDAP hỗ trợ LDAP Data Interchange Format (LDIF) để thuận tiện trong việc quản lý dữ liệu. Nó giúp chúng ta thao tác dể dàng  hơn.

Xem ví dụ các form cơ bản của  một entry LDIF

form cơ bản của LDAP entry:

dn: <distinguished name>

<attrtype> : <attrvalue>

<attrtype> : <attrvalue>

………

Dòng này sẽ tiếp tục đến dòng tiếp theo bởi khoảng trắng hoặc phím tab, cho ví dụ:

dn: cn=John E Doe, o=University of Higher

learning, c=US

Nhiều thuộc tính được ghi ở các dòng riêng biệt. Ví dụ:

            cn: John E Doe

            cn =John Doe

Nếu giá trị là bản mã  non-US-ASCII hoặc bắt đầu với khoảng trắng và dấu (: ) thì sau dấu (:: ) được mã hóa chuẩn base-64. Ví dụ ký tự bắt đầu với khoảng trắng được mã hóa như sau:

cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=

Nhiều cái entry trong cùng một file LDIF được ngăn cách bởi dòng trắng. Nhiều dòng trắng được coi là kết thức một file.

Ví dụ 2.2 cho thấy file LDIF cơ bản  chứa các  organizational unit, People, nội bộ bên dưới cây thư mục DIT  ibm.com . Entry John Smith  chỉ sữ liệu cho entry people, tiếp theo đơn vị tổ chức là Marketting . lưu ý John là nhân viên phòng marketing. Cặp giá trị thuộc tính ou: marketing

-------------------------------------------------------------------------------------------

dn: o=ibm.com

objectclass: top

objectclass: organization

o: ibm.com

dn: ou=People, o=ibm.com

objectclass: organizationalUnit

ou: people

dn: ou=marketing, o=ibm.com

objectclass: organizationalUnit

ou: marketing

dn: cn=John Smith, ou=people, o=ibm.com

objectclass: top

objectclass: organizationalPerson

cn: John Smith

sn: Smith

givenname: John

uid: jsmith

ou: marketing

ou: people

telephonenumber: 838-6004

Một số các thuộc tính cơ bản trong file Ldif:

STT	Tên	Mô tả
1	dn	Distinguished Name : tên gọi phân biệt
2	c	country – 2 kí tự viết tắt tên của một nước
3	o	organization – tổ chức
4	ou	organization unit – đơn vị tổ chức
5	objectClass	Mỗi giá trị objectClass hoạt động như một khuôn mẫu cho các dữ liệu được lưu giữ trong một entry. Nó định nghĩa một bộ các thuộc tính phải được trình bày trong entry (Ví dụ : entry này có giá trị của thuộc tính objectClass là eperson, mà trong eperson có quy định cần có các thuộc tính là tên, email, uid ,…thì entry này sẽ có các thuộc tính đó), còn bộ các thuộc tính tùy chọn có thể có hoặc có thể không có mặt.
6	givenName	tên
7	uid	id người dùng
8	cn	common name – tên thường gọi
9	telephoneNumber	số điện thoại
10	sn	surname – họ
11	userPassword	mật khẩu người dùng
12	mail	địa chỉ email
13	facsimileTelephoneNumber	số phách
14	createTimestamp	thời gian tạo ra entry này
15	creatorsName	tên người tạo ra entry này
16	pwdChangedTime	thời gian thay đổi mật khẩu
17	entryUUID	id của entry

2.2.2 LDAP Shema

Objectclasses

Lớp đối tượng là  thuật ngữ được LDAP biểu thị bởi đối tượng được đại diện bởi entry  thư mục hoặc bản lưu. Một số loại đối tượng  điển hình là người, đơn vị tổ chức, tổ chức  thành phần domain và nhóm của tên đó. Nó xác định quan hệ của lớp đối tượng này với lớp đối tượng khác. Giống như lớp Này có thể có các đối tượng cấp dưới giống cây phân cấp. Chú ý một số lớp đối tượng trong LDAP có thể kết nối được với nhau.

Ví dụ: lớp đơn vị tổ chức (object organizational) nó cũng thường định nghĩa như lớp đối tượng cha bởi vì nó chứa các đối tượng bên dưới nó.

Các lớp đối tượng này được khai báo một cách trừu tượng, các lớp đối tượng này thường được dùng để làm mẫu cho các đối tượng khác. Thư mục entry được tạo từ cấu trúc của đối tượng . lớp đối tượng bổ sung không thể tự tạo chính nó như là thư mục Entry: nó có thể đính kém vào thư mục Entry được khởi tạo từ lớp khối tượng. Các lớp đối tượng cung cấp phương pháp mở rộng thêm thêm lớp đối tượng mà không cấu tạo sơ đồ của 1 lớp cấu trúc.

Lớp đối tượng LDAP được định dạng  thuộc tính chuẩn được liệt kê nhưng phải chưa các thuộc tính bắt buộc và chưa cá thuộc tính tùy chọn. Các lớp đối tượng khác nhau qui định các thuộc tính trùng lặp hoặc  dự phòng cho lớp đối tượng khác. Trong thực tế LDAP thường sử dụng nhiều lớp đối tượng  để xác định thư mục entry. Hầu hết các lớp đối tượng này được thừa kế từ các lớp đối tượng cao cấp khác. Xem LDAP được định nghĩa với các lớp đối tượng khác ở ví dụ 2.3

Ví dụ 2.3 định nghĩa lớp cho LDAP.

Objectclass : top

Objectclass: person

Objectclass: organizatianol Person

Objectclass: inetOrgPerson

Objectclass: eDominoAccount

Thứ tự hiển thị trên cho thấy thứ bậc mối quan hệ  của các lớp đối tượng nhưng không nhất thiêt. Đối tượng lớp trên dĩ nhiên là lớp phân quyền. Hầu hết các lớp này không phụ thuộc vào lớp khác nhưng nó luôn phải phụ thuộc  vào lớp trên nó. Không phải tất cả thư mục của LDAP khi người sử dụng thì nó  gắn lớp đối tượng cao nhất cho họ mà  Khi một ai đó yêu cầu  nó truy cập vào danh sách điều khiển(ACLs) trên lớp đối tượng. lớp person phụ thuộc vào lớp đầu tiên có các thuộc tính phổ biến  và nó yêu cầu CN(tên thường gọi) và sn(họ), nó cũng cho phép các thuộc tính tùy chọn. lớp organizationalPerson được thừa kế lớp person. lớp inetOrgPerson thừa kế của lớp   organizationalPerson. Bây giờ phần khó khan nhất: lớp eDominoAccount phụ thuộc vào lớp trên cùng , nó yêu cầu  sn và userid thuộc tính phổ biến. Lưu ý điều này trùng lặp với lớp Person cũng yêu cầu thuộc tính sn: “điều này có nghĩa chúng ta phải lưu sn 2 lần phải không? câu trả lời là không! đây chỉ là thuộc tính cơ bản, chúng ta sẽ nói tiếp nó ở phần sau.”

Các phương pháp xác định lớp đối tượng cho  V3 LDAP được mô tả RFC 2251 và RFC 2252 Ví dụ 2-4 cho thấy  các đối tượng được thưc hiện từ ITDS:

Ví dụ 2-4  Một vài ITDS dịnh nghĩa lớp đối tượng

objectclass: top

objectclasses=( 2.5.6.0 NAME 'top' DESC 'Standard ObjectClass' ABSTRACT MUST (

objectClass ) )

objectclass: person

objectclasses=( 2.5.6.6 NAME 'person' DESC 'Defines entries that generically

represent people.' SUP 'top' STRUCTURAL MUST ( cn $ sn ) MAY ( userPassword $

telephoneNumber $ seeAlso $ description ) )

objectclass: organizationalPerson

objectclasses=( 2.5.6.7 NAME 'organizationalPerson' DESC 'Defines entries for

people employed by or associated with an organization.' SUP 'person' STRUCTURAL

MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $

preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $

internationalISDNNumber $ facsimileTelephoneNumber $ street $ postalAddress $

postalCode $ postOfficeBox $ physicalDeliveryOfficeName $ ou $ st $ l ) )

objectclass: inetOrgPerson

objectclasses=( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'Defines

entries representing people in an organizations enterprise network.' SUP

'organizationalPerson' STRUCTURAL MAY ( audio $ businessCategory $ carLicense $

departmentNumber $ employeeNumber $ employeeType $ givenName $ homePhone $

homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile

$ pager $ photo $ preferredLanguage $ roomNumber $ secretary $ uid $

userCertificate $ userSMIMECertificate $ x500UniqueIdentifier $ displayName $ o

$ userPKCS12 ) )

  Chú ý mổi lớp đối tượng được  bắt đầu với 1 chuỗi con số giới hạn bởi số thập phân. Con số này được gọi là OID. Sau OID là lớp đối tượng (NAME) theo sau 1 mô tả DESC. Nếu nó là cấp dưới lớp đối tượng khác(SUP) lớp trên đối tượng được liệt kê. Cuối cùng định nghĩa các đối tượng này cần phải có nhưng thuộc tính bắt nuộc(MUST) và tùy chọn (MAY).

OID là chuổi số để nhận diện đối tượng. OIDs là quản lý phân cấp được qui định bởi một tổ chức Quốc tế (ISO - Web site http://www.iso.ch/) và tổ chức viển thông quốc tế (ITU - Web site http://www.itu.ch/). ISO và ITU  quản lý  OID của các tổ chức bằng cách gắn cho họ số OID. Tổ chức có thể tự gắn OIDs cho các tổ chức khác.OIDs được liên kết  với các đối tượng trong giao thức và cấu trúc dữ liệu  được ký hiệu bằng cú pháp trừu tượng(ASN.1)

OID là chuẩn chung qui định toàn cầu, nó được hình thánh bằng cách lấy một  số chuỗi (ví dụ : 1.3.4.7.4.17.1, 1.3.4.7.4.17.2, 1.3.4.7.4.17.3, v.v.v.) tổ chức có thể có chi nhánh từ thư mục gốc hay đỉnh  của cây OID. Một chi nhánh như vậy có thể gọi là một vòng cung. Tổ chức có thể mổ rộng vòng cung này bằng cách tạo ra OIDs.

Nếu bạn có thư muc LDAP  cho một trường đại học( nhiều mã nguồn mỡ hay bản thương mại  thư mục LDAP) . các lớp đối tượng sẽ kết thúc với “.oc”

Ví dụ 2.5

1 (ISO-assigned OID)

1.3 (ISO-identified organization)

1.3.18 (IBM)

1.3.18.0 (IBM Objects)

1.3.18.0.2 (IBM Distributed Directory)

Như  bạn đã biết dấu chấm lần đầu tiên được sử dụng bởi IETF  cho điạ  chỉ IP cũng như OIDs để mọi thứ đơn giản , tuy nhiên không giống như đại chỉ IP, OID không  có giới hạn độ dài. Nếu tổ chức định dạng thuộc tính thư mục sở hữu bên trong nó , bạn cần phải xem xet số mà doanh nhiệp có để gắn thuộc tính cho nó. Chúng ta không nên cấp lại cái mã số mới Vì khi cấp lại sẽ không tương thức với tổ chức(hoặc LDAP của nhà cung cấp sản phẩm). Điều này không nói nên được cái OID arc mà bạn được cấp từ ISO, IANA hoặc 1 số công ty khác , OID  là định nghĩa của riêng bạn, các lớp thuôc tính đối tượng sẽ đảm bảo khả năng tương tác. Nó sẽ ngăn cản  bạn sử dụng OIDs mà bạn đã gắn hoặc do ngưới khác gán.   OIDs sử dũng đẳng thức tính toán. Nó gồm hai đối tượng ( ví dụ: thuộc tính thư mục hoặc chứng nhận chính sách) được coi là như nhau nếu nó có  OID giống nhau. ở đây nó không tự điều hướng  hoặc phân cấp với OIDs( không giống địa chỉ IP). Ví dụ: trong  trường hợp chúng ta không tìm ra người sở hữu  OID, OIDs liên quan v.v… Lúc này OIDs tồn tại để cung cấp một định danh duy nhất. không ai ngăn được 2 tổ chức khác nhau  đặt tên các tổ chức giống nhau mà họ quản lý. Tuy nhiên OIDs cung cấp cho họ duy nhất mốt số (arc) mà không trùng với tổ chức nào. Nếu bạn quan tâm đến việc số  (arc) cho tổ chức riêng của bạn thì các bạn có thể  đăng kí miễn phí tại website: http://www.iana.org/cgi-bin/enterprise.pl.

Để biết thêm thông tin về OIDs , cây và số được gắn và các câu hỏi thường gặp bạn nên bắt đầu với ASN.1 vào link đây: http://asn1.elibel.tm.fr/oid/faq.htm

2.3 Mô hình đặt tên (LDAP naming model)

Mô hình đặt tên LDAP dùng để xác định tên của một tổ chức. Entry được tổ chức trong một cấu trúc cây  được gọi là cây thư mục thông  tin (DIT). Entry bố trí  trên DIT dựa vào tên  phân biệt của chúng(DN).DN là một tên duy nhất rõ ràng xác định một entry duy nhất. DNs được tạo thánh từ 1 chuỗi của những tên phân biệt(RDNs).

Mỗi RDN trong DN tương ứng  với một nhánh của DIT từ đầu cho tới Root của thư mục entry trong DIT. Mỗi RDN đều bắt nguồn từ huộc tính của entry . Trong trường hợp đơn giản phổ biến. một RDN có dạng <attribute name> = <value> .DN  được tạo bởi 1 chuỗi các RDNS cách nhau bằng dấu phẩy.

Ví dụ một DIT được hiển thị trong hình 2-2. Là ví dụ rất cơ bản nhưng sử dụng để minh họa một số khái niệm cơ bản. Mỗi ô đều đại diện cho một thư mục entry . root trong entry là một khái niệm nhưng nó không thật sự tồn tại.

Hình 2.2  Cây thông tin (DIT)

Các tổ chức của entry trong DIT  bị hạn chế định nghĩa lớp đối tượng tương ứng. entry được đặt tên theo vị trí của nó trong DIT. Mục cuối cùng của cây DN cn= john smith, ou=people,o=ibm,c=us, các tổ chức của nhóm người ngày đã có DN của ou=people,o=ibm,c=us.

2.3.1 LDAP distinguished name syntax (DNs)

Các Entry trong LDAP được định dạng bởi tên chúng, các kí tự của tên thường là:

-          Chúng có 2 form: tên đại diện và URL

-          Nó có cú pháp giống nhau

-          Ranh giới không gian tên là không rõ ràng

Một thành phần của tên được gọi là tên phân biệt RDN. Một RDN đại diện cho 1 điểm trong hệ thống phân cấp tên . RDN khác nhau bởi giấu (,). Một RDN là 1 loại .RDNs là 1 loại type=value cho 1 giá trị RDNs, và dấu (+) được sử dụng để tạo ra nhiều đối tượng.

RDNS: type = value+type=value

Type có trường hợp và value được xác định trong cú pháp cụ thể . thứ tự trong RDNs  trong tên LDAP là trường hợp  RDN cụ thể  đầu tiên,  một ít trường hợp Cho phép RDNs di chuyển trên cây phân cấp DIT  . một loạt RDNs tương đương với tên phân biệt. DN được sử dụng đại diện cho một đối tượng hoặc một đường dẫn đến đối tưỡng trong không gian cây phân cấp. URL định dạng cho LDAP đã được đĩnh nghĩa DN như thành phần của URL. Các hình thức được giải thích phần tiếp theo.

Mổi thư mục entry đều có DN. DN đại diện duy nhất cho một thư mục  entry .DN được tạo lên từ các giá trị thuộc tính cách nhau bởi dấu phẩy (,).

Ví Dụ: cn=Roger Smith,ou=sales,o=ib,c=US

   cn=Sandy Brown,ou=marketing,o=ibm,c=US

   cn=Leslie Jones,ou=development,o=ibm,c=US

Bất kể các thuộc tính được định nghĩa trong lựơc đồ quan hệ có thể được sử dụng để tạo một DN. Thứ tự của các thành phần thuộc tính này là quan trọng . Các DN được chứa trong thành phần của mỗi cấp độ của hệ thống phân cấp thư mục từ root tới entry. LDAP DNs bắt đầu với hầu hết với các thuộc tính( thường được sắp xếp trong tên) và tiếp tục dần dần thuộc tính rộng hơn thường kết thúc với thuộc tính một đất nước. thành phần đầu tiên của DN được gọi là RDN. Nó xác định mục rõ ràng phân biết với các thư mục khác cùng cấp( chung thư mục cha).

2.3.2 String form

Cú pháp chính xác cho các tên được định nghĩa trong RFC 2253. Thay vì nhân đôi văn bản RFC, sau đây là là những ví dụ tên phân biệt  được viết cuối form:

-          cn=Leslie Smith, ou=Austin, o=IBM đây là thuộc tính chứa 3 quan hệ của tên phân biệt (RDNs)

-          ou=deptUVZS + cn=Leslie Smith, ou=Austin, o=IBM dya65 là RDNs mà tên đầu tiên chưa nhiều giá trị

-          cn=L. Eagle, o=Sue\, Grabbit and Runn, c=GB ví dụ này cho ta thấy một dấu phẩy(bằng cách sử dụng dấu gạnh huyền \ để thoát kí tự) trong một tên của  tổ chức.

-          cn=Before\0DAfter,o=Test,c=GB , cái ví dụ này  tên chứa giá trị trả về (ODH)

-          sn=Lu\C4\8Di\C4\87 , đại diên cho 1 RDN 5 chữ cái( bao gồm các kí tự ASCII)

Đối với định nghĩa chi tiết về DNS dưới dạng một chuỗi, hãy tham khảo RFC 2253. Thông tin thêm về Unicode ký tự mã hóa (superset của ISO 10646) và chuyển sang hoạt động . UTF-8 có thể được tìm thấy tại http://www.unicode.org và trong RFC 2279.

2.3.3 URL form

Định dạng URL LDAP có dạng chung ldap://<host>:<port>/<path>, đường dẩn <path> được định dạng  <dn>[?<attributes>[?<scope>?<filter>]]

<dn> là 1 tên phân biệt của 1 chuổi LDAP bằng cách sử dụng 1 chuổi đại diện . các thuộc tính này phải trả về các entry hay các thư mục entry cấp trên . nếu bỏ qua các thuộc tính trả về  <scope> quy định cụ thể phạm vi tìm kiếm được thực hiện. Scope có thể có dòng entry one-levels( dòng entry  con). Hoặc toàn bộ nhánh(subtree).<filter> Qui định cụ thể bộ lọc tìm kiếm . áp dụng vào các entry trong phạm vi q1uy định tìm kiếm . các định dạng URL cho phép khác hàng internet sử dụng trình duyệt truy cập đến giao thức  LDAP và thư mục LDAP.

Ví dụ LDAP URLs là:

-          ldap://austin.ibm.com/ou=Austin,o=IBM

Các URL tương ứng cung cấp các tìm kiếm đối tượng cơ bản <ou=Austin, o=IBM> entry  sử dụng lọc <of objectClass=*> yêu cầu tất cả các thuộc tính (if bộ lọc bỏ qua, một bộ lọc của  <objectClass=*> giả thiết theo định nghĩa.

-          ldap://austin.ibm.com/o=IBM?postalAddress

Đây là LDAP URL đề cập thuộc tính  địa chỉ của entry IBM

2.4 Mô hình chức năng (Functional model)

Mô hình chức năng LDAP bao gồm ba loại hoạt động mà có thể được thực hiện đối với một dịch vụ thư mục LDAPv3:

-          Authentication: Bind, Unbind, and Abandon dùng để kết nối hoạt ngắt kết nối với LDAP server, thiết lập cho phép  truy cập, và bảo vệ thông tin.

-          Query:  Tìm kiếm và so sánh các thư mục theo quy định của người dùng.

-          Update: thêm, xóa, định dạng thư mục  hoặc sữa đổi tên phân biệt  (  modifyRDN) hoặc tên phân biệt của một entry

2.4.1 Query

Sử dụng phổ biến trong các hoạt động tìm kiếm. các hoạt động tìm kiếm linh hoạt có có tùy chọn phức tạp nhất.

Các hoạt động tìm kiếm cho phép một client yêu cầu một server tìm kiếm LDAP thông qua một số phần của DIT cho thông tin cuộc họp các tiêu chí người dùng quy định để đọc và danh sách các kết quả.Không có hoạt động riêng biệt để đọc và danh sách, họ được kết hợp trong chức năng tìm kiếm. Việc tìm kiếm có thể là rất chung chung hoặc rất cụ thể. Các hoạt động tìm kiếm cho phép một để xác định điểm khởi đầu trong DIT, làm thế nào sâu trong DIT để tìm kiếm, những gì thuộc tính một mục phải có để được coi là một trận đấu, và những gì thuộc tính để trả lại cho các mục phù hợp.

Một số ví dụ tìm kiếm bày tỏ chính thức bằng tiếng Anh là:

-          Tìm địa chỉ bưu điện cho cn = John Smith, o = IBM, c = DE.

-          Tìm tất cả các mục mà là con của mục ou = ITSO, o = IBM, c = US.

-          Tìm địa chỉ e-mail và số điện thoại của bất cứ ai trong IBM có tên cuối cùng chứa các ký tự "cối xay" và ai cũng có một số fax.

Để thực hiện tìm kiếm, các thông số sau phải được xác định:

-          Căn cứ: ADN xác định điểm khởi đầu, được gọi là các đối tượng cơ bản, tìm kiếm. Các đối tượng cơ bản là một nút trong DIT.

-          Phạm vi: Chỉ cách sâu bên trong DIT để tìm kiếm từ các đối tượng cơ sở. Có ba lựa chọn: baseObject, singleLevel, và wholeSubtree. Nếu baseObject được quy định, chỉ có các đối tượng cơ sở được kiểm tra. Nếu singleLevel được quy định, chỉ có con ngay lập tức của đối tượng cơ sở được kiểm tra, các đối tượng cơ sở chính nó là không kiểm tra. Nếu wholeSubtree được quy định, các đối tượng cơ sở và tất cả các con cháu của nó được kiểm tra.

-          Tìm kiếm bộ lọc: Chỉ định một mục tiêu phải phù hợp để được trả lại từ một tìm kiếm. Bộ lọc tìm kiếm là một sự kết hợp Boolean khẳng định giá trị thuộc tính. Một sự khẳng định giá trị thuộc tính kiểm tra giá trị của một thuộc tính bình đẳng, ít hơn hoặc bằng, và như vậy. Ví dụ, một bộ lọc tìm kiếm có thể xác định các mục có chung một tên có chứa "con sói" hay thuộc tổ chức ITSO.

-          Các thuộc tính để trở lại: Chỉ định thuộc tính để lấy từ mục phù hợp với tiêu chí tìm kiếm. Kể từ khi nhập cảnh có thể có nhiều thuộc tính, điều này cho phép người dùng chỉ nhìn thấy các thuộc tính họ đang quan tâm Thông thường, người dùng quan tâm đến giá trị của các thuộc tính. Tuy nhiên, nó có thể chỉ có các loại thuộc tính và giá trị của họ không quay trở lại. Điều này có thể hữu ích nếu một giá trị lớn như một bức ảnh JPEG là không cần thiết cho tất cả các mục trở về từ tìm kiếm, nhưng một số các hình ảnh sẽ được tải về sau khi cần thiết.

-          Bí danh dereferencing: Chỉ định nếu bí danh là dereferenced-có nghĩa là, nếu sự tham gia bí danh chính nó hoặc nhập nó chỉ để được sử dụng. Bí danh có thể được dereferenced hay không khi định vị các đối tượng cơ bản và / hoặc khi tìm kiếm được các đối tượng cơ sở. Nếu bí danh được dereferenced, sau đó họ là những cái tên thay thế cho các đối tượng quan tâm trong các thư mục. Không dereferencing bí danh cho phép các mục bí danh chính mình để được kiểm tra.

-          Giới hạn: tìm kiếm có thể là rất chung chung, kiểm tra subtrees lớn và gây ra nhiều mục để được trả lại. Người sử dụng có thể xác định thời gian và kích thước giới hạn để ngăn chặn tìm kiếm bất thường từ tốn quá nhiều tài nguyên. Giới hạn kích thước hạn chế số lượng các mục trở về từ tìm kiếm. Thời hạn giới hạn tổng thời gian của việc tìm kiếm. Các máy chủ có thể tự do áp đặt các hạn chế nghiêm ngặt hơn theo yêu cầu của khách hàng.

2.4.2 Giới thiệu tham gia và tài liệu tham khảo tiếp tục

Nếu các máy chủ không có các đối tượng cơ bản, nó sẽ trở lại giới thiệu đến một máy chủ mà không, nếu có thể. Sau khi các đối tượng cơ sở được tìm thấy tìm kiếm singleLevel và wholeSubtree có thể gặp phải giới thiệu khác. Những giới thiệu được trả về trong kết quả tìm kiếm cùng với mục phù hợp khác. Những giới thiệu được gọi là tài liệu tham khảo tiếp tục bởi vì họ chỉ ra nơi tìm kiếm có thể được tiếp tục. Ví dụ, khi tìm kiếm một cây con cho bất cứ ai tên là Smith, một tham chiếu tiếp tục đến máy chủ khác có thể được trả lại, có thể cùng với một số mục phù hợp khác. Nó không được bảo đảm rằng một mục nhập cho ai đó tên là Smith thực sự tồn tại ở máy chủ đó, chỉ có các điểm tham chiếu tiếp tục với một cây con có thể có như vậy một mục. Đó là vào các khách hàng để tiếp tục theo tài liệu tham khảo nếu muốn. Vì chỉ có LDAP Phiên bản 3 quy định cụ thể giới thiệu, tài liệu tham khảo tiếp tục không được hỗ trợ trong phiên bản trước đó.

2.4.3 Tìm kiếm bộ lọc cú pháp

Bộ lọc tìm kiếm xác định tiêu chí mà một mục phải phù hợp để được trả lại từ một tìm kiếm. Thành phần cơ bản của một bộ lọc tìm kiếm là một sự khẳng định giá trị thuộc tính có dạng:

attribute operator value (giá trị nhà điều hành thuộc tính)

Ví dụ, để tìm kiếm một người tên là John Smith tìm kiếm bộ lọc sẽ là cn = John Smith. Trong trường hợp này, cn là thuộc tính, = là các nhà điều hành, và John Smith là giá trị. Bộ lọc tìm kiếm này phù hợp với mục với tên gọi chung John Smith. Bảng 2-5 cho thấy các tùy chọn bộ lọc tìm kiếm.

Bảng 2-5 Tìm kiếm tùy chọn bộ lọc

Điều hành	Mô tả	Ví dụ
=	Trả mục có thuộc tính bằng giá trị.	cn = John Smith tìm entry với tên chung John Smith.
>=	Trả mục có thuộc tính là lớn hơn hoặc bằng giá trị.	sn>= Smith tìm thấy tất cả các mục từ Smith đến z *.
<=	Trả mục có thuộc tính là nhỏ hơn hoặc bằng giá trị.	sn<= Smith tìm thấy tất cả các mục từ * đến smith.
=*	Trả mục có giá trị thiết lập cho thuộc tính đó.	sn=* tìm thấy tất cả các mục có thuộc tính sn.
~=	Trả mục có giá trị thuộc tính khoảng phù hợp với giá trị quy định. Thông thường, đây là một thuật toán phù hợp với từ mà âm thanh như nhau.	sn~= Smit có thể tìm thấy mục "sn = Smith".

* Các nhân vật phù hợp với bất kỳ chuỗi và có thể được sử dụng với các nhà điều hành =. Ví dụ, cn=J*Smi* sẽ phù hợp với John Smith và Jan Smitty.

Bộ lọc tìm kiếm có thể được kết hợp với toán tử Boolean để tạo bộ lọc tìm kiếm phức tạp hơn. Cú pháp để kết hợp các bộ lọc tìm kiếm là: ("&" hoặc "|" (filter1) (filter2) (filter3) ...) ((lọc) "!")

Các toán tử được liệt kê trong Bảng 2-6

Bảng 2-6 toán tử

Toán tử	Mô tả
&	Trả về mục phù hợp với tất cả các tiêu chuẩn lọc được chỉ định.
|	Trả về mục phù hợp với một hoặc nhiều tiêu chí lọc.
!	Trả về mục mà bộ lọc là không đúng sự thật. Điều hành này chỉ có thể được áp dụng cho một bộ lọc duy nhất. (! (lọc)) là hợp lệ, nhưng (! (filter1) (filter2)) không phải.

Ví dụ, (| (sn = Smith) (sn = Miller)) phù hợp với mục với cái tên Smith hay họ Miller. Các toán tử cũng có thể được lồng vào nhau như trong (| (sn = Smith) (& (ou = Austin) (sn = Miller))), mà phù hợp với bất kỳ mục với cái tên Smith hay với cái tên Miller cũng có đơn vị tổ chức thuộc tính Austin.

2.4.4 So sánh

Hoạt động so sánh so sánh một mục nhập cho một giá trị thuộc tính. Nếu sự tham gia có giá trị, so sánh lợi nhuận TRUE. Nếu không, so sánh trả về FALSE. Mặc dù so sánh đơn giản hơn một tìm kiếm, nó là gần như giống như một tìm kiếm phạm vi cơ bản với một bộ lọc tìm kiếm của thuộc tính = giá trị. Sự khác biệt là nếu sự tham gia không có ở tất cả các thuộc tính (thuộc tính là không có), việc tìm kiếm sẽ trở lại không được tìm thấy. Điều này là không thể phân biệt với trường hợp nhập chính nó không tồn tại. Mặt khác, so sánh sẽ return false. Điều này cho thấy rằng các mục không tồn tại, nhưng không có một thuộc tính phù hợp với các giá trị quy định.

2.4.5 Cập nhật hoạt động

Cập nhật các hoạt động sửa đổi các nội dung của thư mục. Bảng 2-7 tóm tắt các hoạt động cập nhật

Bảng 2-7 Cập nhật hoạt động

Hoạt động	Mô tả
Add (thêm)	Chèn các mục mới vào thư mục.
Delete (xóa)	Xóa các mục hiện có từ các thư mục. Chỉ có các nút lá có thể bị xóa. Bí danh không được giải quyết khi xóa.
Modify (sửa đổi)	Thay đổi các thuộc tính và giá trị chứa trong một mục hiện có. Cho phép các thuộc tính mới được thêm vào và các thuộc tính hiện có để được xóa hoặc sửa đổi.
Modify DN (sửa đổi DN)	Thay đổi các thành phần ít quan trọng nhất (trái nhất) của một DN hoặc di chuyển một cây con của mục đến một vị trí mới trong DIT. Mục không thể được di chuyển qua các biên giới máy chủ.

2.4.6 Hoạt động xác thực

Các hoạt động xác thực được sử dụng để thiết lập và kết thúc một phiên làm việc giữa một khách hàng LDAP và một máy chủ LDAP. Phiên có thể được bảo đảm ở mức độ khác nhau, từ một phiên vô danh không an toàn, một phiên chứng thực trong đó khách hàng xác định mình bằng cách cung cấp một mật khẩu, để an toàn, phiên mã hóa sử dụng cơ chế SASL. SASL đã được thêm vào trong LDAP Phiên bản 3 để khắc phục những yếu kém trong thực LDAP Phiên bản 2. Bảng 2-8 tóm tắt các hoạt động xác thực.

Bảng 2-8 hoạt động xác thực

Hoạt động	Mô tả
Bind (ràng buộc)	Bắt đầu một phiên LDAP giữa client và server. Cho phép khách hàng để chứng minh danh tính của mình bằng cách chứng thực chính nó vào máy chủ.
Unbind (không ràng buộc)	Chấm dứt một phiên client / server.
Abandon (bỏ)	Cho phép client yêu cầu server từ bỏ một hoạt động nổi bật.

2.4.7  Điều khiển và các hoạt động mở rộng

Điều khiển và các hoạt động mở rộng cho phép các giao thức LDAP được mở rộng mà không thay đổi giao thức riêng của mình. Điều khiển thay đổi hành vi của một hoạt động, và các hoạt động mở rộng thêm hoạt động mới cho các giao thức LDAP. Danh sách các điều khiển và các phần mở rộng hỗ trợ bởi một máy chủ LDAP có thể thu được bằng cách kiểm tra DSE gốc của máy chủ đó. Điều khiển có thể được xác định để mở rộng hoạt động nào.

Điều khiển được thêm vào cuối của giao thức tin nhắn của hoạt động. Họ được cung cấp như các thông số chức năng trong các API.

Một điều khiển có một chấm thập phân chuỗi đối tượng ID được sử dụng để xác định sự kiểm soát, một giá trị kiểm soát ngẫu nhiên chứa các thông số để kiểm soát, và một mức tới hạn. Nếu mức tới hạn là đúng, máy chủ phải tôn trọng sự kiểm soát, hoặc nếu máy chủ không hỗ trợ kiểm soát, loại bỏ toàn bộ hoạt động. Nếu mức tới hạn là FALSE, một máy chủ không hỗ trợ việc kiểm soát phải thực hiện các hoạt động như thể không có kiểm soát theo quy định. Ví dụ, một điều khiển có thể mở rộng các hoạt động xóa bằng cách gây ra một hồ sơ kiểm toán của xóa được ghi nhận vào một tập tin được chỉ định bởi các thông tin giá trị kiểm soát.

Một hoạt động mở rộng cho phép một hoạt động hoàn toàn mới được xác định. Thông điệp hoạt động giao thức mở rộng bao gồm một số thập phân chấm chuỗi đối tượng ID được sử dụng để xác định các hoạt động mở rộng và một chuỗi tùy ý của dữ liệu hoạt động cụ thể.

2.5 Mô hình an ninh

Các mô hình bảo mật dựa trên các hoạt động ràng buộc. Có các hoạt động liên kết khác nhau có thể, và do đó các cơ chế an ninh được áp dụng là khác nhau là tốt. Một khả năng là khi một khách hàng yêu cầu truy cập cung cấp một DN tự xác định nó cùng với một mật khẩu văn bản rõ ràng đơn giản. Nếu không DN và mật khẩu được khai báo, một phiên vô danh là giả định của máy chủ LDAP. Việc sử dụng các mật khẩu văn bản rõ ràng là mạnh mẽ khuyến khích khi dịch vụ vận tải cơ bản không thể đảm bảo tính bảo mật và do đó có thể dẫn đến tiết lộ mật khẩu cho bên trái phép.

LDAPv3 đi kèm cùng với một lệnh ràng buộc hỗ trợ các lớp cơ chế bảo mật (Simple Authentication and Security - SASL) xác thực và đơn giản. Đây là một khuôn khổ xác thực chung, mà các phương pháp xác thực khác nhau có sẵn để xác thực khách hàng đến máy chủ, một trong số họ là Kerberos.

Hơn nữa, các hoạt động giao thức mở rộng có sẵn trong LDAPv3. Một phần mở rộng liên quan đến an ninh là mở rộng cho Transport Layer Security (TLS) cho LDAPv3. Điều này cho phép hoạt động cũng sử dụng TLS như một phương tiện để mã hóa một phiên LDAP và bảo vệ chống giả mạo. TLS có một cơ chế cho phép nó để giao tiếp với một máy chủ SSL để nó tương thích ngược. Các nguyên tắc cơ bản của SSL và TLS là giống nhau.

2.6 Mục an ninh

An ninh là rất quan trọng trong thế giới nối mạng của máy tính, và điều này đúng với LDAP là tốt. Khi gửi dữ liệu qua mạng không an toàn, nội bộ hay bên ngoài, thông tin nhạy cảm có thể cần được bảo vệ trong quá trình vận chuyển. Ngoài ra còn có một nhu cầu để biết ai đang yêu cầu các thông tin và những người được gửi đi. Điều này đặc biệt quan trọng khi nói đến các hoạt động cập nhật vào một thư mục. An ninh hạn, như được sử dụng trong bối cảnh của cuốn sách này, thường bao gồm bốn khía cạnh sau:

-         Xác thực: đảm bảo rằng bên đối diện (hoặc người máy) thực sự là người mà anh / cô ấy / nó tuyên bố là.

-         Liêm: đảm bảo rằng thông tin mà đến là thực sự giống như những gì đã được gửi.

-         Bảo mật: Bảo vệ công bố thông tin bằng dữ liệu mã hóa cho những người không có ý định nhận được nó.

-         Giấy ủy quyền: đảm bảo rằng một bữa tiệc thực sự cho phép để làm những gì anh / cô ấy / nó được yêu cầu để làm. Điều này về cơ bản là đạt được bằng cách chỉ định điều khiển truy cập, như đọc, viết, hoặc xóa, để ID người dùng hoặc tên gọi thông thường.

Các phần sau đây tập trung vào ba khía cạnh đầu tiên (kể từ khi ủy quyền chưa có trong tiêu chuẩn Phiên bản 3 LDAP): xác thực, tính toàn vẹn và bảo mật. Có một số phương pháp có thể được sử dụng cho mục đích này, những người quan trọng nhất được thảo luận ở đây. Đó là:

-          Không có xác thực.

-          Xác thực cơ bản.

-          Đơn giản xác thực và Layer Security (SASL). Điều này bao gồm DIGEST-MD5. Khi một khách hàng sử dụng Digest-MD5, mật khẩu không được truyền trong văn bản rõ ràng và giao thức ngăn chặn tấn công.

2.6.1 Không xác thực

Đây là phương pháp thẩm định đơn giản nhất, một trong đó rõ ràng là không cần phải được giải thích trong nhiều chi tiết. Phương pháp này chỉ nên được sử dụng khi bảo mật dữ liệu không phải là một vấn đề và khi không có quyền kiểm soát truy cập đặc biệt có liên quan. Đây có thể là trường hợp, ví dụ, khi thư mục của bạn là một địa chỉ cuốn sách có thể xem bởi bất cứ ai. Không xác thực được giả định khi bạn rời khỏi mật khẩu và các lĩnh vực DN có sản phẩm nào trong một hoạt động ldap. Sau đó các máy chủ LDAP tự động giả định người sử dụng một phiên vô danh và cấp quyền truy cập với các truy cập thích hợp kiểm soát được xác định cho thiskind tiếp cận (không nên nhầm lẫn với người sử dụng SASL vô danh).

2.6.2  Xác thực cơ bản

Cơ chế bảo mật trong LDAP được đàm phán khi kết nối giữa khách hàng và máy chủ được thiết lập. Đây là phương pháp được quy định trong LDAP giao diện chương trình ứng dụng (API). Bên cạnh các tùy chọn sử dụng không có chứng thực ở tất cả, cơ chế bảo mật đơn giản nhất trong LDAP được gọi là xác thực cơ bản, cũng được sử dụng trong một số giao thức web khác có liên quan, chẳng hạn như trong HTTP.

Khi sử dụng xác thực cơ bản với LDAP, khách hàng xác định mình đến máy chủ bằng phương tiện của một DN và một mật khẩu được gửi trong các rõ ràng qua mạng (một số hiện thực có thể sử dụng mã hóa Base64 thay thế). Máy chủ xem xét các khách hàng thực, nếu các DN và mật khẩu gửi của khách hàng phù hợp với mật khẩu cho DN được lưu trữ trong thư mục. Base64 mã hóa được xác định trong Internet Mail đa Extensions (MIME) tiêu chuẩn LDAP (RFC 1521). Nó là một mã hóa tương đối đơn giản, và do đó nó không phải là khó để phá vỡ một lần một đã chiếm được dữ liệu trên mạng.

2.6.3  SASL

SASL là một khuôn khổ cho việc thêm cơ chế xác thực bổ sung cho giao thức hướng kết nối. Nó đã được thêm vào LDAP Phiên bản 3 để khắc phục những thiếu sót xác thực của phiên bản 2. SASL ban đầu được đưa ra để thêm xác thực mạnh mẽ hơn để giao thức IMAP. SASL đã phát triển thành một hệ thống chung cho trung gian giữa các giao thức và hệ thống xác thực. Nó là một tiêu chuẩn Internet được đề xuất định nghĩa trong RFC 2222.

Trong SASL, giao thức kết nối, như LDAP, IMAP, andso trên, được đại diện bởi hồ sơ, mỗi hồ sơ cá nhân được xem là một phần mở rộng giao thức cho phép các giao thức và SASL để làm việc cùng nhau. Một danh sách đầy đủ của SASLprofiles có thể được lấy từ Viện Khoa học Thông tin (ISI). Mỗi giao thức có ý định sử dụng SASL cần phải được extendedwith một lệnh để xác định một cơ chế xác thực và để thực hiện một cuộc trao đổi xác thực. Tùy chọn, một lớp bảo mật có thể thương lượng để mã hóa dữ liệu sau khi xác thực và do đó đảm bảo bí mật. LDAP v3 bao gồm một lệnh (ldap_sasl_bind ()) để mã hóa dữ liệu sau khi xác thực.

2.6.4  SSL và TLS

Secure Socket giao thức lớp (SSL) đã được đưa ra để cung cấp cho cả hai xác thực và bảo mật dữ liệu. Nó đóng gói các ổ cắm TCP / IP để về cơ bản tất cả các ứng dụng giao thức TCP / IP có thể sử dụng nó để đảm bảo thông tin liên lạc của nó.

SSL / TLS hỗ trợ xác thực máy chủ (khách hàng xác nhận máy chủ), xác thực khách hàng (máy chủ xác thực khách hàng), hoặc xác thực lẫn nhau. Ngoài ra, nó cung cấp cho sự riêng tư bằng cách mã hóa dữ liệu được gửi qua mạng. SSL / TLS sử dụng một phương pháp khóa công khai để bảo đảm thông tin liên lạc và để xác thực các đối tác của phiên giao dịch. Điều này đạt được với một cặp khóa công khai / riêng tư. Họ hoạt động chức năng như ngược lại với nhau, có nghĩa là dữ liệu mã hóa với khóa riêng có thể được giải mã với khóa công khai và ngược lại. Giả định cho những cân nhắc sau là máy chủ có cặp khóa của mình đã tạo ra. Điều này thường được thực hiện khi thiết lập máy chủ LDAP.

Sự trao đổi đơn giản giữa một khách hàng và một máy chủ thương lượng một kết nối SSL / TLS được giải thích trong các bước sau:

Như là một bước đầu tiên, khách hàng yêu cầu máy chủ cho một phiên SSL / TLS. Khách hàng cũng bao gồm các tùy chọn SSL / TLS nó hỗ trợ trong yêu cầu.

Máy chủ sẽ gửi lại SSL của nó / tùy chọn TLS và một giấy chứng nhận bao gồm, trong số những thứ khác, chìa khóa công cộng của máy chủ, bản sắc cho người mà chứng chỉ đã được ban hành (như là một tên phân biệt), tên của chứng nhận và thời gian hiệu lực. Giấy chứng nhận có thể được coi như tương đương với điện tử của một hộ chiếu. Nó phải được phát hành bởi một chung, tin cậy Certificate Authority (CA) mà chứng từ đó khóa công khai thực sự thuộc về các thực thể được đề cập trong giấy chứng nhận. Giấy chứng nhận được ký chứng nhận bythe có thể được xác nhận với khóa công khai miễn phí của chứng nhận.

Khách hàng sẽ yêu cầu một máy chủ để chứng minh danh tính của mình. Điều này là để đảm bảo rằng giấy chứng nhận không được gửi bởi một người khác chặn nó vào một dịp trước đây.

Máy chủ sẽ gửi lại một tin nhắn bao gồm cả tin nhắn tiêu hóa (tương tự như một tổng kiểm tra) được mã hóa với khóa riêng của nó. Một tiêu hóa tin nhắn được tính toán từ các nội dung tin nhắn bằng cách sử dụng hàm băm có hai tính năng. Nó là vô cùng khó khăn để đảo ngược, và itis gần như không thể tìm thấy một thông điệp rằng sẽ sản xuất tiêu hóa tương tự. Khách hàng có thể giải mã tiêu hóa với khóa công khai của máy chủ và sau đó so sánh nó với các tiêu hóa nó tính từ tin nhắn. Nếu cả hai đều bình đẳng, bản sắc của máy chủ được chứng minh, và quá trình thẩm định được hoàn tất.

Tiếp theo, máy chủ và máy khách phải đồng ý khi một bí mật (đối xứng) chính được sử dụng để mã hóa dữ liệu. Mã hóa dữ liệu được thực hiện với một thuật toán khóa đối xứng bởi vì nó là hiệu quả hơn so với phương pháp khóa công khai tính toán chuyên sâu. Do đó khách hàng tạo ra một khóa đối xứng, mã hóa nó với khóa công khai của máy chủ, và gửi nó đến máy chủ. Chỉ có máy chủ với khóa riêng của nó có thể giải mã khóa bí mật.

Máy chủ giải mã khóa bí mật và gửi lại một tin nhắn kiểm tra mã hóa với khóa bí mật để chứng minh rằng chìa khóa đã đến nơi an toàn. Bây giờ họ có thể bắt đầu giao tiếp bằng cách sử dụng khóa đối xứng để mã hóa dữ liệu.

Như đã nêu ở trên, SSL/TLS được sử dụng để xác thực một máy chủ cho khách hàng sử dụng giấy chứng nhận và khóa riêng của nó và đàm phán một khóa bí mật sau này được sử dụng để mã hóa dữ liệu.