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) является интернет-стандартом для того, чтобы получить доступ к службам каталогов. Поставщик услуг JNDI/LDAP обеспечивает доступ к серверам, реализовывая протоколы LDAP.

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

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


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

Поставщик услуг LDAP соответствует следующим стандартам:
 
Стандарт Поддерживаемый Комментарии
LDAPv3 (RFC 2251) Да  
Атрибуты LDAPv3 (RFC 2252) Да  
Отличительные имена LDAPv3 (RFC 2253) Да  
Фильтры Поиска LDAP (RFC 2254) Да  
LDAP Формат URL (RFC 2255) Да  
Схема LDAPv3 (RFC 2256) Да  
LDAPv2 (RFC 1777) Да  
Аутентификация LDAP (RFC 2829) Да  
Запустите Расширение TLS (RFC 2830) Да  
ОБЗОР-MD5 (RFC 2831) Да  
Управляйте Управлением Отсылкой (RFC 3296) Да  
Пронумерованное страницы Управление Результатами (RFC 2696) Да  
Управление видом (RFC 2891) Да  

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

Описания JNDI, LDAP-специфичного, и свойства SASL-specific, находятся в Направляющих линиях для Поставщиков услуг LDAP.

3.1 Свойства JNDI

Поставщик услуг LDAP поддерживает следующие свойства среды JNDI:
 
Свойство Поддерживаемый Комментарии
java.naming.batchsize Да Значением по умолчанию является 1.
java.naming.factory.control Да  
java.naming.factory.initial Да Определите com.sun.jndi.ldap.LdapCtxFactory, чтобы использовать поставщика услуг LDAP в качестве начального контекста.
java.naming.factory.object Да  
java.naming.factory.state Да  
java.naming.language Нет Проигнорированный провайдером.
java.naming.provider.url Да На системах ранее чем Java 2 SDK, v 1.4.1, могут содержать только единственный URL. На системах ранее чем Java 2 SDK, v 1.4.2, не могут содержать URL LDAPS.
java.naming.referral Да  
java.naming.security.authentication Да simple, none, список механизмов SASL
java.naming.security.credentials Да  
java.naming.security.principal Да  
java.naming.security.protocol Да ssl

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

Провайдер поддерживает следующие LDAP-специфичные свойства среды:
 
Свойство Поддерживаемый Комментарии
java.naming.ldap.attributes.binary Да  
java.naming.ldap.control.connect Да  
java.naming.ldap.deleteRDN Да  
java.naming.ldap.derefAliases Да  
java.naming.ldap.factory.socket Да Значением по умолчанию является javax.net.ssl.SSLSocketFactory, когда  свойство java.naming.security.protocol устанавливается в ssl. См. Раздел SSL для деталей.
java.naming.ldap.ref.separator Да  
java.naming.ldap.referral.limit Да  
java.naming.ldap.typesOnly Да  
java.naming.ldap.version Да  

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

Провайдер поддерживает следующие SASL-специфичные свойства среды:
 
Свойство Поддерживаемый Комментарии
java.naming.security.sasl.authorizationId Да  
java.naming.security.sasl.callback Да  
java.naming.security.sasl.realm Да  
javax.security.sasl.qop Да  
javax.security.sasl.strength Да Выбранный шифр зависит от шифров, доступных от Расширения Криптографии Java (JCE) поставщики услуг в платформе Java.
javax.security.sasl.maxbuffer Да  
javax.security.sasl.server.authentication Да  
javax.security.sasl.policy.forward Да  
javax.security.sasl.policy.credentials Да  
javax.security.sasl.policy.noplaintext Да  
javax.security.sasl.policy.noactive Да  
javax.security.sasl.policy.nodictionary Да  
javax.security.sasl.policy.noanonymous Да  

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

Поставщик услуг LDAP определяет следующие специфичные для провайдера свойства среды:
 
com.sun.jndi.ldap.connect.pool

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

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

