Apache Directory

Apache Directory Server
Разработчики: Apache Software Foundation
Постоянный выпуск: 2.0.0-M20 / {{|2015|05|02}}
Состояние разработки: Active
Написана на: Java
Операционная система: Cross-platform
Тип ПО: LDAP
Лицензия: Apache License 2.0
Веб-сайт http://directory.apache.org/

Apache Directory проект с исходным кодом, принадлежащий Apache Software Foundation. Ее флагманский продукт, то Apache Directory Server, изначально написан Alex Karasulu, это встраиваемый сервер каталогов полностью написанный на Java. Apache Directory была сертифицирована LDAPv3-совместимой с The Open Group в 2006 году. Кроме LDAP, сервер поддерживает другие протоколы, а также, и сервер Kerberos.

Там существуют эти подпроекты:

  • Apache Каталог Studio - это LDAP-браузер / редактор для данных, схем, LDIF и DSML, написанны на Eclipse фреймворке.
  • Apache eSCIMo - это Java на основе реализации протокола SCIM.
  • Apache Fortress - приложение для управления доступом, написана на Java.
  • Apache Керби - это реализация Kerberos, написана на Java.
  • Apache LDAP API - это SDK для доступа к каталогам в Java.
  • Apache Mavibot - это приложение базы данных для Java-приложений

Введение

Стержнем ApacheDS является служба каталога, которая может хранить данные приложений и выполнять операции поиска для разных типов данных. Реализации протокола работают поверх службы каталога для обеспечения Internet-сервисов, относящихся к хранению данных, их поиску и извлечению. Вероятно, самой важной характеристикой ApacheDS является возможность применять различные протоколы в его службе каталога. Это означает, что вы можете хранить ваши прикладные данные (включая динамические объекты Java) в ApacheDS, и различные клиенты могут пользоваться вашими данными, используя различные протоколы. Наиболее важным протоколом реализуемым посредством ApacheDS является Lightweight Directory Access Protocol (Облегченный Протокол Доступа к Сетевому Каталогу) (LDAP). ApacheDS выступает в качестве LDAP-сервера, ожидает запросы и координируется с внутренним стержнем службы каталога для ответа на запросы LDAP

Справочник подпроектов

Каталог Apache студии

Апач Каталог студии является полным каталог инструментов платформа предназначена для использования с любым сервером LDAP, однако он в частности, предназначен для использования с ApacheDS. Это приложение Eclipse RCP, состоящий из нескольких Eclipse (OSGi) плагинов, которые могут быть легко модернизирован дополнительных. Эти модули могут работать даже внутри самого Eclipse.

ApacheDS

ApacheDS является расширяемым и встраиваемый сервер каталогов полностью написан на Java, которая была сертифицирована LDAPv3 совместимый по Open Group. Кроме того, он поддерживает LDAP Kerberos 5 и Протокол изменения пароля. Она была разработана, чтобы ввести триггеры, хранимые процедуры, очередей и представлений в мире LDAP, который не хватало эти богатые конструкции.

Apache eSCIMo

Apache eSCIMo является Java на основе реализации SCIM спецификации v2.0. Использование eSCIMo пользовательские и групповые детали могут быть легко переданы между SCIM осведомленных приложений.

=== Apache === Крепость

Apache крепость представляет собой систему управления доступом основанные на стандартах, которая обеспечивает управление доступом на основе ролей, делегированного администрирования и политики паролей служб с внутреннего интерфейса LDAP.

Apache Керби

Apache Керби является Java Kerberos связывания. Она обеспечивает богатый, интуитивный и совместимую реализацию, библиотека, KDC и различные объекты, которые объединяет инфраструктуру PKI, OTP и токенов (oauth2), как требуется в современных условиях, таких как облачные, Hadoop и мобильный.

Apache LDAP API

