Этот документ определяет направляющие линии, за которыми должны следовать разработчики, создающие поставщиков услуг LDAP и поставщиков услуг, которые поддерживают функции подобные LDAP. Следующим эти направляющие линии разработчики могут произвести реализации, которые пользователи API JNDI могут сконфигурировать и использовать с минимальными различиями.
Не все функции, описанные в этом документе, должны поддерживаться поставщиком услуг LDAP. Однако, если функция поддерживается, она должна поддерживаться в пути, описанном этим документом.
2. Соответствие
Поставщик услуг LDAP, который поддерживает версию 3 (LDAPv3) LDAP, соответствует:
Свойства среды являются средствами, которыми пользователи приложения JNDI конфигурируют и влияют на поведение поставщиков услуг JNDI. Следовательно, поставщики услуг должны интерпретировать и обработать свойства среды таким же образом.
Есть четыре типа свойств среды, которые влияют на поставщиков услуг LDAP:
Создавая начальный контекст, свойства среды можно передать как параметр конструктору или могут быть инициализированы как определено в документации JNDI.
В частности если какое-либо из следующих свойств не предоставляется в свойствах среды тогда, это разыскивается от системных свойств, параметров апплета, и и провайдер и файлы ресурсов приложения (в том порядке):
В случае управления, объекта и свойств фабрики состояния, если больше чем одно возникновение свойства располагается, то его значения связываются в единственный список. В случае свойства url и всех других свойств, только используется первое возникновение.
Свойства среды контекста могут быть исследованы, используя метод Context.getEnvironment.
За исключением свойств java.naming.provider.url И java.naming.factory.initial, изменяя свойство, используя методы Context.addToEnvironment ИЛИ Context.removeFromEnvironment влияет на экземпляр контекста, на который вызывается метод. Например, если Вы определяете новые учетные данные для контекста, чтобы использовать, последующие методы, вызванные на тот контекст, которые требуют, чтобы передача с сервером использовала те новые учетные данные (возможно, внутренне первым созданием нового соединения с сервером). Эти обновленные свойства среды наследованы экземплярами контекста, которые впоследствии получаются из экземпляра контекста, на который влияют, но иначе не влияют на другие экземпляры контекста, которые были существующими до обновления.
3.1.4 Своевременность
Когда изменение производится в свойствах среды, нет никакого требования, чтобы изменение быть проверенным и действоваться в это время метод Context.addToEnvironment ИЛИ Context.removeFromEnvironment было вызвано. Единственное требование - то, что изменение (или изменения) быть эффективными в следующий раз работа, которая использует то свойство, вызываются.
3.1.5 Значения по умолчанию
Эта спецификация определяет значения по умолчанию для свойств среды. В нескольких случаях значение по умолчанию определяется поставщиком услуг. Если у контекста нет определенного свойства среды, он ведет себя, как будто у него есть то свойство среды с его значением по умолчанию.
Когда свойство удаляется из свойств среды контекста, контекст принимает поведение значения по умолчанию, определенное для того свойства. Это не обязательно означает, что значение по умолчанию должно быть записано как значение свойства. Удаление может также быть обозначено отсутствием свойства от свойств среды контекста.
3.1.6 Приемлемые Значения
Эта спецификация определяет приемлемые значения для свойств среды. У некоторых свойств среды есть фиксированный набор приемлемых значений, в то время как у других есть значения, которые должны следовать за определенным синтаксисом. Если недопустимое значение будет представлено, то специфичное для свойства исключение будет выдано (например, ConfigurationException, IllegalArgumentException, или AuthenticationNotSupportedException). В некоторых случаях могло бы быть разумно для поставщика услуг принять дополнительные значения чем определенные, когда, те значения должны быть задокументированы.
3.2 Свойства JNDI
Поставщики услуг LDAP должны обработать свойства среды JNDI согласно следующим спецификациям. В данных примерах env является экземпляром Hashtable, который содержит свойства среды, используемые, чтобы создать начальный контекст.
java.naming.batchsize
Значение этого свойства является строкой десятичных цифр, которая определяет пакетный размер результатов поиска, возвращенных сервером.
Это свойство влияет на поведение блокирования Context.list, Context.listBindings, и методы DirContext.search и NamingEnumeration возражают, что возвращаются. Это не влияет, сколько элементов возвращается в перечислении; это только влияет, как элементы обрабатываются в пакетном режиме или читаются на уровне протокола LDAP.
Установка нулевых средств, которые должен блокировать провайдер, пока все результаты не были получены. Установка целого числа n больше чем нулевые средства, что провайдер должен блокировать до n результаты, была получена от сервера или пока перечисление завершается, какой бы ни производит меньше числа результатов. После того, как приложение считало результаты n (использующий NamingEnumeration.next или NamingEnumeration.nextElement), провайдер должен считать n больше следствий сервера или пока перечисление завершается, какой бы ни производит меньше числа результатов.
Если это свойство не устанавливается тогда, его значение по умолчанию специфично для реализации.
Например, следующий код определяет, что провайдер должен блокировать, пока 24 записи не были считаны из сервера или пока перечисление завершается, какой бы ни производит меньше числа результатов:
Значение этого свойства является разделенным от двоеточия списком полностью определенных имен class классов фабрики управления.
Фабрики ответственны за сужение class средств управления ответом. Они создают определенные средства управления ответом из универсальных средств управления ответом, сгенерированных провайдером.
Никакое значение по умолчанию не определяется для этого свойства.
Например, следующие кодовые наборы ResponseControlFactory class как фабрика управления, чтобы попробовать:
Значение этого свойства является полностью определенным именем class фабрики class, который создает начальный контекст для поставщика услуг LDAP.
Это используется, чтобы выбрать определенного поставщика услуг LDAP; это фактически не используется провайдером непосредственно. Это свойство не должно быть установлено, когда параметром имени начальным методам контекста является URL.
Никакое значение по умолчанию не определяется для этого свойства.
Например, следующий код выбирает провайдера Sun LDAP:
Значение этого свойства является разделенным от двоеточия списком полностью определенных имен class объектных классов фабрики.
Фабрики ответственны за создание конкретных целей из записей LDAP, возвращенных провайдером. Например, фабрика объекта Человека могла бы генерировать объект Person от записи LDAP объектного человека class. Объектные фабрики ведут себя противоположным способом утвердить фабрики, на которых они генерируют объекты от атрибутов LDAP.
Никакое значение по умолчанию не определяется для этого свойства.
устанавливает PersonFromLDAP class как объектная фабрика, чтобы попробовать.
java.naming.factory.state
Значение этого свойства является разделенным от двоеточия списком полностью определенных имен class классов фабрики состояния.
Фабрики ответственны за создание состояния объекта (для того, чтобы сохранить) от объекта непосредственно. Например, фабрика состояния Человека могла бы генерировать запись LDAP объектного человека class от объекта Person. Государственные фабрики ведут себя противоположным способом возразить фабрикам в этом, они генерируют атрибуты LDAP от объектов.
Никакое значение по умолчанию не определяется для этого свойства.
устанавливает PersonToLDAP class как фабрика состояния, чтобы попробовать.
java.naming.language
Значение этого свойства является строковым тегом языка согласно RFC 1766.
Это свойство указывает на предпочтение определенному естественному языку. Провайдер может скорректировать свои запросы LDAP и ответы согласно значению этого свойства. Влияние этого свойства специфично для реализации. Никакое значение по умолчанию не определяется. Например:
Значение этого свойства является списком разделенного пробелом LDAP или строк URL LDAPS, каждая из которых определяет имя узла и номер порта сервера LDAP, и корневое отличительное имя контекста именования, чтобы использовать. URL LDAP определяет использование плоскости (то есть, незащищенный) соединение; URL LDAPS определяет использование соединения SSL. Если список содержит больше чем один URL, провайдер должен попытаться использовать каждый URL поочередно, пока это не в состоянии создать успешное соединение, и после создания, установить свойство в успешный URL.
Именем узла значения по умолчанию является localhost; портом значения по умолчанию является 389 для простых соединений и 636 для соединений SSL. Корневое отличительное имя значения по умолчанию является пустой строкой. Если это свойство не устанавливается, или если или имя узла или номер порта опускаются, то значения по умолчанию используются вместо недостающей информации. Если и имя узла и порт отсутствуют, но непустое отличительное имя присутствует в URL, то провайдер должен использовать отличительное имя, чтобы определить имя узла и порт сервера (ов) LDAP как описано в разделе URL и когда соединение было установлено успешно, установил свойство java.naming.provider.url в URL, созданный, используя успешное имя узла, порт и отличительное имя. См. также раздел URL для информации о том, как провайдер должен обработать другую информацию, найденную в URL.
Значение этого свойства является строкой, которая определяет, как отсылки должны быть обработаны провайдером. Следующие значения определяются для этого свойства:
проигнорируйте отсылки, если они появляются в результатах. PartialResultException бросается, чтобы указать на неполный результат. Кроме того, для серверов LDAPv3, провайдер должен запросить, чтобы отсылки были обработаны как обычные атрибуты, когда они появляются в записях. Это достигается, отправляя некритическому ManageDsaIT (RFC 3296) управление LDAP с каждым запросом LDAP. Серверы LDAP, которые не поддерживают это управление LDAP, просто проигнорируют его и обработают запрос как нормальный.
См. раздел URL для информации о том, как обработать многократные URL, найденные в единственной записи отсылки.
Если это свойство не устанавливается тогда, его значением по умолчанию является ignore.
определяет, что отсылки, с которыми встречаются во время работы LDAP, должны бросить ReferralException в приложение.
java.naming.security.authentication
Значение этого свойства является строкой, которая определяет механизм (ы) аутентификации для провайдера, чтобы использовать. Следующие значения определяются для этого свойства:
none
не используйте аутентификацию (анонимный, связывают).
simple
используйте простую аутентификацию (пароль в виде открытого текста).
Разделенный пробелом список одного или более имен механизма SASL:
используйте первый доступный механизм SASL в списке, который соответствует указанным требованиям политики
См. раздел SASL для информации о том, как это свойство используется для аутентификации SASL. См. RFC 2829 для информации о механизмах аутентификации LDAP.
Если это свойство не устанавливается тогда, его значением по умолчанию является none, если java.naming.security.credentials свойство не устанавливается, когда значением по умолчанию является simple. Если это свойство устанавливается в значение, которое провайдер не распознает или поддерживает, это должно бросить AuthenticationNotSupportedException.
определяет, что аутентификация ОБЗОРА-MD5 используется и, если это механизм SASL недоступно, та аутентификация CRAM-MD5 использоваться. Если ни один не доступен, тогда бросают AuthenticationNotSupportedException.
java.naming.security.credentials
Значение этого свойства является объектом, который определяет учетные данные принципала, который будет аутентифицироваться. Его формат и обработка зависят от значения java.naming.security.authentication свойства. Поскольку анонимный связывает, это свойство игнорируется - пустая строка всегда используется для учетных данных. Для простой аутентификации и аутентификации SASL, которая требует пароля, значение этого свойства может быть предоставлено как java.lang.String, char[] или byte[]. Если это - String или char[] тогда, это кодируется в байтовый массив, используя UTF-8 в случае LDAPv3 и закодировало использование ISO-Latin-1 в случае LDAPv2. Если это - byte[] тогда, это используется как есть. См. раздел SASL для информации о том, как это свойство используется для аутентификации SASL. Никакое значение по умолчанию не определяется для этого свойства. Например:
устанавливает учетные данные, чтобы быть строкой "секрет".
java.naming.security.principal
Значение этого свойства является строкой, которая определяет идентификационные данные принципала, который будет аутентифицироваться. Его формат зависит от типа аутентификации; см. RFC 2829 для получения дополнительной информации. Значение используется в качестве компонента name в LDAP ASN.1 BindRequest для non-SASL аутентификации. Для аутентификации SASL значение этого свойства используется в качестве ID аутентификации для механизмов SASL, которые нуждаются в ID аутентификации.
Провайдер не обязан проверять законность основного имени. Это может, например, только передать строку, которая будет проверена сервером. Если идентифицированный принципал не будет допустимым принципалом тогда, то провайдер должен бросить AuthenticationException.
Никакое значение по умолчанию не определяется для этого свойства.
определяет основное имя, чтобы быть отличительным именем "cn=admin, o=sun, c=us".
java.naming.security.protocol
Значение этого свойства является строкой, которая определяет протокол системы защиты для провайдера, чтобы использовать. Следующее значение определяется для этого свойства:
ssl
используйте версию 3.0 Уровня защищенных сокетов.
Если это свойство устанавливается в ssl, провайдер должен использовать сокеты SSL, или бросить ConfigurationException, если это неспособно сделать так. В дополнение к упомянутому выше значению провайдер может поддерживать другие протоколы системы защиты. Однако, такие специфичные для провайдера протоколы не могли бы поддерживаться всеми провайдерами. Если это свойство устанавливается в протокол системы защиты, который провайдер не распознает или поддерживает, это должно бросить ConfigurationException.
Если java.naming.ldap.factory.socket свойство устанавливается, то фабрика сокета, идентифицированная тем свойством, должна создать сокеты, которые являются подходящими для этой установки протокола. Например, если протокол системы защиты устанавливается в ssl, то фабрика сокета должна создать совместимые SSL сокеты.
Если это свойство не устанавливается тогда, значение по умолчанию не должно использовать протокол системы защиты.
Как разработчик провайдера LDAP, следует знать, что использование SSL, чтобы соединиться с сервером на порту, который не прислушивается к соединениям SSL, заставляет сокет зависать. Точно так же использование простого сокета, чтобы соединиться с сервером, который прислушивается к соединениям SSL также, приводит к зависанию. Это - характеристика протокола, который некоторые реализации могут хотеть исправлять, но иначе не обязаны делать так. Документация провайдера, однако, должна описать это поведение своим пользователям. См. SSL для информации о том, как использовать SSL.
определяет, что совместимые SSL сокеты используются, чтобы связаться с сервером.
3.3 LDAP-специфичные Свойства
Свойства LDAP-specific являются свойствами среды, которые применяются к поставщикам услуг LDAP вообще. У имен этих свойств есть префиксный "java.naming.ldap.". Следующая таблица приводит свойства LDAP-specific, которые до сих пор определялись.
java.naming.ldap.attributes.binary
Значение этого свойства является строкой разделенных пробелом названий атрибута. Это определяет атрибуты, у которых есть нестроковый синтаксис. Это расширяет встроенный список провайдера нестроковых атрибутов (ниже). Значение атрибута, у которого есть нестроковый синтаксис, возвращается как байтовый массив (byte[]) вместо String. Никакое значение по умолчанию не определяется. Если это свойство не устанавливается тогда, только у следующих атрибутов, как полагают, есть нестроковый синтаксис:
сообщает провайдеру возвращаемым значениям mpegVideo и атрибутов myspecialkey как byte[].
java.naming.ldap.control.connect
Значение этого свойства является объектом Control[]. Это устанавливает средства управления запросом соединения, которые являются активными на соединении. См. LdapContext. Никакое значение по умолчанию не определяется для этого свойства. Например:
env.put("java.naming.ldap.control.connect",
new Control[]{ new ManageReferralControl(true) });
устанавливает критический ManageDsaIT управление LDAP как управление запросом соединения.
java.naming.ldap.deleteRDN
Значение этого свойства является строкой, которая определяет, удаляется ли старый RDN методом Context.rename. Следующие значения определяются для этого свойства:
true
удалите старый RDN из записи во время переименовать работы.
false
сохраните старый RDN как значение атрибута записи.
Если это свойство не устанавливается тогда, его значением по умолчанию является true.
Например:
env.put("java.naming.ldap.deleteRDN", "false");
заставляет старый RDN быть сохраненным как атрибут переименованной записи.
java.naming.ldap.derefAliases
Значение этого свойства является строкой, которая определяет, как псевдонимы разыменовываются во время операций поиска. Следующие значения определяются для этого свойства:
always
всегда разыменовывайте псевдонимы.
never
никогда не разыменовывайте псевдонимы.
finding
разыменуйте псевдонимы только во время разрешения имени (то есть, определяя местоположение целевой записи).
searching
разыменуйте псевдонимы, как только разрешение имени завершилось (то есть, после определения местоположения целевой записи).
Если это свойство не устанавливается тогда, его значением по умолчанию является always. Например:
заставляет провайдера разыменовывать псевдонимы только, как только целевая запись была расположена.
ОТМЕТЬТЕ: это свойство не связано с флагом разыменовывать-ссылок в объекте SearchControls.
java.naming.ldap.factory.socket
Значение этого свойства является строкой, идентифицирующей имя class фабрики сокета. Это свойство используется, чтобы переопределить фабрику сокета значения по умолчанию. class, определенный в этом свойстве, должен реализовать интерфейс javax.net.SocketFactory. См. Справочник JSSE для получения дополнительной информации. См. SSL для информации о том, как использовать SSL. Кроме того, если java.naming.security.protocol свойство устанавливается, то фабрика сокета, идентифицированная этим свойством, должна создать сокеты, которые являются подходящими для той установки протокола. Например, если протокол системы защиты устанавливается в ssl тогда, фабрика сокета должна создать совместимые SSL сокеты. Никакое значение по умолчанию не определяется для этого свойства. Например:
устанавливает фабрику сокета провайдера, чтобы быть javax.net.ssl.SSLSocketFactory.
java.naming.ldap.ref.separator
Значение этого свойства является строкой, содержащей символ, чтобы использовать, кодируя объект RefAddr в атрибуте javaReferenceAddress (см. Объекты Java). Это свойство используется, чтобы избежать конфликта в случае, где символ разделителя значения по умолчанию появляется в компонентах объекта RefAddr. Если это свойство не устанавливается тогда, его значением по умолчанию является '#' (символ хеша). Например:
env.put("java.naming.ldap.ref.separator", ":");
определяет что разделитель ':' (символ двоеточия) использоваться, храня экземпляры RefAddr.
java.naming.ldap.referral.limit
Значение этого свойства является строкой десятичных цифр, определяющих максимальное количество отсылок, чтобы следовать в цепочке отсылок. Установка нуля указывает, что нет никакого предела. Если это свойство не устанавливается тогда, значением по умолчанию является 10. Например:
env.put("java.naming.ldap.referral.limit", "5");
определяет, что предел отсылки 5.
java.naming.ldap.typesOnly
Значение этого свойства является строкой, которая определяет, приписывают ли только ID, возвращаются в результатах - значения атрибута опускаются. Влияет на методы SearchResult.getAttributes И DirContext.getAttributes. Следующие значения определяются для этого свойства:
true
возврат только приписывает ID.
false
возвратите и ID атрибута и значения атрибута.
Если это свойство не устанавливается тогда, его значением по умолчанию является false.
Например:
env.put("java.naming.ldap.typesOnly", "true");
заставляет сервер возвращать ID атрибута, но не значения атрибута.
java.naming.ldap.version
Значение этого свойства является строкой, которая определяет версию протокола для провайдера. Следующие значения определяются для этого свойства:
2
выбирает версию 2 (LDAPv2) LDAP.
3
выбирает версию 3 (LDAPv3) LDAP.
Если это свойство не устанавливается тогда, провайдер сначала пытается связать использование LDAP v3 и сбои к использованию LDAP v2, если ошибка протокола получается от сервера. Этот failover механизм только используется, когда свойство java.naming.security.authentication указывает анонимный, связывают или простая аутентификация.
Например:
env.put("java.naming.ldap.version", "2");
запрашивает провайдера LDAP связаться с сервером, используя LDAPv2.
3.4 Специфичные для функции Свойства
Специфичные для функции свойства являются свойствами среды, которые применяются к определенной функции, которая поддерживается провайдером.
Значение этого свойства является строкой, которая определяет ID авторизации для механизмов SASL.
Если это свойство не устанавливается, то ID авторизации, который передают к механизмам SASL, является пустой строкой. Согласно SASL (RFC 2222), используя ID авторизации пустой строки направляет сервер, чтобы получить ID авторизации из учетных данных аутентификации клиента.
определяет идентификационные данные, чтобы использовать для авторизации (управление доступом) после успешной аутентификации.
java.naming.security.sasl.realm
Значение этого свойства является строкой, которая определяет информацию области, запрошенную некоторыми механизмами SASL, такими как ОБЗОР-MD5.
Если это свойство не устанавливается, то специфичное для механизма значение по умолчанию, такое как согласованное между клиентом и сервером во время обмена аутентификации используется.
определяет, что клиент хочет использовать область "веб-пользователей" для аутентификации.
java.naming.security.sasl.callback
Значение этого свойства является экземпляром javax.security.auth.callback.CallbackHandler. Когда провайдер использует механизм SASL, который требует обратных вызовов, механизм SASL использует объект, предоставленный в свойстве. Обработчик обратного вызова должен удовлетворить NameCallback, предоставляя ID аутентификации.
env.put("java.naming.security.sasl.callback",
new MyCallbackHandler());
предоставляет экземпляр обработчика обратного вызова для механизмов SASL, чтобы использовать.
javax.security.sasl.qop
Значением этого свойства является ', '-separated список качества защиты (qop) значения, используемые, чтобы определить qop предпочтение клиента. Значение qop является одним из
"auth" - аутентификация только
"auth-int" - аутентификация плюс защита целостности
"auth-conf" - аутентификация плюс защита целостности и защита конфиденциальности
Порядок списка определяет привилегированный порядок. Если это свойство отсутствует, значением по умолчанию qop является "auth". javax.security.sasl.strength
Значением этого свойства является ', '-separated список значений силы шифра, используемых, чтобы определить предпочтение клиента. Значение силы является одним из
"low"
"medium"
"high"
Порядок списка определяет привилегированный порядок. Если это свойство отсутствует, силой значения по умолчанию является "high,medium,low".
Для конфиденциальности в ОБЗОРЕ-MD5 "high" отображается на "3des", "medium" к "rc4" или "des", и "low" к "rc4-56" или "rc4-40".
javax.security.sasl.maxbuffer
Значение этого свойства является строковым представлением целого числа, которое определяет максимальный размер получить буфера в байтах, которые клиент готов получить. Если это свойство отсутствует, размер значения по умолчанию определяется механизмом SASL.
javax.security.sasl.server.authentication
Значение этого свойства является или "истиной" или "ложью", определяя, должен ли сервер аутентифицировать клиенту или нет, соответственно. Если это свойство отсутствует, значение по умолчанию является "ложью".
javax.security.sasl.policy.forward
Значение этого свойства является или "истиной" или "ложью", определяя, должен ли выбранный механизм SASL поддерживать прямую тайну между сеансами или нет, соответственно. Если это свойство отсутствует, значение по умолчанию является "ложью".
javax.security.sasl.policy.credentials
Значение этого свойства является или "истиной" или "ложью", определяя, должен ли выбранный механизм SASL потребовать удостоверений клиента или нет, соответственно. Если это свойство отсутствует, значение по умолчанию является "ложью".
javax.security.sasl.policy.noplaintext
Значение этого свойства является или "истиной" или "ложью", определяя, не должен ли выбранный механизм SASL быть восприимчивым к простым простым пассивным атакам или нет, соответственно. Если это свойство отсутствует, значение по умолчанию является "ложью".
javax.security.sasl.policy.noactive
Значение этого свойства является или "истиной" или "ложью", определяя, не должен ли выбранный механизм SASL быть восприимчивым к активному (несловарь) атаки или нет, соответственно. Если это свойство отсутствует, значение по умолчанию является "ложью".
javax.security.sasl.policy.nodictionary
Значение этого свойства является или "истиной" или "ложью", определяя, не должен ли выбранный механизм SASL быть восприимчивым к атакам с подбором по словарю или нет, соответственно. Если это свойство отсутствует, значение по умолчанию является "ложью".
javax.security.sasl.policy.noanonymous
Значение этого свойства является или "истиной" или "ложью", определяя, не должен ли выбранный механизм SASL принять анонимные входы в систему или нет, соответственно. Если это свойство отсутствует, значение по умолчанию является "ложью".
3.5 Специфичные для провайдера Свойства
Специфичные для провайдера свойства являются свойствами среды, которые применяются только к определенным реализациям провайдера. Имена этих свойств выбираются конструктором провайдера. Рекомендуемая политика для того, чтобы назвать эти свойства состоит в том, чтобы использовать инвертированное доменное имя DNS конструктора, чтобы снабдить префиксом имя пакета провайдера и использовать то имя пакета, чтобы снабдить префиксом имя свойства. Например, префиксы Sun его специфичные для провайдера свойства LDAP с "com.sun.jndi.ldap".
4. Имена
Имена обрабатываются методами контекста провайдера согласно следующим правилам:
Имена String, предоставленные как параметры методам контекста, находятся в составном синтаксисе имени. Первый компонент составного имени является отличительным именем LDAP, в то время как остальная часть компонентов используется для федерации.
Если параметром Name является объект CompositeName тогда, его первый компонент, как предполагается, является отличительным именем LDAP, и остающиеся компоненты (если кто-либо) используются для федерации.
Если параметром Nameне является объект CompositeName тогда, все его компоненты, как предполагается, являются проанализированной формой отличительного имени LDAP. Таким образом, каждый компонент Name является относительным отличительным именем LDAP (RDN).
Имена анализируются, используя синтаксический анализатор имени, возвращенный методом Context.getNameParser. Синтаксический анализатор принимает отличительные имена LDAP, поскольку String возражает и производит отличительные имена LDAP, как Name возражает.
Имена, возвращенные операциями контекста, являются строковыми именами составного объекта или представляют URL в виде строки.
Синтаксис строки отличительные имена LDAP следует за RFC 2253. Например:
CN=Steve Kille, O=Isode Limited, C=GB
OU=Sales+CN=J. Smith, O=Widget Inc., C=US
CN=L. Eagle, O=Sue\, Grabbit and Runn, C=GB
Имя, предоставленное контексту LDAP, всегда относительно того контекста. Например, учитывая контекст LDAP (lctx) для "dc=widget,dc=com", чтобы назвать записи LDAP в том поддереве, имя относительно "dc=widget,dc=com" должно быть предоставлено. Например, следующий вызов получает атрибуты для записи "cn=John Smith,dc=widget,dc=com".
Точно так же, когда контекст перечисляется, используя любой из методов перечисления (Context.list, Context.listBindings, DirContext.search), возвращенные имена относительно целевого контекста - перечисляемый контекст. Когда отсылки вызываются вместо относительного имени, LDAP или строка URL LDAPS, содержащая полностью определенное имя, возвращаются. (Если перечисление выполнялось, используя простое соединение, строка URL LDAP возвращается; если это было сделано, используя соединение SSL, строка URL LDAPS возвращается.) Формат URL LDAP определяется в RFC 2255.
LDAP URL, которые следуют за RFC 2255 и URL LDAPS, может быть предоставлен любому из методов контекста. Имя узла и номер порта извлекаются из URL и используются, чтобы связаться с сервером LDAP; схема URL ("ldap" или "ldaps") используется, чтобы определить, используется ли соединение плоскости или SSL. Свойства java.naming.factory.initial И java.naming.provider.url игнорируются. Например,
Этот фрагмент кода связывается с сервером LDAP в машине wserver в порту 389, используя простое соединение.
5. Атрибуты
Провайдер LDAP ожидает так ввод и возвращает как выходной все значения атрибута или как String или как объекты byte[]. См. свойство среды java.naming.ldap.attributes.binary для того, которые обрабатываются как byte[] и как расширить список.
6. URL
RFC 2255 описывает синтаксический формат URL LDAP. Формат содержит все элементы, необходимые, чтобы определить работу поиска LDAP с условиями для того, чтобы поддерживать расширения:
Информация об аутентификации может быть определена в части extensions URL. См. RFC для полного описания формата.
В дополнение к URL LDAP провайдер может также поддерживать нестандартные, но широко используемые URL LDAPS. LDAPS URL используют соединения SSL вместо плоскости (то есть, незащищенные) соединения. У них есть синтаксис, подобный URL LDAP кроме схем, отличаются, и порт значения по умолчанию для URL LDAPS 636 вместо 389.
Конфигурация поставщиков услуг. Чтобы сконфигурировать поставщика услуг LDAP, Вы обычно предоставляете один или более разделенных пробелом LDAP или URL LDAPS в свойстве java.naming.provider.url. Это используется поставщиком услуг LDAP, чтобы сконфигурировать его соединение с сервером каталогов. Только host, port, и части dn URL релевантны в этой установке. Предоставление других частей URL приводит к ConfigurationException.
Параметр начальным методам контекста. Если строку URL (с синтаксисом scheme_id:rest_of_name) передают к методам в InitialContext, или как параметр String или как первый компонент Name, идентификатор схемы URL используется, чтобы определить местоположение фабрики контекста для того, чтобы обработать ту схему. Если ни один не находится, строка URL обрабатывается как обычное имя и передается к начальному контексту, определенному свойством java.naming.factory.initial, используется. См. метод java.naming.spi.NamingManager.getURLContext для деталей о том, как располагаются фабрики контекста URL. Отметьте, что эта поддержка URL как имена только доступна в начальном контексте.
За исключением методов поиска, когда LDAP или URL LDAPS передают как имя к начальному контексту, URL не должен содержать запрос ('?') компоненты. Иначе, InvalidNameException бросается поставщиком услуг. Для методов поиска компоненты запроса URL переопределяют любые соответствующие компоненты, предоставленные как параметры. Например, если URL LDAP, содержащий компонент контекста, предоставляется, то тот контекст переопределяет любой контекст, устанавливающий, который можно передать в параметре SearchControls.
Отсылки. Отсылка LDAP содержит список одного или более URL. Чтобы обработать отсылку LDAP (или явно или неявно устанавливая свойство java.naming.referral), поставщик услуг должен использовать информацию в этих URL, чтобы создать соединения с серверами LDAP, к которым они обращаются. Когда многократные URL присутствуют в единственной отсылке, они обрабатываются как альтернативы, и каждый сопровождается, пока каждый не успешно выполняется. Полный URL (то есть, включая любые компоненты запроса) используется.
Возвращенный как имя в списке и перечислениях поиска. Когда у имени возвращаемой записи есть имя, которое не является относительно целевого контекста (то есть, запускающийся контекст для списка или поиска), имя возвращается как URL. См. метод NameClassPair.isRelative для деталей.
Параметр методу getObjectInstanceNamingManager или DirectoryManager. Когда пространство имен LDAP объединяется в федерацию под другим пространством имен (например, таким как DNS), информацией, которая хранится в превосходящем пространстве имен, мог бы быть LDAP или URL LDAPS. В таком сценарии работа поиска/списка/поиска в превосходящем пространстве имен возвратила бы Reference, содержащий LDAP или URL LDAPS для пространства имен LDAP. Поставщик услуг для превосходящего пространства имен передал бы Reference к методу getObjectInstance, чтобы создать экземпляр контекста LDAP.
Для элементов (1), (2), (3), и (5), если URL пропускает имя узла и порт, но имеет непустое отличительное имя, провайдер должен использовать алгоритм для того, чтобы обнаружить службы LDAP с DNS как описано в интернет-проекте draft-ietf-ldapext-locate-08.txt. Если провайдер не использует этот алгоритм, или если конфигурация DNS не доступна, то провайдер должен использовать localhost в качестве имени узла, и 389 как порт для простых соединений, 636 как порт для соединений SSL.
7. Объекты Java
7.1 Хранение
Провайдер LDAP должен поддерживать хранение объектов Java в каталог. Это реализуется в следующих методах:
Context.bind()
Context.rebind()
DirContext.bind()
DirContext.rebind()
Провайдер должен поддерживать как минимум хранение следующих типов объектов Java:
Экземпляры Reference
Объекты, которые реализуют интерфейс Referenceable
Объекты, которые реализуют интерфейс Serializable
Объекты, которые реализуют интерфейс DirContext
Это должно проверить, является ли объект в этих четырех категориях в порядке, перечисленном, потому что это, наиболее вероятно, получит намерение клиента. Например, Reference является Serializable, так, если бы Вы выполняли проверку Serializable сначала, то никакой Reference s никогда не был бы сохранен в ссылочном формате (то есть, они будут все сериализированы).
Ссылки, referenceable и сериализуемые объекты должны быть сохранены согласно RFC 2713. объекты DirContext должны храниться, храня их атрибуты.
Храня список ссылки RefAddr в атрибут javaReferenceAddress, разделителем, чтобы использовать для того, чтобы разграничить позицию адреса, тип и контент управляют, используя свойство среды java.naming.ldap.ref.separator. Если это свойство среды не определяется, символ хеша '#' должен использоваться в качестве разделителя.
Провайдер использует метод DirectoryManager.getStateToBind, храня объекты в каталоге. Это позволяет объектам любого типа быть преобразованными в одну из этих четырех категорий, упомянутых выше так, чтобы они могли быть сохранены в каталог.
7.2 Чтение
Объекты читаются из каталога, используя следующие операции:
Context.lookup()
Context.lookupLink()
Binding.getObject()
Когда провайдер считает запись из каталога, это получит атрибуты LDAP, и атрибуты, определенные в RFC 2713, если у записи будет связанный объект Java. Если запись содержит Java связанные с объектом атрибуты, провайдер должен воссоздать объект, используя те атрибуты. Иначе, провайдер должен возвратить экземпляр DirContext, содержащего атрибуты записи. И для DirContext и для объектов Java, провайдер должен тогда вызвать DirectoryManager.getObjectInstance() на это и возвратить результат вызывающей стороне.
8.0 Схема
JNDI не определяет связанные со схемой детали, такие как структура и содержание дерева схемы, разрешение, чтобы изменить к содержанию дерева схемы, и эффект таких модификаций на каталоге зависит от базового каталога. JNDI определяет только, что корневой контекст схемы - возвращенное DirContext.getSchema() - содержит следующую привязку:
AttributeDefinition
ClassDefinition
SyntaxDefinition
Этот документ определяет структуру и контент деревьев схемы, которые получаются из LDAP-на-основе схем. Это описывает, как дерево схемы размечается, и обязательные и дополнительные атрибуты, которые можно ожидать считать связанным с записями в различных частях этого дерева схемы.
Разрешение, чтобы изменить содержание дерева схемы определяется администратором каталога. Когда дерево схемы изменяется, изменения производятся в схеме, сохраненной на сервере каталогов.
8.1 Древовидная структура схемы
В дополнение к этим трем привязке в корневом контексте схемы, перечисленном ранее, корневой контекст схемы может также содержать следующие четыре привязки:
Корень дерева SASL: плоское пространство имен с механизмами аутентификации SASL, идентифицированными их именем строки.
Любая из этой привязки может отсутствовать, если базовый каталог не публикует такую информацию о схеме, или поставщик услуг не поддерживает получение их. Если эти имена присутствуют в корневом контексте схемы, однако, у них должна быть привязка, определенная в вышеупомянутой таблице.
Названия атрибута и значения атрибутов этих записей являются нечувствительными к регистру.
8.2 Определения атрибута
Имя "AttributeDefinition" связывается с контекстом, содержащим объекты DirContext, представляющие определения атрибута в схеме. Например, если бы каталог поддерживает атрибут "commonName", у контекста "AttributeDefinition" была бы привязка с именем "commonName", который связывается с объектом DirContext.
У каждого объекта в контексте "AttributeDefinition" есть следующие обязательные и дополнительные атрибуты:
Идентификатор атрибута
Описание Значения атрибута
(Обязательный) NUMERICOID
уникальный идентификатор (OID)
ИМЯ
имя атрибута
DESC
описание атрибута
УСТАРЕВШИЙ
"истина" если устаревший, "ложь" или отсутствующий иначе
ГЛОТОК
имя превосходящего атрибута вводит, из которого получается тип этого атрибута
РАВЕНСТВО
имя или OID соответствия правила, если равенство, соответствующее позволенный, отсутствующий иначе
УПОРЯДОЧИВАНИЕ
имя или OID соответствия правила, упорядочивая соответствие позволенного, отсутствующий иначе
ПОДСТРОКА
имя или OID соответствия правила, если подстрока, соответствующая позволенный, отсутствующий иначе
СИНТАКСИС
числовой OID синтаксиса значений этого типа
ЕДИНСТВЕННОЕ ЗНАЧЕНИЕ
"истина", если атрибут, не многозначный, "ложный" или отсутствующий иначе.
КОЛЛЕКТИВНЫЙ
"истина", если атрибут является коллективным, "ложным" или отсутствует иначе.
"НИКАКАЯ ПОЛЬЗОВАТЕЛЬСКАЯ МОДИФИКАЦИЯ"
"истина", если не поддающийся изменению пользователем, "ложный" или отсутствующий иначе.
ИСПОЛЬЗОВАНИЕ
описание использования атрибута
Эти атрибуты имеют 1 к 1 корреспонденция именам, определенным в RFC 2252 для "AttributeTypeDescription". Все значения атрибута представляются java.lang.String class.
Можно, например, получить объект, представляющий атрибут "cn", используя следующий код:
DirContext schema = ctx.getSchema(""); // get schema tree
DirContext cnSchema = schema.lookup("AttributeDefinition/cn");
Если бы Вы тогда получаете атрибуты "cnSchema" объекта DirContext, Вы видели бы:
NUMERICOID 2.5.4.3
NAME cn
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
DESC Standard Attribute, alias for commonName
Эквивалентный способ получить "cnSchema" состоит в том, если у Вас уже есть атрибут "cn". Следующий код иллюстрирует эту альтернативу:
Имя "ClassDefinition" связывается с контекстом, содержащим объекты DirContext, представляющие объектные определения class в схеме. Например, если бы каталог поддерживает объект "страны" class, у контекста "ClassDefinition" была бы привязка с именем "страной", которая связывается с объектом DirContext.
У каждого объекта в контексте "ClassDefinition" есть следующие обязательные и дополнительные атрибуты:
Идентификатор атрибута
Описание Значения атрибута
(Обязательный) NUMERICOID
уникальный идентификатор (OID)
ИМЯ
возразите имени class
DESC
возразите описанию class
УСТАРЕВШИЙ
"истина" если устаревший, "ложь" или отсутствующий иначе
ГЛОТОК
имя превосходящего объектного class, из которого получается этот объектный class
КРАТКИЙ ОБЗОР
"истина", если объектный class абстрактен, "ложен" или отсутствует иначе
СТРУКТУРНЫЙ
"истина", если объектный class структурен, "ложен" или отсутствует иначе
ВСПОМОГАТЕЛЬНЫЙ
"истина", если объектный class является вспомогательным, "ложным" или отсутствует иначе
ДОЛЖЕН
список имен типов атрибутов, которые должны присутствовать
МАЙ
список имен типов атрибутов, которые могут присутствовать
Эти атрибуты имеют 1 к 1 корреспонденция именам, определенным в RFC 2252 для "ObjectClassDescription". Все значения атрибута представляются java.lang.String class.
Можно, например, получить объект, представляющий объект "страны" class, используя следующий код:
DirContext schema = ctx.getSchema(""); // get schema tree
DirContext countrySchema = schema.lookup("ClassDefinition/country");
Если бы Вы тогда получаете атрибуты "countrySchema" объекта DirContext, Вы видели бы:
NUMERICOID 2.5.6.2
NAME country
MAY aci, searchguide, description
MUST objectclass, c
DESC Standard ObjectClass
SUP top
Эквивалентный способ получить "countrySchema" состоит в том, если у Вас уже есть объект "страны". Следующий код иллюстрирует эту альтернативу:
// Read object from directory
DirContext countryObj = (DirContext)ctx.lookup("c=us", new String[]{"country"});
// Get all of object's object class definitions
DirContext objClasses = countryAttr.getSchemaClassDefinition();
// Pick out "country" object class in particular
DirContext countryClass = (DirContext)objClasses.lookup("country");
ОТМЕТЬТЕ: JNDI 1.1's спецификация getSchemaClassDefinition() подразумевает, что поставщик услуг должен возвратить любое из объектных определений class объекта. Эта спецификация является несоответствующей, потому что у объекта обычно есть многократные классы объектов, и приложение могло бы потребовать знания о любых из тех классов объектов в зависимости от того, что это делает. Предложение как иллюстрировано примером выше состоит в том, чтобы возвратить контекст, содержащий все объектные определения class.
8.4 Определения синтаксиса
Имя "SyntaxDefinition" связывается с контекстом, содержащим объекты DirContext, представляющие определения синтаксиса в схеме. Например, если бы каталог поддерживает "1.3.6.1.4.1.1466.115.121.1.15" синтаксиса (Строка Каталога) синтаксис, у контекста "SyntaxDefinition" была бы привязка с именем "1.3.6.1.4.1.1466.115.121.1.15", который связывается с объектом DirContext.
У каждого объекта в контексте "SyntaxDefinition" есть следующие обязательные и дополнительные атрибуты:
Идентификатор атрибута
Описание Значения атрибута
(Обязательный) NUMERICOID
уникальный идентификатор (OID)
DESC
описание синтаксиса
Эти атрибуты имеют 1 к 1 корреспонденция именам, определенным в RFC 2252 для "SyntaxDescription". Все значения атрибута представляются java.lang.String class.
Можно, например, получить объект, представляющий "1.3.6.1.4.1.1466.115.121.1.15" синтаксиса, используя следующий код:
DirContext schema = ctx.getSchema(""); // get schema tree
DirContext dirStringSchema =
schema.lookup("SyntaxDefinition/1.3.6.1.4.1.1466.115.121.1.15");
Если бы Вы тогда получаете атрибуты "dirStringSchema" объекта DirContext, Вы видели бы:
Эквивалентный способ получить "dirStringSchema" состоит в том, если у Вас уже есть атрибут, у которого есть тот синтаксис (такой как, атрибут "страны"). Следующий код иллюстрирует эту альтернативу:
Имя "MatchingRule" связывается с контекстом, содержащим правила соответствия представления объектов DirContext в схеме. "Соответствующее правило" однозначно определяет алгоритм, чтобы использовать, сравнивая значения атрибута. Например, каталог мог бы поддерживать соответствующее правило, которое основано на том, как строка звучит, и определите это как "soundAlikeMatch" соответствие правила. Затем, у контекста "MatchingRule" была бы привязка с именем "soundAlikeMatch", который связывается с объектом DirContext.
То, когда соответствующее правило является расширяемым правилом соответствия, оно должно также содержать, "ПРИМЕНЯЕТ" атрибут, перечисляющий атрибуты, к которым может быть применено это расширяемое правило соответствия.
У каждого объекта в контексте "MatchingRule" есть следующие обязательные и дополнительные атрибуты:
Идентификатор атрибута
Описание Значения атрибута
(Обязательный) NUMERICOID
уникальный идентификатор (OID)
ИМЯ
имя соответствия правила
DESC
соответствие описания правила
УСТАРЕВШИЙ
"истина" если устаревший, "ложь" или отсутствующий иначе
СИНТАКСИС
числовой oid синтаксиса, к которому применяется это правило
ПРИМЕНЯЕТСЯ
имена типов списка атрибутов, к которым применяется это расширяемое правило соответствия
Эти атрибуты имеют 1 к 1 корреспонденция именам, определенным в RFC 2252 для "MatchingRuleDescription" и "MatchingRuleUseDescription". Все значения атрибута представляются java.lang.String class.
Можно, например, получить объект, представляющий "soundAlikeMatch" синтаксис, используя следующий код:
DirContext schema = ctx.getSchema(""); // get schema tree
DirContext soundMatchSchema =
schema.lookup("MatchingRule/soundAlikeMatch");
Если бы Вы тогда получаете атрибуты "soundMatchSchema" объекта DirContext, Вы видели бы:
NUMERICOID 1.2.3.4.5
NAME soundAlikeMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 (for directory string)
APPLIES 2.5.4.41, 2.5.4.15
DESC Home-grown Phonetic match
8.6 Определения расширения
Имя "ExtensionDefinition" связывается с контекстом, содержащим объекты DirContext, представляющие расширения, поддерживаемые сервером. Например, каталог мог бы поддерживать, "Запускают TLS" расширение ("1.3.6.1.4.1.1466.20037"). Затем, у контекста "ExtensionDefinition" была бы привязка с именем "1.3.6.1.4.1.1466.20037", который связывается с объектом DirContext.
У каждого объекта в контексте "ExtensionDefinition" есть следующие обязательные и дополнительные атрибуты:
Идентификатор атрибута
Описание Значения атрибута
(Обязательный) NUMERICOID
уникальный идентификатор (OID)
DESC
описание расширения
Все значения атрибута представляются java.lang.String class.
Можно, например, получить объект, представляющий расширение TLS Запуска ("1.3.6.1.4.1.1466.20037") использование следующего кода:
DirContext schema = ctx.getSchema(""); // get schema tree
DirContext startTLSSchema =
schema.lookup("ExtensionDefinition/1.3.6.1.4.1.1466.20037");
Если бы Вы тогда получаете атрибуты "startTLSSchema" объекта DirContext, Вы видели бы:
NUMERICOID 1.3.6.1.4.1.1466.20037
DESC Start TLS (see RFC 2830)
8.7 Определения управления
Имя "ControlDefinition" связывается с контекстом, содержащим объекты DirContext, представляющие средства управления, поддерживаемые сервером. Например, каталог мог бы поддерживать управление для того, чтобы попросить, чтобы сервер сортировал результаты поиска, которые это возвращает.
У каждого объекта в контексте "ControlDefinition" есть следующие обязательные и дополнительные атрибуты:
Идентификатор атрибута
Описание Значения атрибута
(Обязательный) NUMERICOID
уникальный идентификатор (строка)
DESC
описание управления
Все значения атрибута представляются java.lang.String class.
Можно, например, получить объект, представляющий серверное управление сортировкой ("1.2.840.113556.1.4.473") использование следующего кода:
DirContext schema = ctx.getSchema(""); // get schema tree
DirContext svrSortSchema =
schema.lookup("ControlDefinition/1.2.840.113556.1.4.473");
Если бы Вы тогда получаете атрибуты "svrSortSchema" объекта DirContext, Вы видели бы:
NUMERICOID 1.2.840.113556.1.4.473
DESC server-side sorting of search results
8.8 Механизмы SASL
Имя "SASLMechanism" связывается с контекстом, содержащим объекты DirContext, представляющие механизмы аутентификации SASL, поддерживаемые сервером. Например, каталог мог бы поддерживать ВНЕШНИЙ механизм SASL (RFC 2222), который запрашивает, чтобы сервер использовал учетные данные безопасности, которыми обменивается нижний уровень.
У каждого объекта в контексте "SASLMechanism" есть следующие обязательные и дополнительные атрибуты:
Идентификатор атрибута
Описание Значения атрибута
(Обязательное) ИМЯ
Имя механизма SASL
DESC
Описание механизма SASL
Все значения атрибута представляются java.lang.String class.
Можно, например, получить объект, представляющий ВНЕШНИЙ механизм SASL, используя следующий код:
DirContext schema = ctx.getSchema(""); // get schema tree
DirContext saslExternalSchema =
schema.lookup("SASLMechanism/EXTERNAL");
Если бы Вы тогда получаете атрибуты "saslExternalSchema" объекта DirContext, Вы видели бы:
NAME
EXTERNALDESC EXTERNAL SASL mechanism (RFC
2222)
9. Исключения
Создавая провайдера LDAP, Вы должны преобразовать коды ошибки LDAP (см. RFC 2251) в исключения JNDI. Следует использовать следующую таблицу, выполняя преобразование. Кроме того следует закодировать такую большую информацию насколько возможно об ошибке в подробное сообщение исключения, исключение "первопричины", разрешенные и остающиеся имена. Отметьте, что разрешенное имя и разрешенный объект должны соответствовать установке друг друга.
Код ошибки LDAP
Исключение или Действие
успех (0)
Сообщите об успехе.
operationsError (1)
NamingException
protocolError (2)
CommunicationException
timeLimitExceeded (3)
TimeLimitExceededException
sizeLimitExceeded (4)
SizeLimitExceededException
compareFalse (5)
Используемый DirContext.search() и не генерирует исключение.
compareTrue (6)
Используемый DirContext.search() и не генерирует исключение.
authMethodNotSupported (7)
AuthenticationNotSupportedException
strongAuthRequired (8)
AuthenticationNotSupportedException
partialResults (9)
Если java.naming.referral устанавливается в ignore, или содержание ошибки не содержит отсылку, бросает PartialResultException. Иначе, используйте содержание, чтобы создать отсылку.
отсылка (10)
Если java.naming.referral устанавливается в ignore, тогда бросают PartialResultException. Если это устанавливается в throw, тогда бросают ReferralException. Если это будет установлено в follow тогда, то провайдер должен следовать за отсылкой. Если значение для java.naming.ldap.referral.limit превышается, в то время как следование за отсылкой тогда бросает LimitExceededException.
adminLimitExceeded (11)
LimitExceededException
unavailableCriticalExtension (12)
OperationNotSupportedException
confidentialityRequired (13)
AuthenticationNotSupportedException
saslBindInProgress (14)
Используемый внутренне провайдером LDAP во время многоступенчатой аутентификации SASL.
noSuchAttribute (16)
NoSuchAttributeException
undefinedAttributeType (17)
InvalidAttributeIdentifierException
inappropriateMatching (18)
InvalidSearchFilterException
constraintViolation (19)
InvalidAttributeValueException
attributeOrValueExists (20)
AttributeInUseException
invalidAttributeSyntax (21)
InvalidAttributeValueException
noSuchObject (32)
NameNotFoundException
aliasProblem (33)
NamingException
invalidDNSyntax (34)
InvalidNameException
isLeaf (35)
Используемый провайдером; обычно не генерирует исключение.
aliasDereferencingProblem (36)
NamingException
inappropriateAuthentication (48)
AuthenticationNotSupportedException
invalidCredentials (49)
AuthenticationException
insufficientAccessRights (50)
NoPermissionException
занятый (51)
ServiceUnavailableException
недоступный (52)
ServiceUnavailableException
unwillingToPerform (53)
OperationNotSupportedException
loopDetect (54)
NamingException
namingViolation (64)
InvalidNameException
objectClassViolation (65)
SchemaViolationException
notAllowedOnNonLeaf (66)
ContextNotEmptyException
notAllowedOnRDN (67)
SchemaViolationException
entryAlreadyExists (68)
NameAlreadyBoundException
objectClassModsProhibited (69)
SchemaViolationException
affectsMultipleDSAs (71)
NamingException
другой (80)
NamingException
10. Отображение API
Методы интерфейсов контекста API JNDI отображаются на операции LDAP следующим образом.
EventContext.addNamingListener
EventDirContext.addNamingListener
Зарегистрируйте слушателя для того, чтобы получить события именования, которые имеют место в указанном поддереве записей LDAP. Серверы LDAP уведомляют клиенты событий посредством средств управления LDAP, присоединенных к ответам работы LDAP или посредством незапрашиваемые уведомления LDAP. Такие ответы тогда обрабатываются провайдером LDAP и обозначаются к приложению в форме NamingEvent или UnsolicitedNotificationEvent.
Context.addToEnvironment
Обновите свойства среды контекста. Если многократные контексты совместно используют тот же самый набор свойств среды, провайдер должен заботиться, чтобы только изменить среду намеченного контекста. Изменение свойства среды могло бы потребовать изменений к существующему соединению, которое использует контекст.
Предоставление нуля для значения свойства имеет тот же самый эффект как удаление свойства. Для всех свойств среды записывается новое свойство, даже если оно не влияет на контекст. См. раздел Свойств Среды.
Context.bind
DirContext.bind
Выполните LDAP, добавляет работа, чтобы создать новую запись в каталоге. Метод DirContext.bind может принять нуль как объект связать, если это также предоставляется непустое множество атрибутов. Иначе, если методу дают недостаточную информацию (то есть, никакой объект или атрибуты), никакая запись не может быть добавлена. Если объект обеспечивается в параметрах, то он преобразовывается в атрибуты и сохранен в записи наряду с любыми предоставленными атрибутами, как описано в разделе Объектов Java. Провайдер должен использовать метод DirectoryManager.getStateToBind, чтобы преобразовать входной объект в форму, которую это может сохранить. Если провайдер не поддерживает привязку каких-либо объектов в каталоге тогда, это должно бросить OperationNotSupportedException. Иначе, если это поддерживает обязательные объекты, но не поддерживает предоставленный объект тогда, это должно бросить IllegalArgumentException.
Context.close
Высвободите средства, связанные с контекстом. Например, если соединение, используемое этим контекстом, не совместно используется с другим контекстом, провайдер может отказаться от любых выдающихся запросов и закрыть сетевое соединение с сервером. Точно то, какие средства высвобождаются, является зависящим от реализации.
Context.composeName
Если родительский контекст от того же самого пространства имен LDAP, то свяжите имена согласно синтаксису имени LDAP, описанному в Context.getNameParser(). Иначе, свяжите имена как составные имена.
Context.createSubcontext
DirContext.createSubcontext
Выполните LDAP, добавляет работа, чтобы создать именованную запись и ее связанные атрибуты. Если никакие атрибуты не предоставляются тогда, атрибут objectClass сгенерирован со значениями top, и javaContainer (javaContainer является структурный class, который необходим, чтобы избежать ошибки нарушения схемы).
Context.destroySubcontext
Выполните LDAP, удаляют работу, чтобы удалить именованную запись и ее связанные атрибуты. Именованная запись должна быть листовой записью; поддеревья не удаляются. Если листовая запись не существует (но ее родитель существует), работа все еще успешно выполняется.
LdapContext.extendedOperation
Выполните LDAP расширенная работа.
DirContext.getAttributes
Выполните работу поиска базового объекта LDAP, чтобы получить атрибуты записи LDAP. Используйте" (objectclass = *)" как фильтр. Если список требуемых атрибутов является нулем или содержит специальный идентификатор атрибута '*' тогда, все пользовательские атрибуты при записи LDAP возвращаются. Если операционные атрибуты требуются тогда, те идентификаторы атрибута должны присутствовать в списке требуемых атрибутов.
LdapContext.getConnectControls
Получите средства управления запросом соединения в действительности для LDAP, связывают операции, вызванные на этот контекст.
Context.getEnvironment
Возвратите свойства среды, записанные в контексте.
Context.getNameInNamespace
Возвратите отличительное имя LDAP контекста.
Context.getNameParser
Возвратите синтаксический анализатор имени, который анализирует имена LDAP согласно RFC 2253.
LdapContext.getRequestControls
Получите средства управления запросом в действительности для операций LDAP, впоследствии вызванных на этот контекст.
LdapContext.getResponseControls
Получите средства управления ответом, возвращенные последней работой LDAP, вызванной на этот контекст.
Выполните одноуровневую работу поиска LDAP именованной записи, используя фильтр" (objectclass = *)", чтобы получить имена записей сразу ниже именованной записи. Попросите, как минимум, атрибуты javaClassName так, чтобы имя class каждой записи могло быть определено. Если имя class не может быть определено, возвратите javax.naming.directory.DirContext как имя class. Имена, которые возвращаются, или относительно именованного контекста, или они - LDAP или URL LDAPS.
Context.listBindings
Выполните одноуровневую работу поиска LDAP именованной записи, используя фильтр" (objectclass = *)", чтобы получить атрибуты, представляющие объекты (или ссылки на объект). Запросите атрибуты на то, что они восстановили объект Java и возможно другие атрибуты также. См. Объекты Java на том, как восстановить объект. Если объект не может быть восстановлен согласно RFC 2713, тогда возвращают объект DirContext представление записи LDAP. Провайдер должен использовать метод DirectoryManager.getObjectInstance, чтобы удовлетворить звонки в метод Binding.getObject. Имена, которые возвращаются, или относительно именованного контекста, или они - LDAP или URL LDAPS.
Context.lookup
Context.lookupLink
Выполните работу поиска базового объекта LDAP именованной записи, используя фильтр" (objectclass = *)". Запрос (возможно все) атрибуты для того, чтобы восстановить объект Java. См. Объекты Java на том, как восстановить объект. Провайдер должен использовать метод DirectoryManager.getObjectInstance, чтобы удовлетворить звонки в метод Binding.getObject.
DirContext.modifyAttributes
Выполните LDAP, изменяют работу при именованной записи, используя предоставленные модификации. Для перегруженный метод, который принимает Attributes, сначала преобразуйте параметр Attributes в упорядоченный список модификаций, перечисляя его содержание, используя Attributes.getAll() и снова используя параметр работы модификации (mod_op).
LdapContext.newInstance
Инициализируйте новый экземпляр этого контекста с указанными средствами управления запросом.
Context.rebind
DirContext.rebind
Этот метод может включить несколько различных операций LDAP. Сначала получите атрибуты существующей записи. Если существующая запись не существует, этот метод ведет себя то же самое как bind(). Иначе, если никакие атрибуты не были предоставлены, и связываемым объектом является DirContext, вызовите DirContext.getAttributes() и используйте результат в качестве параметра атрибутов (attrs). Если нет все еще никаких атрибутов, используйте атрибуты исходной записи в качестве attrs. Удалите существующую запись, используя LDAP, удаляют работу. Преобразуйте объект, обеспеченный в параметрах в атрибуты (как описано в разделе Объектов Java), и хранилище в записи наряду с attrs, используя LDAP добавляют работу. Провайдер должен использовать метод DirectoryManager.getStateToBind, чтобы преобразовать входной объект в форму, которую это может сохранить.
LdapContext.reconnect
Повторно соединитесь с сервером LDAP, используя предоставленные средства управления запросом соединения и текущие свойства среды.
Context.removeFromEnvironment
Удалите свойства среды контекста. Если многократные контексты совместно используют тот же самый набор свойств среды, провайдер должен заботиться, чтобы только изменить среду намеченного контекста. Изменение свойства среды могло бы потребовать изменений к существующему соединению, которое использует контекст.
Для всех свойств среды записывается новое свойство, даже если оно не влияет на контекст. Удаление свойства должно заставить контекст принимать значение по умолчанию свойства.
EventContext.removeNamingListener
Вычеркните из списка слушателя события именования так, чтобы последующие события, предназначенные для того слушателя, не были поставлены.
Context.rename
Выполните LDAP, изменяют работу DN, чтобы переименовать запись. Если LDAPv2 используется тогда, новое имя и старое название должны совместно использовать то же самое имя непосредственного родителя. Если родители не равны, тогда бросают InvalidNameException. Отметьте эффект java.naming.ldap.deleteRDN свойства на поведении этого метода.
DirContext.search
Выполните работу поиска LDAP согласно указанным средствам управления поиском. Если список требуемых атрибутов является нулем или содержит специальный идентификатор атрибута '*' тогда, все пользовательские атрибуты при записи LDAP возвращаются. Если операционные атрибуты требуются тогда, те идентификаторы атрибута должны присутствовать в списке требуемых атрибутов. Если объекты требуют быть возвращенными, то Java связанные с объектом атрибуты (RFC 2713) требуют в дополнение к любому, которого требует пользователь API. Если эти атрибуты присутствуют тогда, они используются, чтобы собрать исходные объекты (см. Объекты Java). Если объект не может быть восстановлен согласно RFC 2713, тогда возвращают объект DirContext представление записи LDAP. Провайдер должен использовать метод DirectoryManager.getObjectInstance, чтобы удовлетворить звонки в метод Binding.getObject. Имена, которые возвращаются, или относительно именованного контекста, или они - LDAP или URL LDAPS. Провайдер может использовать LDAP, сравнивают работу вместо поиска LDAP, когда предоставленный фильтр поиска соответственно ограничивается:
Фильтр должен иметь форму "(<attributeID>=<value>)"
Контекст должен быть объектным контекстом
Нулевые атрибуты нужно требовать (пустой список атрибутов возврата)
В формах поиска, которые принимают строковый фильтр как параметр, синтаксис фильтра следует за RFC 2254 за исключением того, что символы Unicode также позволяются. Использование символов Unicode предпочтительно для использования закодированных октетов UTF-8. Поставщик услуг ответственен за преобразование символов Unicode в их соответствующее представление UTF-8 для передачи к серверу. Например, альфа греческой буквы может быть определена в строковом фильтре или как "\u03B1" или как "\\CE\\B1".
В форме search(Name, Attributes) и связанные методы, параметр Attributes преобразовывается в строковый фильтр, создавая соединительное выражение из его элементов. Каждое значение атрибута обрабатывается как литерал; поэтому '*' и другие специальные символы, определенные в RFC 2254, которые появляются в значениях атрибута, должен быть оставлен согласно правилам в RFC 2254. Например, значение атрибута '*' должно быть закодировано как строка "\\2a".
В форме search(Name, String filterExpr, Object[] filterArgs) и его перегруженный метод String, "{цифровое}" расширение делается в фильтре, включая значения от filterArgs. Каждый" {цифровой}" компонент может появиться вместо "attr" или "значения" в Разделе 4 от RFC 2254.
Объекты в filterArgs должны быть закодированы следующим образом:
байтовые массивы (byte[]) кодируются, кодируя каждый байт как строка согласно RFC 2254. Например, массив {0, 1, 10, 100} кодируется как строка "\\00\\01\\0a\\64".
Строки обрабатываются как литералы. Другими словами, '*' и другие специальные символы, определенные в RFC 2254, которые появляются в строке, оставляются согласно правилам в RFC 2254. Например, строка "*" кодируется как строка "\\2a".
Объекты, которые не являются ни String, ни byte[], преобразовываются в их строковую форму, используя Object.toString() и затем правила для примененного String.
LdapContext.setRequestControls
Установите средства управления запросом для операций LDAP, впоследствии вызванных на этот контекст.
EventContext.targetMustExist
Определите, может ли слушатель зарегистрировать интерес к записи LDAP, которая не существует.
Context.unbind
Выполните LDAP, удаляют работу, чтобы удалить именованную запись. Именованная запись должна быть листовой записью; поддеревья не удаляются. Если листовая запись не существует (но ее родители существуют), работа все еще успешно выполняется.
11. Федерация
Поставщик услуг LDAP должен поддерживать федерацию, использующую разделение strong и или или оба из стыков или неявного следующего системного указателя именования.
12. SASL
Провайдер поддерживает механизмы SASL посредством Java API SASL (JSR 28). Это позволяет драйверам механизма SASL от различных поставщиков использоваться с провайдером LDAP, и также позволяет драйверу механизма SASL использоваться с различными провайдерами LDAP и даже non-LDAP библиотеки протокола.
API SASL Java зависит от Службы Аутентификации и авторизации Java (JAAS), который оказывает поддержку обратного вызова для механизмов SASL, которые должны получить или предоставить пользователя/информацию по применению непосредственно.
12.1 Конфигурация SASL
Определить, что аутентификация SASL использоваться, Вы определяете официальные зарегистрированные в IANA имена механизмов SASL в свойстве java.naming.security.authentication. Первый механизм SASL в списке, который и доступен и удовлетворяет дополнительно указанные политики, используется. Таким образом, свойства с префиксным "javax.security.sasl.policy." могут использоваться, чтобы управлять характеристиками безопасности выбранного механизма SASL.
Некоторые механизмы SASL требуют идентификационных данных аутентифицируемого объекта. Это известно как ID аутентификации. Некоторые механизмы SASL, как ОБЗОР-MD5, требуют использования пароля и/или области. По умолчанию провайдер предоставляет значение свойства java.naming.security.principal как ID аутентификации к любому механизму SASL, который требует ID аутентификации, значения свойства java.naming.security.credentials как пароль, и значение свойства java.naming.security.sasl.realm как область. Чтобы переопределить эти значения по умолчанию, используйте свойство java.naming.security.sasl.callback.
Механизмы SASL поддерживают понятие идентификационных данных авторизации или ID авторизации, который является объектом, к которому сервер должен предоставить доступ, если аутентификация успешно выполняется. Если свойство java.naming.security.sasl.authorizationId было установлено, то его значение используется в качестве ID авторизации. Иначе, пустая строка используется в качестве ID авторизации, который направляет сервер, чтобы получить ID авторизации из учетных данных аутентификации клиента.
См. свойства SASL для описания свойств, используемых поставщиком услуг LDAP для того, чтобы поддерживать SASL.
В дополнение к этим свойствам могли бы быть свойства, требуемые для определенных механизмов SASL. Например, механизм SASL, который поддерживает конфиденциальность и целостность, должен знать качество о защите, которой требует клиент. Свойства, такие как они передают к механизму SASL через свойства среды. См. документацию JNDI для того, как установить свойства среды.
Например, если приложение нуждается в конфиденциальности, оно может сделать так при использовании вызова, такого как:
env.put("javax.security.sasl.qop", "auth-conf");
прежде, чем передать env начальному конструктору контекста. См. Java API SASL для деталей об этих свойствах.
12.2 Драйверы Механизма SASL
Java API SASL служит основой для того, чтобы динамически включить драйверы механизма SASL. Провайдер LDAP мог бы обеспечить несколько драйверов значения по умолчанию. См. Java API SASL для деталей.
13. Расширения и Средства управления
Провайдер поддерживает расширения LDAP и средства управления, используя пакет javax.naming.ldap. Кроме того, провайдер поддерживает незапрашиваемые уведомления LDAP (которые передаются в LDAP расширенные ответы работы), использование служб пакета javax.naming.event.
Несколько расширений LDAP и средств управления определяются IETF LDAPEXT рабочая группа.
"Запускаются, TLS" расширение ("1.3.6.1.4.1.1466.20037") поддерживается классами StartTlsResponse и StartTlsRequest. Провайдер LDAP должен обеспечить конкретную реализацию абстрактного StartTlsResponse class и сделать его реализацию доступной для провайдера LDAP. См. описание в StartTlsRequest.createExtendedResponse. Как правило, реализация StartTlsResponse нуждалась бы в доступе к структурам данных провайдера LDAP.
Поставщик услуг LDAP должен выполнить проверку имени узла после того, как Начинают переговоры TLS как определено в RFC 2830. Если бы сервер LDAP был обнаружен автоматически при использовании информации в DNS (как описано в разделе URL), то провайдер должен использовать доменное имя, полученное из отличительного имени как имя узла, чтобы проверить, как рекомендующийся draft-ietf-ldapext-locate-08.txt.
14. Уведомление о событии
Провайдер поддерживает уведомление о событии, используя пакет javax.naming.event.
Приложение JNDI может зарегистрироваться для событий, которые происходят в каталоге, таком как дополнение или удаление записи, или модификация записи. Приложения могут также зарегистрироваться для незапрашиваемых уведомлений.
и выбирая имя узла и номер порта сервера LDAP, который поддерживает SSL. Как только соединение SSL было установлено, последующие обмены протокола LDAP имеют место по тому безопасному соединению.