env.put("com.sun.jndi.ldap.connect.pool",
"true");
направляет провайдера LDAP, чтобы использовать объединенное в пул соединение, создавая начальный контекст.

ОТМЕТЬТЕ: На системах ранее чем 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 серверов есть проблемы, анализируя объектные определения class, которые содержат, пункты без круглых скобок. Если Вы создаете или изменяете объектное определение class, которое содержит сингл, элемент, работа вокруг ошибки, добавляя, что лишнее значение (такое как 'objectClass') к ДОЛЖНО перечислить.

com.sun.jndi.ldap.trace.ber

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

Например,

env.put("com.sun.jndi.ldap.trace.ber",
System.out);
предписывает, чтобы протокол LDAP проследил до потока стандартного вывода.

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


4. Имена

Поставщик услуг LDAP поддерживает имена в соответствии с описанием в Направляющих линиях для Поставщиков услуг LDAP. Это поддерживает отличительные имена LDAP в следующих форматах:
 
Формат Отличительного имени Комментарии
String Обработка как составное имя. Обработайте первый компонент составного имени как отличительное имя. Используйте отдых компонентов для федерации.
Name Если экземпляр CompositeName, обработайте как составное имя, что означает процесс первый компонент составного имени как отличительное имя, и используйте остальных для федерации. Иначе, обработайте как анализирующийся имя LDAP, где каждый компонент Name является компонентом имени LDAP как определено в RFC 2253.
LDAP Строка URL Когда передано к начальному контексту, строка URL LDAP интерпретируется согласно RFC 2255, и его компоненту отличительного имени, интерпретируемому согласно RFC 2253.
LDAPS Строка URL Когда передано к начальному контексту, строка URL LDAPS интерпретируется как URL LDAP, за исключением того, что соединение SSL используется, чтобы связаться с сервером.

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

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


5. Атрибуты

Поставщик услуг LDAP поддерживает атрибуты в соответствии с описанием в Направляющих линиях для Поставщиков услуг LDAP. Это поддерживает следующие форматы для того, чтобы определить значения атрибута LDAP:
 
Формат значения атрибута Поддерживаемый Комментарии
Значения String Да  
Значения byte[] Да  

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

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

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

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

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


6. URL

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

Поставщик услуг LDAP поддерживает URL в соответствии с описанием в Направляющих линиях для Поставщиков услуг LDAP. Это поддерживает и LDAP и URL LDAPS.

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

Использование URL Поддерживаемый Комментарии
LDAP и URL LDAPS, чтобы сконфигурировать поставщика услуг LDAP. Да  
URL, которые передают как имена к методам InitialDirContext. Да  
URL в отсылках LDAP Да Компонент контекста URL LDAP/LDAPS поддерживается. Атрибуты, фильтр и компоненты расширений игнорируются.
URL, возвращенные как имена в list, listBindings, и перечислениях search. Да  
URL, соединяющие объединенные в федерацию пространства имен. Да  

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

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

Поставщик услуг LDAP поддерживает использование конфигурации DNS для того, чтобы автоматически обнаружить службу LDAP. Когда URL LDAP/LDAPS в вышеупомянутых случаях использования пропустит имя узла и порт, но имеет непустое отличительное имя, поставщик услуг LDAP попытается определить местоположение серверов LDAP, чтобы использовать как описано в Направляющих линиях для Поставщиков услуг 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

Поставщик услуг LDAP поддерживает хранение и чтение следующих типов объектов, как определено в Направляющих линиях для Поставщиков услуг LDAP.
 
Объекты Storable/Readable Поддерживаемый Комментарии
Объекты Reference Да  
Объекты Referenceable Да  
Объекты Serializable Да  
Объекты DirContext Да  

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


8. Схема

Поставщик услуг LDAP поддерживает следующую привязку схемы, как определено в Направляющих линиях для Поставщиков услуг LDAP.
 
Дерево схемы Поддерживаемый Комментарии
AttributeDefinition Да  
ClassDefinition Да  
SyntaxDefinition Да  
MatchingRule Да  
ExtensionDefinition Нет  
ControlDefinition Нет  
SASLMechanism Нет  

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

