Spec-Zone .ru спецификации, руководства, описания, API

Содержание документации

LDAP, Называющий Поставщика услуг для
Именование Java и Каталог Interface™ (JNDI)

Оглавление

1. Введение
2. Соответствие
3. Свойства среды
4. Имена
5. Атрибуты
6. URL
7. Объекты Java
8. Схема
9. Исключения
10. Отображение API
11. Федерация
12. Уведомление о событии
13. Аутентификация SASL
14. SSL и Запускает TLS
15. Объединение в пул соединения
16. Соображения безопасности

1. Введение

Этот документ описывает функции поставщика услуг LDAP. Главная часть описания выражается с точки зрения того, как поставщик услуг LDAP ведет себя относительно описаний в Инструкциях для Поставщиков услуг LDAP. Для примеров и описаний того, как использовать этого провайдера, пожалуйста см. Учебное руководство JNDI.

Поставщик услуг LDAP реализует основные характеристики для доступа LDAP. Дополнительная функциональность, такая как поддержка многих популярных средств управления LDAP, и хранения и чтения RMI и объектов CORBA, может быть добавлена к основному провайдеру, устанавливая пакет усилителя, доступный для скачивания на Веб-сайте JNDI.

2. Соответствие

3. Свойства среды

3.1 Свойства JNDI

3.2 LDAP-специфичные Свойства

3.3 SASL-специфичные Свойства

3.4 Специфичные для провайдера Свойства

com.sun.jndi.ldap.connect.pool

Это свойство используется, чтобы определить, что объединенное в пул соединение должно использоваться, создавая начальный экземпляр контекста. Если его значение будет "истиной", то провайдер будет использовать объединенное в пул соединение, если параметры для того, чтобы создать соединение (называемый запросом соединения) будут соответствовать критериям, сформулированным конфигурацией пула соединения. Если это свойство не было установлено, или если оно было установлено в какое-либо другое значение, или если запрос соединения не будет соответствовать критериям, то провайдер не будет использовать объединенное в пул соединение. См., что Соединение Объединяет раздел в пул для получения дополнительной информации об объединении в пул соединения.

Например, следующий код

env.put("com.sun.jndi.ldap.connect.pool",
"true");

ОТМЕТЬТЕ: На системах ранее чем Java 2 SDK, v 1.4.1, объединение в пул соединения не поддерживаются и поэтому, это свойство игнорируется.

com.sun.jndi.ldap.connect.timeout

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

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

Например,

env.put("com.sun.jndi.ldap.connect.timeout", "500"); заставляет поставщика услуг LDAP прерывать попытку подключения, если соединение не может быть установлено через половину секунды.

Когда объединение в пул соединения требовали на соединение, это свойство также определяет максимальное время ожидания для соединения, когда все соединения в пуле используются, и максимальный размер пула был достигнут. Если значение этого свойства будет меньше чем или равно, чтобы обнулить при таких обстоятельствах, то провайдер будет ожидать неопределенно соединения, чтобы стать доступным; иначе, провайдер прервет ожидание, когда максимальное время ожидания было превышено. См., что Соединение Объединяет раздел в пул для деталей.

ОТМЕТЬТЕ: На системах ранее чем Java игнорируются 2 SDK, v 1.4, это свойство, потому что нет никакой поддержки в SDK для тайм-аутов соединения.

com.sun.jndi.ldap.read.timeout

Значение этого свойства является строковым представлением целого числа, представляющего тайм-аут чтения в миллисекундах для операций LDAP. Если провайдер LDAP не может получить ответ LDAP в пределах того периода, он прерывает попытку чтения. Целое число должно быть больше чем нуль. Целое число, меньше чем или равное, чтобы обнулить средства, никакой тайм-аут чтения не определяется, который эквивалентен ожиданию ответа бесконечно, пока это не получается.

Если это свойство не определяется, значение по умолчанию должно ожидать ответа, пока это не получается.

Например,

env.put("com.sun.jndi.ldap.read.timeout", "5000"); заставляет поставщика услуг LDAP прерывать попытку чтения, если сервер не отвечает ответом в течение 5 секунд.

