OpenLDAP

В этой статье слишком много ссылок на первоисточники . Пожалуйста, улучшите это, добавив вторичные или третичные источники . ( Октябрь 2014 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

OpenLDAP

Разработчики)	Проект OpenLDAP
изначальный выпуск	26 августа 1998 г . ; 22 года назад [1] ( 1998-08-26 )
Стабильный выпуск	2.4.55 [2] / 26 октября 2020 г . ; 4 месяца назад ( 2020-10-26 )
Предварительный выпуск	2.5.0alpha / 14 октября 2020
Репозиторий	git .openldap .org / openldap / openldap .git
Написано в	C
Операционная система	Любой
Платформа	Кроссплатформенность
Тип	Служба каталогов LDAP
Лицензия	Общественная лицензия OpenLDAP [3]
Интернет сайт	www .openldap .org

OpenLDAP является свободным , открытым исходным кодом , реализация Lightweight Directory Access Protocol (LDAP) , разработанной в рамках проекта OpenLDAP. Он выпущен под собственной лицензией в стиле BSD, которая называется OpenLDAP Public License. ^[4]

LDAP - это протокол, не зависящий от платформы. Несколько распространенных дистрибутивов Linux включают программное обеспечение OpenLDAP для поддержки LDAP. Программное обеспечение также работает в вариантах BSD , а также в AIX , Android , HP-UX , macOS , Solaris , Microsoft Windows (NT и производные, например, 2000, XP, Vista, Windows 7 и т. Д.) И z / OS .

История [ править ]

Проект OpenLDAP ^[5] был начат в 1998 году Куртом Зейленга. ^[6] Проект начался с клонирования эталонного источника LDAP из Университета Мичигана, где длительный проект поддерживал разработку и развитие протокола LDAP до его окончательного выпуска в 1996 году.

По состоянию на май 2015 ^{[Обновить]}года в проекте OpenLDAP участвовали четыре основных члена команды: Ховард Чу (главный архитектор), ^[7] Куана Гибсон-Маунт, Халлвард Фурусет и Курт Зейленга. Есть множество других важных и активных участников, включая Люка Ховарда, Райана Тэнди и Гэвина Генри. Среди бывших членов основной команды - Пьеранджело Масарати. ^[8]

Компоненты [ править ]

OpenLDAP состоит из трех основных компонентов:

• slapd - автономный демон LDAP и связанные с ним модули и инструменты
• библиотеки, реализующие протокол LDAP и основные правила кодирования ASN.1 (BER)
• клиентское программное обеспечение: ldapsearch, ldapadd, ldapdelete и другие

Кроме того, в проекте OpenLDAP имеется ряд подпроектов:

• JLDAP - библиотеки классов LDAP для Java
• JDBC-LDAP - Java JDBC - драйвер моста LDAP
• ldapc ++ - библиотеки классов LDAP для C ++
• Fortress - Java SDK для управления доступом на основе ролей
• LMDB - библиотека базы данных с отображением в память

Бэкэнды [ править ]

Общая концепция [ править ]

Исторически архитектура сервера OpenLDAP (slapd, Standalone LDAP Daemon) была разделена на интерфейс, который обрабатывает доступ к сети и обработку протоколов, и серверную часть, которая занимается строго хранением данных. Этот разделенный дизайн был особенностью исходного кода Мичиганского университета, написанного в 1996 году ^[9] и продолженного во всех последующих выпусках OpenLDAP. Исходный код включал один основной сервер базы данных и два экспериментальных / демонстрационных сервера. Архитектура является модульной, и теперь доступно множество различных серверных программ для взаимодействия с другими технологиями, а не только с традиционными базами данных.

Примечание. В более старых (1.x) выпусках термины «серверная часть» и «база данных» часто использовались как синонимы. Чтобы быть точным, «бэкэнд» - это класс интерфейса хранилища, а «база данных» - это экземпляр бэкэнда. Сервер slapd может использовать произвольно много бэкэндов одновременно и может иметь произвольно много экземпляров каждого бэкэнда (т. Е. Произвольно много баз данных), активных одновременно.