Поставщик услуг LDAP отображает коды ошибки LDAP на исключения JNDI согласно Направляющим линиям для Поставщиков услуг LDAP.
 

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

Поставщик услуг LDAP отображает следующие методы API JNDI на LDAP согласно Направляющим линиям для Поставщиков услуг LDAP:
 
Отображение для методов Context Поддерживаемый Комментарии
addToEnvironment Да  
bind Да  
close Да  
composeName Да  
destroySubcontext Да  
getEnvironment Да  
getNameInNamespace Да  
getNameParser Да  
list Да  
listBindings Да  
lookup Да Не обрабатывает LinkRef особенно.
lookupLink Да  
rebind Да  
removeFromEnvironment Да  
rename Да  
unbind Да  
Отображение для методов DirContext Поддерживаемый Комментарии
bind Да  
createSubcontext Да  
destroySubcontext Да  
getAttributes Да  
getSchema Да  
getSchemaClassDefinition Да  
modifyAttributes Да  
rebind Да  
search Да  
Отображение для методов LdapContext Поддерживаемый Комментарии
extendedOperation Да  
getRequestControls Да  
getResponseControls Да  
newInstance Да  
reconnect Да  
setRequestControls Да  
Отображение для методов EventDirContext Поддерживаемый Комментарии
addNamingListener Да  
removeNamingListener Да  
targetMustExist Да  

11. Федерация

Поставщик услуг LDAP поддерживает федерацию в соответствии с описанием в Направляющих линиях для Поставщиков услуг LDAP. Это поддерживает следующие методы федерации:
 
Метод федерации Поддерживаемый Комментарии
Стык Да Кроме тех случаев, когда зависимая система именования является другой системой LDAP
Неявный Следующий Системный Указатель Именования Да  
 

Поставщик услуг 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. Уведомление о событии

Поставщик услуг LDAP поддерживает уведомление о событии в соответствии с описанием в Направляющих линиях для Поставщиков услуг LDAP. Это поддерживает следующие события:
 
Событие Поддерживаемый Комментарии
Уведомление об изменении пространства имен Да Использует персистентный поиск control*
Объектное уведомление об изменении Да Использует персистентный поиск control*
Незапрашиваемое уведомление Да  

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


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

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

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

В дополнение к этим механизмам провайдер поддерживает дополнительные механизмы SASL, сделанные доступный через платформу, определенную в Java API SASL (JSR 28 Общедоступных Проектов Анализа), за исключением того, что пакет называют com.sun.security.sasl.preview вместо javax.security.sasl.

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

14.1 SSL

Поставщик услуг LDAP поддерживает SSL в соответствии с описанием в Направляющих линиях для Поставщиков услуг LDAP. Это использует фабрику сокета значения по умолчанию javax.net.ssl.SSLSocketFactory, если  свойство java.naming.ldap.factory.socket не было установлено в имя class некоторой другой фабрики сокета.

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

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

14.2 Запустите TLS

Провайдер LDAP поддерживает, "Запускают TLS" расширение ("1.3.6.1.4.1.1466.20037"), предоставляя конкретную реализацию краткого обзора StartTlsResponse class. Проверка имени узла выполняется согласно Направляющим линиям для Поставщиков услуг LDAP.

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 Если не Использовать Объединение в пул

Объединенные в пул соединения предназначаются, чтобы быть снова использованными. Поэтому, приложение, которое планирует выполнение операций на контексте, который мог бы изменить состояние базового соединения, не должно использовать объединение в пул соединения для контекста. Определенно, если приложение планирует использовать TLS Запуска расширенная работа на контексте, или планирует изменить связанные с безопасностью свойства (такие как java.naming.security.principal или java.naming.security.protocol) после того, как начальный контекст был создан, это не должно использовать объединение в пул соединения для того контекста. Используя объединение в пул соединения при таких обстоятельствах мог бы поставить под угрозу безопасность приложения и/или создать неожиданное поведение.

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