ОТМЕТЬТЕ: На системах ранее чем SDK Java, v 6.0, игнорируется это свойство, потому что нет никакой поддержки в SDK для тайм-аутов чтения.

com.sun.jndi.ldap.netscape.schemaBugs

Сервер каталогов 4.0 Netscape и более ранние выпуски не поддерживают записи схемы, которые выполняют RFC 2252. Определенно, противоречащий RFC 2252, сервер Netscape требует, чтобы OID (такие как те для ГЛОТКА и СИНТАКСИСА) были разграничены одинарными кавычками, и списки быть включенными круглыми скобками. Когда Вы обновляете схему Сервера каталогов 4.0 Netscape, Вы должны использовать это свойство, чтобы обойти эти проблемы.

Следующие значения определяются для этого свойства:

       true
          активируйте обходное решение.
       false
          не активируйте обходное решение.

Если это свойство не устанавливается тогда, его значением по умолчанию является false.

Например,

env.put("com.sun.jndi.ldap.netscape.schemaBugs", "true");

ОТМЕТЬТЕ 1: Это свойство можно только передать к начальному контексту и становится фиксированным для провайдера. Это незатронуто методами addToEnvironment ИЛИ removeFromEnvironment.

ОТМЕТЬТЕ 2: Если Вы используете Сервер каталогов 4.1 Netscape, не используйте это свойство. У 4.1 серверов есть проблемы, анализируя определения класса объекта, которые содержат, пункты без круглых скобок. Если Вы создаете или изменяете определение класса объекта, которое содержит сингл, элемент, работа вокруг ошибки, добавляя, что лишнее значение (такое как 'objectClass') к ДОЛЖНО перечислить.

com.sun.jndi.ldap.trace.ber

Значение этого свойства является объектом java.io.OutputStream, в который пишется шестнадцатеричный дамп поступления и выхода LDAP ASN.1 пакеты BER. Никакое значение по умолчанию не определяется для этого свойства.

Например,

env.put("com.sun.jndi.ldap.trace.ber",
System.out);

ОТМЕТЬТЕ: Это свойство можно только передать к начальному контексту и становится фиксированным для провайдера. Это незатронуто методами addToEnvironment ИЛИ removeFromEnvironment.

4. Имена

Синтаксический анализатор имени, возвращенный вызовом getNameParser(), возвращает синтаксический анализатор, который, когда дано имя строки, анализирует это в компоненты в соответствии с RFC 2253.

5. Атрибуты

Некоторые серверы LDAP поддерживают выделение подтипов атрибута, синонимы названия атрибута, и коды языка для того, чтобы определить предпочтение языка значениям атрибута. В таких случаях название атрибута, возвращенное сервером LDAP, может отличаться от того, которое требовали.

В LDAP названия атрибута являются нечувствительными к регистру. Поэтому, создавая набор атрибутов, которые передадут в качестве параметра к операциям JNDI, рекомендуется использовать нечувствительный к регистру класс атрибутов. Например,

       Attributes attrs = new BasicAttributes(true); // ignoreCase=true

Для всех значений атрибута, независимо от того, являются ли они String или byte[], Вы должны знать синтаксис и формат значения атрибута. Можно обычно узнавать это, читая документ схемы, в котором определяются атрибут и его синтаксис.

Когда атрибуты предоставляются как параметры вызовам JNDI тогда, они должны удовлетворить, любая схема осуществляется в каталоге LDAP. В частности атрибут objectClass обычно требуется, создавая новую запись LDAP (например, при использовании Context.bind, Context.rebind или DirContext.createSubcontext).

6. URL

6.1 Использование

Это поддерживает следующее использование URL:
 

ОТМЕТЬТЕ: На системах ранее чем Java 2 SDK, v 1.4.2, поставщик услуг LDAP не распознает или возвращает URL LDAPS.

6.2 Автоматическое Открытие Службы LDAP