Доступные бэкенды [ править ]

В настоящее время в дистрибутиве OpenLDAP предоставляется 17 различных серверных модулей, и известно, что различные третьи стороны поддерживают другие серверные модули независимо. Стандартные серверные ВМ можно условно разделить на три категории:

• Бэкэнды хранения данных - они фактически хранят данные
  • back-bdb: первый транзакционный бэкэнд для OpenLDAP, построенный на Berkeley DB.
  • back-hdb: вариант back-bdb, который является полностью иерархическим и поддерживает переименование поддеревьев.
  • back-ldif: построен на простых текстовых файлах LDIF
  • back-mdb: транзакционный бэкэнд, построенный на базе данных OpenLDAP Lightning Memory-Mapped Database (LMDB)
  • back-ndb: транзакционный бэкэнд, построенный на кластерном движке MySQL NDB
• Серверные прокси-серверы - они действуют как шлюзы к другим системам хранения данных.
  • back-ldap: простой прокси для других серверов LDAP
  • back-meta: прокси с функциями метакаталога
  • back-passwd: использует пароль системы Unix и данные группы
  • back-relay: внутреннее перенаправление на другие серверные части slapd
  • back-sql: общается с произвольными базами данных SQL
• Динамические бэкенды - они генерируют данные на лету
  • back-config: настройка slapd через LDAP
  • back-dnssrv: обнаруживает серверы LDAP через DNS
  • back-monitor: статистика slapd через LDAP
  • back-null: бэкэнд-приемник / без операций, аналог Unix / dev / null
  • back-perl: вызывает произвольные модули Perl в ответ на запросы LDAP
  • back-shell: вызывает сценарии оболочки для запросов LDAP
  • back-sock: перенаправляет запросы LDAP через IPC произвольным демонам

Некоторые бэкенды, доступные в старых версиях OpenLDAP, больше не используются, в первую очередь back-ldbm, унаследованный от исходного кода UMich, и back-tcl, который был похож на back-perl и back-shell.

Скоро будет прекращена поддержка других бэкэндов. back-ndb теперь устарел, поскольку партнерство с MySQL, которое привело к его разработке, было прекращено Oracle после того, как Oracle приобрела MySQL. back-bdb и back-hdb будут заменены на back-mdb в ближайшее время, поскольку back-mdb превосходит все аспекты производительности, надежности и управляемости.

На практике бэкенды, такие как -perl, -shell и -sock, позволяют взаимодействовать с любым произвольным языком программирования, тем самым обеспечивая безграничные возможности для настройки и расширения. По сути, сервер slapd становится механизмом RPC с компактным, четко определенным и повсеместным API.

Оверлеи [ править ]

Общая концепция [ править ]

Обычно запрос LDAP принимается внешним интерфейсом, декодируется и затем передается внутреннему интерфейсу для обработки. Когда серверная часть завершает запрос, она возвращает результат веб-интерфейсу, который затем отправляет результат клиенту LDAP. Оверлей - это фрагмент кода, который можно вставить между интерфейсом и сервером. Таким образом, он может перехватывать запросы и инициировать другие действия с ними до того, как серверная часть их получит, а также может воздействовать на результаты серверной части до того, как они достигнут внешнего интерфейса. Оверлеи имеют полный доступ к внутренним API slapd и поэтому могут вызывать все, что может выполнить интерфейс или другие серверные части. Одновременно можно использовать несколько оверлеев, образуя стек модулей между интерфейсом и сервером.

Наложения предоставляют простые средства для расширения функциональности базы данных, не требуя написания совершенно новой серверной части, и позволяют добавлять новые функции в компактные, легко отлаживаемые и поддерживаемые модули. С момента появления функции наложения в OpenLDAP 2.2 сообщество OpenLDAP внесло много новых наложений.

Доступные оверлеи [ править ]