Объединение в пул соединения конфигурируется и сохраняется на Среду выполнения Java. Соединения не совместно используются через различные времена выполнения. Чтобы использовать объединение в пул соединения, никакая конфигурация не требуется. Конфигурация необходима, только если Вы хотите настроить, как объединение в пул делается, такие как управление размером пулов и какие соединения объединяются в пул.

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

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

Системное Имя Свойства Описание Значение по умолчанию
com.sun.jndi.ldap.connect.pool.authentication Список разделенных пробелом типов аутентификации соединений, которые могут быть объединены в пул. Допустимые типы не "ни один", "простой", и "ОБЗОР-MD5". "none simple"
com.sun.jndi.ldap.connect.pool.debug Строка, которая указывает на уровень вывода отладки, чтобы произвести. Допустимыми значениями является "fine" (создание соединения трассировки и удаление) и "все" (вся отладочная информация).  
com.sun.jndi.ldap.connect.pool.initsize Строковое представление целого числа, которое представляет число соединений идентификационные данные для каждого подключения, чтобы создать, первоначально создавая соединение для идентификационных данных. 1
com.sun.jndi.ldap.connect.pool.maxsize Строковое представление целого числа, которое представляет максимальное количество соединений идентификационные данные для каждого подключения, которые могут сохраняться одновременно. никакой максимальный размер
com.sun.jndi.ldap.connect.pool.prefsize Строковое представление целого числа, которое представляет привилегированное число соединений идентификационные данные для каждого подключения, которые должны сохраняться одновременно. никакой привилегированный размер
com.sun.jndi.ldap.connect.pool.protocol Список разделенных пробелом типов протокола соединений, которые могут быть объединены в пул. Допустимые типы "просты" и "ssl". "plain"
com.sun.jndi.ldap.connect.pool.timeout Строковое представление целого числа, которое представляет число миллисекунд, которыми неактивное соединение может остаться в пуле, не будучи закрытым и удаленный из пула. никакой тайм-аут

Вот пример, который устанавливает максимальный размер пула в 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 Что Объединяется в пул

Провайдер LDAP будет использовать объединенное в пул соединение, только если приложение запросило это, и запрос на соединение соответствует критериям объединения в пул. Приложение запрашивает, чтобы соединение было объединено в пул при использовании свойства среды com.sun.jndi.ldap.connect.pool. Критерии объединения в пул значения по умолчанию - то, что плоскости (не-SSL) соединения, которые используют простой или никакая аутентификация, позволяют быть объединенной в пул. Критерии объединения в пул могут быть скорректированы, чтобы включать соединения SSL и тип аутентификации ОБЗОРА-MD5 при использовании свойств System. Соединение, которое включило трассировке протокола (через свойство среды com.sun.jndi.ldap.trace.ber) не может быть объединено в пул. Для того, чтобы объединить соединения в пул от пользовательской фабрики сокета см. Объединяющие в пул Пользовательские Соединения Фабрики Сокета

Чтобы позволить соединениям 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 поддерживает объединенные в пул соединения так, чтобы они могли быть снова использованы. Когда приложение запрашивает использовать объединенное в пул соединение, провайдер LDAP должен определить, может ли запрос быть удовлетворен существующим объединенным в пул соединением. Это делает это, присваивая идентификационные данные соединения каждому объединенному в пул соединению и проверяя, есть ли у входящего запроса те же самые идентификационные данные соединения как то из одного из его объединенных в пул соединений.

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

Тип аутентификации Содержание идентификационных данных соединения
ни один
  • средства управления соединением
  • имя узла, номер порта и схема как определено в свойстве java.naming.provider.url, отсылке, или URL, предоставленном начальному контексту
  • содержание следующих свойств:
    java.naming.security.protocol
    java.naming.ldap.version
    
простой
  • вся информация, перечисленная для анонимного
  • содержание следующих свойств:
    java.naming.security.principal
    java.naming.security.credentials
    