Например, учитывая URL ldap:///dc=example,dc=com, поставщик услуг попытается определить местоположение DNS записи SRV для _ldap._tcp.example.com. Если провайдер найдет такие записи, то он будет тогда извлекать и использовать имена хоста и порты серверов LDAP от записей. Порядок, в котором это использует эти записи, следует за алгоритмом, описанным в интернет-проекте draft-ietf-ldapext-locate-08.txt.

Для того, чтобы определить местоположение DNS записи SRV службы LDAP, поставщик услуг LDAP использует службу DNS, сконфигурированную для базовой платформы (на Солярисе или Linux, например, клиентская конфигурация DNS читается из/etc/resolv.conf файла). Если DNS не был сконфигурирован для базовой платформы, поставщик услуг LDAP будет использовать localhost и 53 как имя хоста и порт сервера DNS. Если никакая служба DNS не будет доступна, или если у службы DNS не будет записей SRV службы LDAP, то поставщик услуг LDAP будет использовать localhost в качестве имени хоста, и 389 как порт для простого соединения и 636 как порт для соединения SSL.

ОТМЕТЬТЕ 1: На системах ранее чем Java 2 SDK, v 1.4.1, неуказанное имя хоста и порт всегда значение по умолчанию к localhost и 389, соответственно; никакая попытка не предпринимается, чтобы использовать DNS.

ОТМЕТЬТЕ 2: На системах ранее чем Java 2 SDK, v 1.4.2, порт по умолчанию всегда 389 независимо от того, используется ли SSL.

7. Объекты Java

См. Учебное руководство JNDI для примеров.

8. Схема

9. Исключения

10. Отображение API

11. Федерация

Поставщик услуг LDAP обрабатывает составные имена как строго разделено. Таким образом, это обрабатывает первый компонент составного имени как отличительное имя и остальная часть компонентов как имена в следующей системе (ах) именования. Например, вот примеры, который перечисляет корень следующей системы именования, объединенной в федерацию вне контекста LDAP, и ищет имя, используя многокомпонентное составное имя:

// List the root of the nns, 
// Note use of the trailing slash to indicate traversal into the nns
NamingEnumeration enum = ctx.list("cn=objects,ou=Sales/");

// A composite name lookup
Object obj = ctx.lookup("cn=objects,ou=Sales/some/x/y/z");

12. Уведомление о событии

* персистентное поисковое управление определяется в Интернет-проекте IETF draft-ietf-ldapext-psearch-03.txt.

13. Аутентификация SASL

Поставщик услуг LDAP поддерживает следующие механизмы SASL.

• ВНЕШНИЙ (RFC 2222). Этот механизм получает информацию об аутентификации из внешнего источника (такого как SSL/TLS или IPsec).
• ОБЗОР-MD5 (RFC 2831) для Дайджест-аутентификации.
• GSSAPI (RFC 2222) является для Kerberos аутентификацией V5.

14. SSL и Запускает TLS

14.1 SSL

Когда SSL используется, и никакой порт не был определен, 636 используется в качестве порта по умолчанию.

ОТМЕТЬТЕ: На Java 2 SDK, v 1.4.1 и более ранние системы, порт по умолчанию всегда 389, независимо от того, используется ли SSL.

14.2 Запустите TLS

15. Объединение в пул соединения

ОТМЕТЬТЕ: объединение в пул Соединения поддерживается только на Java 2 SDK, v 1.4.1 и более поздние выпуски.

15.1 Краткий обзор

Поставщик услуг LDAP поддерживает объединение в пул соединения, поддерживая пулы ранее используемых соединений. Всякий раз, когда провайдер LDAP нуждается в соединении (и приложение запросило объединение в пул), это получает соединение от пула. Если существующее соединение будет доступно, то оно будет использоваться. Если никакое существующее соединение не доступно, новое соединение создается и используется. Когда провайдер делается с соединением, соединение отмечается неактивное и может быть снова использовано.