API Apache Справочник LDAP требует постоянных усилий, чтобы обеспечить более глубокое API LDAP, в качестве замены для JNDI и существующего LDAP API (jLdap и Mozilla LDAP API). Это "схемы известно" API с некоторыми удобных способов доступа ко всем типам серверов LDAP, а не только ApacheDS, но любой сервер LDAP. API является OSGi готова и расширяемый. Новые элементы управления, элементы схемы и сетевого уровня могут быть добавлены или использованы в ближайшем будущем.

Apache Mavibot

Mavibot является многопрофильным управления версиями Параллелизм (MVCC) BTree в Java. Ожидается, что он будет заменой JDBM (текущей подсистемой для Apache Directory Server) но может быть хорошим выбором для любого другого проекта, нуждающихся в реализации Java MVCC BTree.

История

Alex Karasulu основал проект Apache Directory Project в 2002 году. В 2006 году он был сертифицирован Open Group как совместимый с протоколом LDAPv3. Кроме LDAP, Apache DS поддерживает Kerberos5 и Change Password Protocol. Разработчик позиционирует сервер как встраиваемое решение, предназначенное для интеграции в другие Java-приложения и работающее с ними в контексте одной VM. На сегодняшний день он встроен в такие продукты, как Apache Geronimo, JBoss и другие. Тем не менее, Apache DS можно запустить автономно, например, как службу Windows. Поскольку программа полностью написана на Java, она успешно компилируется и работает на огромном количестве аппаратных и программных платформ. На сайте проекта доступны инсталляторы для GNU/Linux, Windows и MacOS, а также бинарные пакеты для Debian, Fedora и Solaris (для платформ SPARC и Intel), но на самом деле набор поддерживаемых ОС значительно шире. Помимо стандартного функционала сервера LDAP, в Apache DS реализованы такие интересные расширения, как хранимые процедуры и триггеры. Автор проекта Алекс Карасулу (Alex Karasulu) в 2001 году предложил включить в сервер OpenLDAP поддержку этих объектов, которые давно используются в реляционных базах данных, но отсутствуют в спецификациях LDAP. Его попытка провалилась из-за сложности существующего программного обеспечения. В октябре 2002 года Алекс начинает разработку собственного сервера каталогов, написанного на Java. Затем, в октябре 2003 года, он передает права на код своей разработки в Apache Software Foundation.

Служба Каталогов в ApacheDS

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

Архитектура

50k-ft-architecture.png

Apache Directory Server (также известный как ApacheDS) архитектура имеет много различных слоев. Следующая схема выставить наиболее важные из них:

Architecture.png

Как мы видим, выделяется четыре различных слоя:

  • Сеть
  • Сессия
  • PartitionNexus
  • Бэкэнд

Запуска сервера

Так что, когда запущен DirectoryService и находится в рабочем состоянии, мы можем pfgecrfnm различные серверы, которые будут принимать входящие запросы от удаленных gbhjd.

Транспорт

Это позволяет соединение через определение транспорта. Транспортныv является TCP или UDP сокет, Cпособный принимать запрос и отправить ответ. В зависимости от типа сервера, мы можем объявить один или несколько TCP транспортов или TCP и UDP транспортов или лишь UDP Transport.

Сервер Ldap

Сервер LDAP необходим один или два TCP транспорта. Стандартный порт LDAP (по умолчанию в 10389 для ApacheDS, но хорошо знают порт, как правило, 389), а также можно объявить LDAPS порт (по умолчанию это 10636 для ApacheDS, но, как правило, 636).

Обратите внимание, что * LDAPS * считается устаревшим.

Kerberos Сервер

Kerberos сервер использует один TCP Transport ( 60088, но так же порт 88) и один _transport UDP (одинаковое значение для обоих портов). Идея заключается в том, что сообщение начинается на TCP и UDP продолжается.

ChangePassword Сервер

ChangePassword сервер использует один TCP транспорта и один UDP транспорт тоже. Значение по умолчанию равно 60464, но хорошо известный порт 464.

HTTP Server

Есть HttpServer забегание, он используется для управления. Заявленные порты и TCP-порт, один для HTTP и его значение по умолчанию 8080, другой для HTTPS и его значение по умолчанию 8443.