В настоящее время в основной дистрибутив OpenLDAP входит 21 оверлей, еще 15 оверлеев находятся в разделе кода, добавляемого пользователями, и еще больше ожидают утверждения для включения.

Другие модули [ править ]

Бэкэнды и оверлеи - два наиболее часто используемых типа модулей. Бэкэнды обычно были встроены в двоичный файл slapd, но они также могут быть построены как динамически загружаемые модули, а оверлеи обычно создаются как динамические модули. Кроме того, slapd поддерживает динамические модули для реализации новых синтаксисов LDAP, правил сопоставления, элементов управления и расширенных операций, а также для реализации настраиваемых механизмов управления доступом и механизмов хеширования паролей.

OpenLDAP также поддерживает SLAPI, архитектуру подключаемых модулей, используемую Sun и Netscape / Fedora / Red Hat. В текущих выпусках структура SLAPI реализована внутри наложения slapd. Хотя многие плагины, написанные для Sun / Netscape / Fedora / Red Hat, совместимы с OpenLDAP, очень немногие члены сообщества OpenLDAP используют SLAPI.

Доступные модули [ править ]

• Родные модули slapd
  • acl / posixgroup - поддержка членства posixGroup в управлении доступом
  • comp_match - поддержка сопоставления на основе компонентов
  • kinit - поддерживать / обновлять Kerberos TGT для slapd
  • passwd / - дополнительные механизмы хеширования паролей. В настоящее время включает Kerberos , Netscape, RADIUS и SHA-2 .
• Плагины SLAPI
  • addrdnvalue - добавить значение RDN к записи, если оно было опущено в запросе Add

Сводка выпуска [ править ]

Основные (функциональные) версии программного обеспечения OpenLDAP включают:

• OpenLDAP Version 1 представляет собой общую очистку последнего выпуска проекта Мичиганского университета (выпуск 3.3) и объединение дополнительных изменений.
• OpenLDAP версии 2.0, выпущенный в августе 2000 года, включает в себя основные улучшения, включая поддержку LDAP версии 3 (LDAPv3), поддержку интернет-протокола версии 6 ( IPv6 ) и множество других улучшений.
• OpenLDAP версии 2.1, выпущенный в июне 2002 года, включал серверную часть транзакционной базы данных (основанную на Berkeley Database или BDB), поддержку простого уровня аутентификации и безопасности (SASL), а также экспериментальные серверные части Meta, Monitor и Virtual.
• OpenLDAP версии 2.2, выпущенный в декабре 2003 года, включал механизм синхронизации LDAP с поддержкой репликации (syncrepl), оверлейный интерфейс и многочисленные функциональные улучшения, связанные с базами данных и RFC.
• OpenLDAP версии 2.3, выпущенный в июне 2005 года, включал серверную часть конфигурации (динамическую конфигурацию), дополнительные оверлеи, включая RFC-совместимое программное обеспечение политики паролей, а также множество дополнительных улучшений.
• OpenLDAP версии 2.4, выпущенный в октябре 2007 года, представил N-стороннюю репликацию MultiMaster, резервный мастер, возможность удалять и изменять элементы схемы на лету, а также многое другое. ^[10]

Репликация [ править ]

OpenLDAP поддерживает репликацию с использованием синхронизации содержимого, как указано в RFC 4533 . В дальнейшем эта спецификация именуется «syncrepl». В дополнение к базовой спецификации также поддерживается расширение, известное как delta-syncrepl. Дополнительные улучшения были реализованы для поддержки репликации с несколькими мастерами .

syncrepl [ править ]

Базовая операция синхронизации описана в RFC 4533 . Протокол определен таким образом, что постоянная база данных изменений не требуется. Скорее, набор изменений подразумевается посредством информации порядкового номера изменения (CSN), хранящейся в каждой записи и оптимизируемой с помощью дополнительного журнала сеанса, который особенно полезен для отслеживания недавних удалений. Модель работы состоит в том, что клиент репликации (потребитель) отправляет «поиск с синхронизацией контента» на сервер репликации (провайдер). Потребитель может предоставить файл cookie в этом поиске (особенно если он ранее был синхронизирован с поставщиком). В реализации OpenLDAP RFC 4533 этот файл cookie включает последний CSN, полученный от поставщика (называемый contextCSN).