Приложение запрашивает объединение в пул соединения, добавляя свойство, com.sun.jndi.ldap.connect.pool, к свойствам среды, которые передают начальному конструктору контекста. Приложение может решить, использовать ли объединение в пул на основе на контекст при использовании свойств среды с и без этого свойства. Этот тот же самый механизм используется, чтобы управлять, используются ли объединенные в пул соединения для обработки отсылки и обработки URL LDAP/LDAPS, которые передают к начальному контексту. Например, когда это свойство присутствует в среде, когда провайдер обработает отсылку, провайдер будет использовать объединенное в пул соединение для отсылки.

Вот пример кода, который запрашивает, чтобы объединение в пул соединения использовалось для нового начального контекста и всех контекстов, полученных из него.

Hashtable env = new Hashtable();
env.put("com.sun.jndi.ldap.connect.pool", "true");
env.put(Context.PROVIDER_URL, url);
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
DirContext ctx = new InitialDirContext(env);
...

Только добавление единственного свойства, com.sun.jndi.ldap.connect.pool, требуется; никакие другие изменения не приложение обязаны.

Провайдер LDAP отслеживает то, используется ли соединение посредством индикаций из приложения. Это предполагает, что приложение, которое поддерживает открытый дескриптор контекста, использует соединение. Поэтому, для провайдера LDAP, чтобы должным образом управлять объединенными в пул соединениями, приложение должно быть прилежным о вызове Context.close() на контекстах, в которых это больше не нуждается.

Плохие соединения автоматически обнаруживаются и удаляются из пула. Вероятность контекста, заканчивающегося с плохим соединением, является тем же самым независимо от того, используется ли объединение в пул соединения.

15.2 Если не Использовать Объединение в пул

15.3 Глобальная Конфигурация

Объединение в пул соединения конфигурируется многими свойствами System во время запуска времени выполнения. Отметьте, что они - свойства System, не свойства среды и что они влияют на все запросы объединения в пул соединения.

Вот сводка системных свойств. Они описываются более подробно в остальной части этого раздела.

Вот пример, который устанавливает максимальный размер пула в 20, привилегированный размер пула к 10, и неактивный тайм-аут к 5 минутам для объединенных в пул соединений.

# java -Dcom.sun.jndi.ldap.connect.pool.maxsize=20 \
       -Dcom.sun.jndi.ldap.connect.pool.prefsize=10 \
       -Dcom.sun.jndi.ldap.connect.pool.timeout=300000 \
    YourProgram

15.3.1 Что Объединяется в пул

Чтобы позволить соединениям SSL быть объединенными в пул, включайте строку "ssl" в свойство com.sun.jndi.ldap.connect.pool.protocol System. Например, чтобы позволить и плоскости и соединениям SSL, которые будет объединяться в пул, устанавливает это свойство System в строку "plain ssl".

Чтобы позволить соединениям ОБЗОРА-MD5 быть объединенными в пул, включайте строку "DIGEST-MD5" в свойство com.sun.jndi.ldap.connect.pool.authentication System. Например, чтобы позволить соединениям анонимных, простых и типов аутентификации ОБЗОРА-MD5, которые будут объединяться в пул, устанавливает это свойство System в строку "none simple DIGEST-MD5".

15.3.2 Как Соединения Объединяются в пул

Идентификационные данные соединения являются набором параметров, требуемых создать возможно аутентифицируемое соединение LDAP. Его состав зависит от типа аутентификации запроса, как показано в следующей таблице.

15.3.3 Объединение в пул Пользовательских Соединений Фабрики Сокета

    public class CustomSocketFactory extends SocketFactory
                implements Comparator<SocketFactory> { 
       :
       :
       public int compare(SocketFactory sf1, SocketFactory sf2) {
           :
           :
           // do whatever comparison that's required
       }
    }

Если класс фабрики сокета не реализует интерфейс Компаратора, соединения от того класса фабрики сокета не становятся объединенными в пул. Это требование для того, чтобы реализовать интерфейс Компаратора должно гарантировать, что Поставщик услуг LDAP делает необходимые проверки, сравнивая соединения от различных фабрик сокета, реализация которых не известна провайдеру.

15.3.4 Размеры пула

