LDAP (англ.Lightweight Directory Access Protocol — Полегшений протокол доступу до директорій / каталогів) — мережевий протоколприкладного рівня для надсилання запитів та модифікації данихслужби каталогів через TCP/IP. LDAP є відкритим, комерційно-нейтральним, (англ.vendor-neutral), промисловим стандартним протоколом. LDAP розроблений IETF як полегшений варіант розробленого ITU-T протоколу DAP.
Серед поширених варіантів використання LDAP — надання єдиного сховища для зберігання імен користувачів та паролів. Це дозволяє різним службам та застосункам надсилати запити до LDAP сервера для валідації користувачів[1].
Короткий опис
LDAP — відносно простий протокол, що використовує TCP/IP і дозволяє проводити операції аутентифікації (bind), пошуку (search) та порівняння (compare), а також операції додавання, зміни або видалення записів. Зазвичай LDAP-сервер приймає вхідні з'єднання на порт 389 по протоколах TCP або UDP. Для LDAP-сеансів, інкапсульованих в SSL, зазвичай використовується порт 636.
Будь-який запис у каталозі LDAP складається з одного або декількох атрибутів і володіє унікальним / розрізняльним ім'ям (DN — англ.Distinguished Name). Унікальне ім'я може виглядати, наприклад, наступним чином: «cn = Іван Петренко, ou = Співробітники, dc = example, dc = com». Унікальне ім'я складається з одного або декількох відносних унікальних імен (RDN — англ.Relative Distinguished Name), розділених комою. Відносне унікальне ім'я має вигляд ІмяАтрибута = значення. На одному рівні каталогу не може існувати двох записів з однаковими відносними унікальними іменами. В силу цієї структури унікального імені записи в каталозі LDAP можна легко уявити у вигляді дерева.
Запис може складатися тільки з тих атрибутів, які визначені в описі класу запису (object class), які, у свою чергу, об'єднані в схеми (schema). У схемі визначено, які атрибути є для даного класу обов'язковими, а які — необов'язковими. Також схема визначає тип і правила порівняння атрибутів. Кожен атрибут запису може зберігати кілька значень.
Як правило, каталог LDAP реалізується згідно з моделлюX.500: він складається із деревазаписів[2], кожне з яких складається із множини іменованих атрибутів зі значеннями. Деякі зі служб підтримують складнішу модель «ліс», але більшість мають лише один початковий запис.
Залежно від обраної моделі, LDAP-каталог часто віддзеркалює різноманітні політичні, географічні, та (або) організаційні регіони. Встановлені LDAP-системи схиляються до використання доменних імен (DNS) для структурування найвищих рівнів ієрархії. На нижчих рівнях в каталозі можуть бути записи, які відповідають людям, організаційним підрозділам, принтерам, документам, групам людей, або будь чому іншому, що представляє даний запис, або множину записів в каталозі.
Остання версія протоколу — LDAPv3. Стандарт LDAPv3 визначено в низці документів IETF, як описано в RFC 4510.
Структура каталогів
Протокол надає інтерфейс з каталогами, які відповідають стандарту X.500 видання 1993 р.:
Запис складається з набору атрибутів.
Атрибут має ім'я, яке може бути типом атрибута (attribute type) або описом (фактично скороченою назвою) атрибута (attribute description), і одне або кілька значень. Атрибути визначені в схемі.
Кожен запис має унікальний ідентифікатор: його розрізняльне ім'я (Distinguished Name — DN). Воно складається з одного чи декількох відносних розрізняльних імен (Relative Distinguished Name — RDN), утворених з одного чи декількох атрибутів в запису. Можна уявити DN як повний шлях до файлу і RDN як ім'я файлу в батьківській папці (наприклад, якщо /foo/bar/myfile.txt є DN, то myfile.txt буде RDN). Добре DN і RDN пояснено тут [Архівовано 8 листопада 2014 у Wayback Machine.].
Про опис атрибута йдеться в третьому розділі RFC 4514:
Implementations MUST recognize AttributeType name strings
(descriptors) listed in the following table, but MAY recognize other
name strings.
(Реалізації ПОВИННІ розпізнавати рядки назв AttributeType (дескрипторів), перелічених в
наступній таблиці, але МОЖУТЬ розпізнавати й інші назви рядків.)
String X.500 AttributeType
------ --------------------------------------------
CN commonName (2.5.4.3)
L localityName (2.5.4.7)
ST stateOrProvinceName (2.5.4.8)
O organizationName (2.5.4.10)
OU organizationalUnitName (2.5.4.11)
C countryName (2.5.4.6)
STREET streetAddress (2.5.4.9)
DC domainComponent (0.9.2342.19200300.100.1.25)
UID userId (0.9.2342.19200300.100.1.1)
Назви (імена) атрибутів у формі тип атрибута і опис атрибута наведені та описані в RFC 4519.
Історія виникнення
Телекомунікаційні компанії впровадили концепцію служби каталогів до інформаційних технологій та комп'ютерних мереж так як вони розуміли, на підставі свого 70-річного досвіду роботи з телефонними каталогами. Це вилилося у специфікації X.500 (набору протоколів розробленого ITU у 1980 роках).
X.500служби каталогів були доступні через X.500 протокол доступу до каталогів (англ.Directory Access Protocol — DAP), який використовував Open Systems Interconnection (OSI) стек протоколів. Розробка LDAP мала на меті полегшити доступ до X.500служби каталогів через простіший стек протоколів TCP/IP.
RFC 4403 — LDAP Schema for Universal Description, Discovery, and Integration version 3 (UDDIv3) (LDAP Схема для опису, представлення та інтеграції версії 3 (UDDIv3))
RFC 4524 — LDAP: COSINE Schema (replaces RFC 1274) (Схема COSINE (Co-operation and Open Systems Interconnection in Europe (Кооперація і взаємодія відкритих систем в Європі))
RFC 1778 — The String Representation of Standard Attribute Syntaxes (Рядкове подання синтаксисів стандартних атрибутів) (replaced RFC 1488)
RFC 1779 — A String Representation of Distinguished Names (Рядкове подання розрізняльних імен) (replaced RFC 1485)
LDAPv2 був наданий історичний статус за наступним RFC:
RFC 3494 — Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status (Полегшений протокол доступу до каталогів версії 2 (LDAPv2)) в історичний статус)