Затем поставщик возвращает в качестве результатов поиска (или, см. Оптимизацию ниже, ответы с информацией о синхронизации) настоящее (неизмененная запись используется только в текущей фазе этапа обновления) (без атрибутов), добавлено, изменено (представлено на этапе обновления как добавить со всеми текущими атрибутами) или удалить (без атрибутов) записи, чтобы перевести потребителя в синхронизированное состояние на основе того, что известно через их cookie. Если файл cookie отсутствует или указывает, что потребитель полностью рассинхронизирован, то на этапе обновления поставщик отправит добавление для каждой имеющейся записи. В идеальном случае этап обновления ответа содержит только этап удаления с небольшим набором добавлений (включая те, которые представляют текущий результат изменений) и удалений, которые произошли с момента последней синхронизации потребителя с поставщиком. Тем не мение,из-за ограниченного состояния журнала сеанса (также непостоянного), хранящегося в провайдере, может потребоваться текущая фаза, в частности, включая представление всех неизмененных записей в качестве средства (неэффективного) для обозначения того, что было удалено в провайдере с момента потребителя последняя синхронизирована.

Поиск может выполняться либо в режиме обновления, либо в режиме refreshAndPersist, что подразумевает, какие этапы происходят. Этап обновления всегда выполняется первым. На этапе обновления могут происходить две фазы: присутствие и удаление, где всегда присутствует перед удалением. Фазы разделяются ответом с информацией о синхронизации, в котором указывается, какая фаза завершена. Этапы обновления и сохранения также разграничиваются таким ответом с информацией о синхронизации. Необязательная оптимизация для более компактного представления группы записей, которые должны быть представлены или удалены, заключается в использовании ответа с информацией о синхронизации, содержащего syncIdSet, который идентифицирует список значений entryUUID этих записей.

Настоящая фаза отличается от фазы удаления следующим образом. Записи, которые представляют собой неизмененные записи, могут быть возвращены только на текущем этапе. Записи, которые удаляют записи, могут быть предоставлены только на этапе удаления. На любом этапе могут быть возвращены добавленные записи (включая добавления, которые представляют все текущие атрибуты измененных записей). В конце текущей фазы каждая запись, которая есть у потребителя, которая не была идентифицирована в добавленной записи или существующем ответе во время текущей фазы, неявно больше не находится в поставщике и, следовательно, должна быть удалена на потребителе, чтобы синхронизировать потребителя. с провайдером.

Как только начинается этап сохранения, провайдер отправляет результаты поиска, которые указывают только на добавление, изменение и удаление записей (нет указаний на неизмененные записи) для тех записей, которые изменились с момента завершения этапа обновления. Стадия сохранения продолжается бесконечно, что означает, что поиск не дает окончательного ответа «готово». Напротив, в режиме обновления происходит только этап обновления, и такой этап завершается ответом «Готово», который также завершает этап присутствия или удаления (в зависимости от того, какая фаза была активна в данный момент).

delta-syncrepl [ править ]

Этот протокол хранит постоянную базу данных доступов на запись (изменений) и может точно представлять каждое изменение (то есть только те атрибуты, которые изменились). Он по-прежнему основан на стандартной спецификации syncrepl, которая всегда отправляет изменения как полные записи. Но в delta-syncrepl переданные записи фактически отправляются из базы данных журнала, где каждое изменение в основной базе данных записывается как запись журнала. Записи журнала записываются с использованием схемы журнала LDAP. ^[11]

См. Также [ править ]

• Список программного обеспечения LDAP

Ссылки [ править ]

Внешние ссылки [ править ]

• Официальный веб-сайт
• Фонд OpenLDAP
• Использование libldap , учебник по клиентскому API OpenLDAP
• Статья Марти Хеймана об обновлении OpenLDAP , 13 сентября 2007 г.