Начальный размер пула является числом соединений идентификационные данные для каждого подключения, которые создает поставщик услуг LDAP, сначала создавая пул (который соответствует когда приложение первые запросы объединенное в пул соединение для тех идентификационных данных соединения). Аутентификация каждого соединения в пуле выполняется по требованию, поскольку соединение привыкает. По умолчанию начальный размер пула 1 и может быть изменен при использовании свойства System com.sun.jndi.ldap.connect.pool.initsize. Это обычно привыкло во время запуска приложения к главному пул с определенным числом соединений с сервером.

Максимальный размер пула является максимальным количеством соединений идентификационные данные для каждого подключения, которые могут сохраняться одновременно поставщиком услуг LDAP. И в использовании и неактивные соединения способствуют этому числу. Когда размер пула достигает этого числа, никакое новое соединение для соответствующих идентификационных данных соединения не может быть создано, пока соединение в пуле не было удалено (то есть, физическое соединение закрывается). Когда размер пула достигает максимума, и все соединения в пуле используются, запрос приложения на соединение от того пула блокируется до соединения в пуле или становится неактивным или удаляется. Максимальный размер пула 0 средств, что нет никакого максимального размера: запрос на объединенное в пул соединение будет использовать существующее объединенное в пул неактивное соединение или недавно создаваемое объединенное в пул соединение.

Привилегированный размер пула является привилегированным числом соединений идентификационные данные для каждого подключения, которые должен поддержать поставщик услуг LDAP. И в использовании и неактивные соединения способствуют этому числу. Когда приложение запрашивает использование объединенного в пул соединения, и размер пула является меньше чем привилегированный размер, провайдер LDAP будет создавать и использовать новое объединенное в пул соединение независимо от того, является ли неактивное соединение availble. Когда приложение заканчивается с объединенным в пул соединением (вызывая Context.close() на все контексты, которые совместно используют соединение), и размер пула больше чем привилегированный размер, провайдер LDAP закроет и удалит объединенное в пул соединение из пула. Привилегированный размер пула 0 средств, что нет никакого привилегированного размера: запрос на объединенное в пул соединение приведет к недавно создаваемому соединению, только если никакие неактивные не доступны.

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

15.3.5 Неактивные Соединения

15.4 Конфигурация на контекст

15.4.1 Включение Объединению в пул

Если это свойство будет опущено, то контекст не будет использовать объединение в пул соединения.

15.4.2 Тайм-аут соединения

Если это свойство не было определено, провайдер LDAP будет ожидать неопределенно объединенного в пул соединения, чтобы стать доступным, и ожидать тайм-аута TCP по умолчанию, чтобы вступить в силу, создавая новое соединение.

Отметьте, что это свойство отличается от свойства System com.sun.jndi.ldap.connect.pool.timeout, который связывается с удалением неактивных объединенных в пул соединений.

16. Соображения безопасности

permission java.net.SocketPermission "host[:port]", "connect";

Для каждого узла/порта, идентифицированного в свойстве java.naming.factory.initial и на названия строк URL, предоставленные методам контекста.

permission java.net.SocketPermission "host[:port]", "connect,accept";

Поскольку каждый узел/порт, названный в URL, представляет в виде строки в References и атрибутах javaCodebase, сохраненных объектами Serializable.

permission java.lang.RuntimePermission "setFactory"

permission javax.security.auth.AuthPermission "createLoginContext.appClassName";
permission javax.security.auth.AuthPermission "doAsPrivileged";

Для класса приложений это собирается войти в систему и вызвать метод doAsPrivileged.

permission java.net.SocketPermission "host[:port]", "connect";

Для узла/порта Центра распределения ключей Kerberos (KDC).

permission javax.security.auth.kerberos.ServicePermission "krbtgt/realm@realm", "initiate";
permission javax.security.auth.kerberos.ServicePermission "ldap/fully-qualified-hostname@realm", "initiate";

Для области и узла службы LDAP и KDC.

---

Авторское право © 1993, 2011, Oracle и/или его филиалы. Все права защищены.

Свяжитесь с Нами