ОБЗОР-MD5
  • вся информация, перечисленная для простого
  • содержание следующих свойств:
    java.naming.security.sasl.authorizationId
    java.naming.security.sasl.realm
    javax.security.sasl.qop
    javax.security.sasl.strength
    javax.security.sasl.server.authentication
    javax.security.sasl.maxbuffer
    javax.security.sasl.policy.noplaintext
    javax.security.sasl.policy.noactive
    javax.security.sasl.policy.nodictionary
    javax.security.sasl.policy.noanonymous
    javax.security.sasl.policy.forward
    javax.security.sasl.policy.credentials
    

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

Объединение в пул соединений от пользовательской фабрики сокета позволяется, когда java.naming.ldap.factory.socket свойство среды устанавливается. Для пользовательской фабрики сокета, которая будет объединена фабрика сокета в пул, class должен реализовать интерфейс Comparator. Поставщик услуг LDAP вызывает метод Comparator.compare() для сравнения равенства фабрик сокета, соединения которых проверяются на равенство механизмом объединения в пул. Сравнение фабрики сокета должно гарантировать, что параметры фабрики сокета, которые влияют на равенство соединения, сравниваются. Это сравнение делается в дополнение к сравнению идентификационных данных соединения, описанному в том, Как Соединения Объединяются в пул. У пользовательского class фабрики сокета должна быть следующая структура, если ее соединения должны были быть объединены в пул:
    public class CustomSocketFactory extends SocketFactory
                implements Comparator<SocketFactory> { 
       :
       :
       public int compare(SocketFactory sf1, SocketFactory sf2) {
           :
           :
           // do whatever comparison that's required
       }
    }

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

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

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

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

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

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

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

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

Когда приложение заканчивается с объединенным в пул соединением (вызывая Context.close() на все контексты, которые совместно используют соединение), базовое объединенное в пул соединение отмечается как неактивное, ожидая, чтобы быть снова использованным. По умолчанию неактивные соединения остаются в пуле неопределенно, пока они не собираются "мусор". Если свойство "com.sun.jndi.ldap.connect.pool.timeout" System было установлено, провайдер LDAP автоматически закроет и удалит объединенные в пул соединения, которые были неактивны для больше чем установленный период.

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

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

Чтобы использовать объединение в пул, установите свойство com.sun.jndi.ldap.connect.pool в "true" в свойствах среды, которые передают начальному конструктору контекста. Провайдер применит критерии объединения в пул к предоставленным свойствам среды и решит, использовать ли объединение в пул для того контекста. Если провайдер решает, что соединение не может быть объединено в пул, это создает и использует необъединенное в пул соединение для контекста.

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

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

Свойство среды com.sun.jndi.ldap.connect.timeout используется, чтобы определить период тайм-аута для установления соединения LDAP. Это свойство влияет на тайм-аут TCP, открывая соединение с сервером LDAP. Когда объединение в пул соединения требовали, это свойство также определяет максимальное время ожидания для соединения, когда все соединения в пуле используются, и максимальный размер пула был достигнут.

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

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


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

Когда менеджер безопасности был установлен, следует предоставить приложению, используя JNDI и поставщика услуг LDAP следующие полномочия:
permission java.net.SocketPermission "host[:port]", "connect";

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

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

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

Если Вы используете аутентификацию SASL и будете устанавливать клиентскую фабрику SASL программно, удовлетворите свое ходатайство следующее разрешение.
permission java.lang.RuntimePermission "setFactory"
Если Вы используете "GSSAPI" SASL механизм, Вы нуждаетесь в следующих дополнительных полномочиях.
permission javax.security.auth.AuthPermission "createLoginContext.appClassName";
permission javax.security.auth.AuthPermission "doAsPrivileged";

Для приложения class это собирается войти в систему и вызвать метод 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.


Oracle и/или его филиалы Авторское право © 1993, 2012, Oracle и/или его филиалы. Все права защищены.
Свяжитесь с Нами