DirectoryService

DirectoryService является ядром сервера. Именно здесь обрабатываются входящие запросы и задается бэкенд для данных.

Он имеет точку входа, OperationManager, который отвечает за сопоставление запросов в цепочку интерсепторов, а также для защиты сервера от одновременных изменений.

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

Теперь надо просто детерминировать к какому типу Backend мы должны обратиться, и это делается с помощью Dn. Затем запрос передается на Backend, который возвращает результат.

Окружение

DirectoryService знает о своей среде исполнения: у него есть экземпляр schemaManager, он знает о цепи интерсепторов, он хранит карту всех находящихся на рассмотрении запросов (это необходимо, как можно отказаться от какой-то запрос), он владеет существующим сеансам.

Другими словами, то DirectoryService это не только часть сервера, выполняющего логику, он также держит текущее состояние каждого клиента.

Перехватчики

Перехватчики представляют собой функциональные слои внутри DirectoryService. Каждый из них отвечает за конкретную задачу.

Каждая операция Rceived по DirectoryService будут обработаны различными перехватчиками, один за другим, вплоть до бэкэнда, и снова, когда результат возвращается к вызывающему абоненту. Обратите внимание, что вызов следующего перехватчик не требует, чтобы вы знали, какой из них будет называться.

Некоторые перехватчики могут быть отключены, некоторые другие могут быть включены. Кроме того, можно добавить некоторые новые.

Backend

Бэкенд часть сервера, ответственного за хранение данных таким образом, мы можем легко восстановить их. Это хранилище не обязательно должны быть в неизменяемой памяти: можно иметь бэкенд в памяти.

Существующие Backends

JDBM LDIF В памяти JDBM Backend

Бэкэнд JDBM хранит данные на диске, используя BTrees. Это быстро, когда дело доходит до получения данных, медленно, когда вы должны добавить их.

In-Memory Backend

Этот бэкэнд загружает в память полный набор записей. Ничего не пишется на диске, ничего не читаем с диска. Если сервер остановлен, все потеряно.

LDIF Backend

Он поставляется в двух формах: один файл, или много ALl (по одному на входе). Это всегда опирается на внутреннюю память бэкенда, иначе было бы невозможно получить записи.

Так как зависим от бекенд в памяти, который обрабатывает индексы, мы должны создать эти индексы при этом Backend читается, что может быть дорогостоящей операцией.

ApacheDS выполняет JNDI

На рисунке ниже вы можете увидеть, как ApacheDS выполняет надстройку назначения имен и аранжировки каталога (Java Naming and Directory Interface - JNDI— это набор Java API, организованный в виде службы каталогов, который позволяет Java-клиентам открывать и просматривать данные и объекты по их именам.) для своей стержневой службы каталогов. JNDI является интерфейсом Java, который определяет методы для выполнения таких действий каталога как хранение данных в каталоге и поиск сохраненных данных. JNDI является частью как Java 2 Enterprise Edition (J2EE), так и Java 2 Standard Edition (J2SE). Тогда как J2SE включает только клиентскую поддержку JNDI, J2EE контейнеры обычно включают серверные реализации JNDI. A J2EE-контейнер может использовать службу каталогов ApacheDS через надстройку JNDI, как показано на рисунке:

Рисунок 1. ApacheDS внутри контейнера J2EE

Набор интерфейсов в JNDI обеспечивает абстрактный образ службы каталогов. Реализация JNDI обеспечивает логику непосредственно для сообщения со службой каталога (например, Java-платформа включает в себя реализацию JNDI для LDAP). Вы можете использовать JNDI для сообщения с любым типом службы каталога, если у вас имеется JNDI реализация именно для этого типа. Если вы хотите использовать JNDI в клиентском приложении на основе Java, вам нужна клиентская реализация JNDI. A клиентская реализация JNDI обеспечивает классы, которые реализуют интерфейсы JNDI по запросам автора к действиям каталога. ApacheDS реализует серверную JNDI. Это значит, что он включает классы, которые реализуют JNDI интерфейсы для ответа по запросам к действиям каталога. Контейнер J2EE может использовать службу каталога ApacheDS через его JNDI-надстройку.

Встраиваемая поддержка протокола

ApacheDS предназначался для использования только в качестве службы каталога, внедренного в J2EE контейнер. Вы можете использовать ApacheDS для реализации любого протокола, который требует внутренней службы протокола. Вы даже можете использовать его для обслуживания различных типов протоколов одновременно; например, текущая ApacheDS реализация обеспечивает выполнение как LDAP, так и Kerberos. Более того, список протоколов, поддерживаемых в ApacheDS постоянно растет. ApacheDS имеет подвижную, расширяемую структуру, которая делает возможным реализацию новых протоколов. На Рисунке 2 вы можете увидеть модель ApacheDS структуры, которая работает поверх надстройки JNDI, показанной на Рисунке 1

Рисунок 2. Гибкость и расширяемость структуры ApacheDS

Как видно из рисунка, ApacheDS использует набор интерфейсов, называемых Multipurpose Interfaces for Networked Applications (Многоцелевые Интерфейсы для Сетевых Приложений - MINA). MINA поддерживает реализацию нового протокола для внедрения в ApacheDS.

Как функционирует MINA

Интерфейсы в MINA содержат методы генерирования специфического протокола производственных объектов. Данные заводские объекты обеспечивают средства внедрения новой реализации протокола в ApacheDS. Реализации протокола обеспечивают выполнение MINA интерфейсов, а ApacheDS инфраструктура основывается на методах включенных в MINA для сообщения с реализациями протокола. Например, в MINA существует интерфейс ProtocolProvider, который использует метод getCodecFactory(). Этот метод ProtocolProvider.getCodecFactory() отсылает объект, экспонирующий другой интерфейс MINA, а именно ProtocolCodecFactory. Реализации протокола в ApacheDS обеспечивают выполнение интерфейса ProtocolProvider. Например, реализация LDAP в ApacheDS имеет класс LDAPProtocolProvider, который обеспечивает выполнение интерфейса ProtocolProvider. Метод getCodecFactory() в LDAPProtocolProvider выдает объект, который экспонирует интерфейс ProtocolCodecFactory. Это ProtocolCodecFactory, который является заводским объектом и который инфраструктура ApacheDS использует для кодирования и декодирования объектов для LDAP. ProtocolCodecFactory включает методы newEncoder() и newDecoder(), которые выдают объекты, экспонирующие MINA интерфейсы ProtocolEncoder и ProtocolDecoder. Кодирующий объект специфического протокола экспонирует интерфейс ProtocolEncoder, а декодирующий объект экспонирует интерфейс ProtocolDecoder.

Кодирование и декодирование в MINA

Инфраструктура ApacheDS использует экземпляр класса ProtocolDecoder конкретного протокола для декодирования запроса протокола таким образом, чтобы можно было распознать его прежде, чем начать обработку запроса. После декодирования ApacheDS обрабатывает запрос. Например, если запросом был поиск LDAP, ApacheDS будет осуществлять поиск запрошенных данных во внутренней службе каталога и сортировку результатов поиска. После нахождения требуемых результатов поиска, инфраструктура ApacheDS использует объект конкретного протокола ProtocolEncoder для кодирования результатов поиска. В случае поиска LDAP ApacheDS будет использовать ProtocolEncoder LDAP объект для кодирования результатов поиска прежде, чем отправить ответ автору запроса.

Инфраструктура служб MINA

MINA также имеет классы для обработки служб. Любая системная служба может зарегистрироваться в сервисе реестра, а система доступа протокола будет зарегистрирована вместе с классами системы доступа, которая обеспечивает сервис. Затем система доступа протокола преобразовывает запросы протокола в действия JNDI. Простым примером является LDAP запрос поиска, преобразованный в действия поиска JNDI. Как только инфраструктура ApacheDS распознает, какое действие JNDI необходимо запустить во время обработки запроса протокола, то она может генерировать событие. Инфраструктура обработки события в MINA посылает событие к соответствующему обработчику. Например, если запрос требует запуска поискового действия JNDI, запускается обработчик поиска. MINA также поддерживает накопитель порождаемых процессов. Если обработчик занят выполнением предыдущей операции, событие временно хранится в накопителе порождаемых процессов до тех пор, пока оно не будет обработано. Вы можете увидеть системы доступа протокола, интерфейсы и классы MINA, и обработчики действий, работающих с JNDI на Рисунке 2. Вероятно, главным преимуществом ApacheDS инфраструктуры является использование общей службы каталога (JNDI) для различных систем доступа к протоколам. Это означает, что вы можете использовать ApacheDS для экспонирования ваших данных клиентам, используя различные протоколы. Поскольку одним из наиболее важных протоколов, поддерживаемых ApacheDS, является LDAP (и поскольку вы будете использовать ApacheDS прежде всего как LDAP-сервер для хранения объектов Java)

Обзор LDAP

LDAP-протокол распознает команды запроса и ответа для действий каталога. Действия каталога подразумевают хранение новых данных в каталоге, поиск и извлечение хранящихся данных, удаление ненужных данных, обновление устаревших данных и тому подобные действия. (См. Resources для RFC 2251, официальное описание LDAP, которая содержит команды запроса и ответа для хранения, извлечения, обновления и удаления данных в каталоге LDAP.) Команда LDAP, которую вы используете для хранения новых данных (например, вашего действующего Java-объекта) в ApacheDS, называется bind (связать). Она передает данные пользователя в службу каталога LDAP, например ApacheDS, и хранит (или накапливает) данные в каталоге. Для LDAP не имееет значения фактическое месторасположение хранилища данных. Вместо этого LDAP указывает Distinguished Name (Уникальное Имя - DN) для каждой учетной записи, хранящейся в ApacheDS. Каждое DN должно быть однозначно определяемым внутри службы каталога. Существование двух учетных записей с одинаковым DN невозможно. Вы узнаете о механизме LDAP, используемом для обеспечения единичности каждого DN, далее из раздела. Кроме того, поисковый механизм LDAP использует имена DN.

Установка

Для работы Apache Geronimo необходимо наличие Java

Установка java:

sudo apt-get install default-jre

Необходимо задавать переменные JAVA_HOME, JRE_HOME, JAVA_OPTS. Для этого в ~/.bashrc пропишем:

vi ~/.bashrc
...
export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
export JRE_HOME=/usr/lib/jvm/java-7-openjdk-amd64/jre
export JAVA_OPTS=
...

Скачиваем с http://directory.apache.org/studio/downloads.html Apache Directory и устанавливаем загруженный пакет

sudo dpkg -i apacheds-<version>.deb

И запускаем загрузочный скрипт

sudo /etc/init.d/apacheds-<version> start

Для работы с Apache Directory Server можно использовать Apache Directory Studio

Скачиваем c http://directory.apache.org/studio/downloads.html Apache Directory Studio

Распаковываем загруженный архив

tar xvf ApacheDirectoryStudio-<version>.tar.gz

Переходим в распакованную директорию

cd ./ApacheDirectoryStudio/

Запускаем ApacheDirectoryStudio

./ApacheDirectoryStudio

Создаем новое подключение: LDAP->New Connection

Bind DN or user: uid=admin,ou=system
Bind password: secret

Литература

  1. ApacheDS-official site [Электронный ресурс]: Официальный сайт ApacheDS / Дата обращения: 28.12.2016. — Режим доступа: http://directory.apache.org/
  2. IBM - official site [Электронный ресурс]: Хранение объектов Java в Apache Directory Server / Дата обращения: 28.12.2016. — Режим доступа: http://www.ibm.com/developerworks/ru/library/j-apacheds1/index.html