Network Working Group Request for Comments: 4512 Категория: Standards Track K. Zeilenga, OpenLDAP Foundation Июнь 2006 года Отменяет: RFC 2251, RFC 2252, RFC 2256, RFC 3674
Этот документ определяет проект стандарта протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) Internet Society (2006).
Облегчённый протокол доступа к службам каталогов (Lightweight Directory Access Protocol, LDAP) — это Интернет-протокол для доступа к распределённым службам каталогов, функционирующим в соответствии с моделями данных и сервисов X.500. В этом документе описываются информационные модели каталога X.500, используемые в LDAP.
В этом документе обсуждаются информационные модели каталога X.500 [X.501], используемые протоколом Lightweight Directory Access Protocol (LDAP) [RFC4510].
Каталог — это "ряд открытых систем, взаимодействующих друг с другом для предоставления сервисов каталога" [X.500]. Содержащаяся в каталоге информация собирательно называется информационной базой каталога (Directory Information Base, DIB). Пользователь каталога, человек или другая сущность, получает доступ к каталогу посредством клиента (или пользовательского агента каталога (Directory User Agent, DUA)). Клиент от имени пользователя взаимодействует с одним или несколькими серверами (или системными агентами каталога (Directory System Agents, DSA)). На сервере хранится фрагмент DIB.
DIB содержит два класса информации:
Эти две модели, называемые обобщёнными информационными моделями каталога, описывают то, как информация представлена в каталоге. Эти обобщённые модели служат основой для других информационных моделей. В разделе 4 обсуждается информационная модель подсхемы (subschema) и исследование подсхемы. В разделе 5 обсуждается информационная модель DSA (сервера).
Другие информационные модели X.500 (такие как информационные модели знаний о распределении контроля доступа и знаний о репликации) могут быть адаптированы для использования в LDAP. Спецификация того, как такие модели будут применяться в LDAP, оставлена как предмет будущих документов.
Этот документ является неотъемлемой частью технической спецификации LDAP [RFC4510], полностью отменяющей определённую ранее техническую спецификацию LDAP, RFC 3377.
Этот документ отменяет разделы 3.2 и 3.4, а также части разделов 4 и 6 RFC 2251. Изменения этих разделов обобщены в приложении A.1. Остальные части RFC 2251 отменяются документами [RFC4511], [RFC4513] и [RFC4510].
Этот документ отменяет разделы 4, 5 и 7 RFC 2252. Изменения этих разделов обобщены в приложении A.2. Остальные части RFC 2252 отменяются документом [RFC4517].
Этот документ отменяет разделы 5.1, 5.2, 7.1 и 7.2 RFC 2256. Изменения этих разделов обобщены в приложении A.3. Остальные части RFC 2256 отменяются документами [RFC4519] и [RFC4517].
Этот документ полностью отменяет RFC 3674. Изменения этого RFC обобщены в приложении A.4.
В этот документ включены материалы из стандарта [X.501], как адаптированные по мере необходимости для описания данного протокола, так и неадаптированные. Произведённые адаптации (и любые другие различия в описании) применяются к данному протоколу и только к нему.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119]
Определения схемы данных даются с использованием форматов описания LDAP (как определено в разделе 4.1). Приводимые здесь определения отформатированы (произведено разбиение строк) с целью повышения читабельности. Спецификация правил соответствия и синтаксисов LDAP, упоминаемых в этих определениях, дана в [RFC4517].
Ряд синтаксисов в этом документе описывается с использованием расширенной формы Бэкуса-Наура (ABNF) [RFC4234]. Эти синтаксисы (как и ряд синтаксисов, определённых в других документах) основываются на следующих общих конструкциях:
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
NULL = %x00 ; ноль (0)
SPACE = %x20 ; пробел (" ")
DQUOTE = %x22 ; двойная кавычка (""")
SHARP = %x23 ; знак числа (или знак решётки) ("#")
DOLLAR = %x24 ; знак доллара ("$")
SQUOTE = %x27 ; одинарная кавычка ("'")
LPAREN = %x28 ; левая круглая скобка ("(")
RPAREN = %x29 ; правая круглая скобка (")")
PLUS = %x2B ; знак плюса ("+")
COMMA = %x2C ; запятая (",")
HYPHEN = %x2D ; дефис ("-")
DOT = %x2E ; точка (".")
SEMI = %x3B ; запятая (";")
LANGLE = %x3C ; левая угловая скобка ("<")
EQUALS = %x3D ; знак равенства ("=")
RANGLE = %x3E ; правая угловая скобка (">")
ESC = %x5C ; обратная косая черта ("\")
USCORE = %x5F ; знак подчёркивания ("_")
LCURLY = %x7B ; левая фигурная скобка "{"
RCURLY = %x7D ; правая фигурная скобка "}"
; Любой символ, закодированный UTF-8 [RFC3629] Unicode [Unicode]
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
OCTET = %x00-FF ; Любой октет (8-битовый блок данных)
Идентификаторы объектов (Object identifiers, OIDs) [X.680] представлены в LDAP с использованием точечно-цифрового формата, соответствующего следующей конструкции ABNF:
numericoid = number 1*( DOT number )
Короткие имена, известные также как дескрипторы, используются как более читабельное представление идентификаторов объектов. Короткие имена нечувствительны к регистру символов и соответствуют следующей конструкции ABNF:
descr = keystring
Там, где может быть указан как идентификатор объекта, так и короткое имя, используется следующая конструкция:
oid = descr / numericoid
Форма <descr>, как правило, предпочтительнее, когда короткие имена применяются для тех идентификаторов объектов, которые идентифицируют объекты с названиями, соответствующими этому короткому имени (например, описания типов атрибутов, правил соответствия или объектных классов); форму же <numericoid> следует использовать, когда идентификаторы объектов могут идентифицировать несколько видов объектов или когда недоступно короткое имя (дескриптор), исключающее неоднозначность.
Реализациям следует (SHOULD) интерпретировать короткие имена (дескрипторы), используемые неоднозначным образом (как обсуждалось выше), как нераспознанные.
Короткие имена (дескрипторы) обсуждаются далее в разделе 6.2.
Как утверждается в стандарте [X.501]:
Назначение каталога — хранение и обеспечение доступа к информации об объектах, представляющих интерес в некоторой области ("мире"). Объектом может быть что угодно, поддающееся идентификации (именованию).
Объектный класс — это идентифицированное семейство объектов или потенциальных объектов, имеющих общие характеристики. Каждый объект принадлежит как минимум одному классу. Объектный класс может быть подклассом других объектных классов, в этом случае члены данного нижестоящего класса (подкласса) считаются также членами вышестоящих классов (суперклассов). Могут существовать подклассы подклассов и т.д., глубина вложенности не ограничена.
Запись каталога, — именованная коллекция информации, — это базовая единица хранимой в каталоге информации. Существует несколько типов записей каталога.
Запись-объект представляет собой конкретный объект. Запись-псевдоним предоставляет альтернативное именование объекта. Подзапись (subentry) содержит административную и/или операционную информацию.
Представляющий DIB набор записей иерархически организован в виде древовидной структуры, называемой информационным деревом каталога (Directory Information Tree, DIT).
В разделе 2.1 описывается информационное дерево каталога.
В разделе 2.2 обсуждается структура записей.
В разделе 2.3 обсуждается именование записей.
В разделе 2.4 обсуждаются объектные классы.
В разделе 2.5 обсуждаются описания атрибутов.
В разделе 2.6 обсуждаются записи-псевдонимы.
Как отмечалось выше, DIB состоит из набора записей, иерархически организованных в виде древовидной структуры, называемой информационным деревом каталога (Directory Information Tree, DIT); конкретнее, в виде дерева, вершинами которого являются записи.
Соединения между вершинами определяют отношения между записями. Если существует соединение от X к Y, то запись в вершине X является непосредственно вышестоящей (superior) записью по отношению к записи в вершине Y, а Y — непосредственно нижестоящей (subordinate) по отношению к X. Вышестоящими по отношению к какой-либо записи являются запись, непосредственно вышестоящая исходной записи, и вышестоящие по отношению к ней. Нижестоящими по отношению к какой-либо записи являются все записи, непосредственно нижестоящие по отношению к исходной записи, и нижестоящие по отношению к ним.
Аналогичным образом, отношения вышестоящий/нижестоящий между записями объектов могут быть использованы для получения отношений между объектами, которые они представляют. Правила структуры DIT могут быть использованы для определения взаимоотношений между объектами.
Примечание: Запись, непосредственно вышестоящая по отношению к какой-либо записи, также называется родительской (parent) записью по отношению к ней, а запись, непосредственно нижестоящая по отношению к какой-либо записи, также называется дочерней (child) записью по отношению к ней. Записи, у которых одна и та же родительская запись, также называются одноуровневыми (sibling) записями.
Запись состоит из набора атрибутов, содержащих информацию о том объекте, который представлен этой записью. Одни атрибуты представляют пользовательскую информацию и называются пользовательскими атрибутами. Другие атрибуты представляют операционную и/или административную информацию и называются операционными атрибутами.
Атрибут — это описание атрибута (тип и ноль или более опций) с одним или несколькими ассоциированными значениями. На атрибут часто указывают с помощью описания этого атрибута. Например, атрибут 'givenName' — это атрибут, состоящий из описания атрибута 'givenName' (тип атрибута 'givenName' [RFC4519] и ноль опций) и одного или более ассоциированных значений.
Тип атрибута определяет, может ли атрибут иметь несколько значений, синтаксис и правила соответствия, используемые для построения и сравнения значений этого атрибута, и другие функции. Опции указывают подтипы и другие функции.
Значения атрибута соответствуют синтаксису, определенному типом атрибута.
Никакие два значения атрибута не могут быть эквивалентны. Два значения считаются эквивалентными, если и только если они будут равны по правилу соответствия equality этого типа атрибута. Либо, если тип атрибута определён без правила соответствия equality, два значения являются эквивалентными если и только если они идентичны. (Другие ограничения смотрите в разделе 2.5.1.)
Например, атрибут 'givenName' может иметь более одного значения, эти значения должны соответствовать синтаксису Directory String и быть нечувствительными к регистру символов. В атрибуте 'givenName' не могут одновременно содержаться значения "John" и "JOHN", поскольку они являются эквивалентными согласно правилу соответствия equality этого типа атрибута.
Кроме того, никакой атрибут не должен иметь значение, которое не соответствует само себе. Например, атрибут 'givenName' не может иметь в качестве значения строку, содержащую код символа замещения (REPLACEMENT CHARACTER, U+FFFD), поскольку проверка такой строки на соответствие по правилу соответствия equality этого атрибута приведёт к результату Undefined.
Когда атрибут используется для именования записи, одно и только одно значение этого атрибута используется для формирования относительного уникального имени (Relative Distinguished Name). Это значение называется отличительным значением.
Каждая запись именуется относительно своей непосредственно вышестоящей записи. Это относительное имя, известное как относительное уникальное имя (RDN) записи [X.501], состоит из неупорядоченного набора одного или нескольких утверждений значений атрибутов (attribute value assertions, AVA), которые, в свою очередь, состоят из описания атрибута без опций и значения атрибута. Эти AVA выбираются так, чтобы они соответствовали значениям атрибутов записи (каждое такое значение должно быть отличительным значением).
Относительное уникальное имя записи должно быть уникально среди записей, являющихся непосредственно подчинёнными записи, непосредственно вышестоящей относительно целевой записи (то есть всех одноуровневых записей относительно целевой записи).
Примеры строкового представления RDN [RFC4514]:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
Последний пример демонстрирует многозначное RDN, то есть RDN, состоящее из нескольких AVA.
Полностью определенное имя записи, известное как уникальное имя (DN) [X.501], представляет собой конкатенацию RDN этой записи и DN непосредственно вышестоящей по отношению к ней записи. Уникальное имя однозначно указывает на запись в дереве. Примеры строкового представления DN [RFC4514]:
UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
Псевдоним — это "имя для объекта, обеспечиваемое путём использования записей-псевдонимов" [X.501]. Записи-псевдонимы описываются в разделе 2.6.
Объектный класс — это "идентифицированное семейство объектов (или возможных объектов) с некоторыми общими характеристиками" [X.501].
Как определено в стандарте [X.501]:
Объектные классы используются в каталоге для ряда задач, в число которых входят:
- описание и классификация объектов и записей, соответствующих этим объектам;
- управление работой каталога (где это уместно);
- регулирование положения записей в DIT (в сочетании со спецификацией правил структуры DIT);
- регулирование содержащихся в записях атрибутов (в сочетании со спецификацией правил содержимого DIT);
- идентификация классов записей, которые должны быть ассоциированы с какой-либо специфической политикой путём применения к ним соответствующих административных полномочий.
Объектный класс (подкласс) может являться производным от объектного класса (его прямой суперкласс), который, в свою очередь, может являться производным от ещё более общего объектного класса. Для структурных объектных классов этот процесс оканчивается наиболее общим объектным классом 'top' (определение смотрите в разделе 2.4.1). Упорядоченный набор суперклассов объектного класса, вплоть до самого вышестоящего по отношению к нему объектного класса, называется его цепочкой суперклассов.
Объектный класс может являться производным от двух или более прямых суперклассов (то есть суперклассов, не являющихся частью одной и той же цепочки суперклассов). Эта особенность создания подклассов называется множественным наследованием.
Каждый объектный класс определяет набор атрибутов, присутствие которых в принадлежащих к этому классу записях необходимо, и набор атрибутов, присутствие которых в принадлежащих к этому классу записях допускается. Поскольку запись какого-либо класса должна соответствовать требованиям каждого класса, к которому он принадлежит, можно сказать, что объектный класс наследует наборы допустимых и необходимых атрибутов от своих суперклассов. Подкласс может определять в качестве необходимого атрибут, определённый в его суперклассе как допустимый. Если атрибут входит в оба подмножества, его присутствие необходимо.
Каждый объектный класс должен быть одного из трёх видов: абстрактный (Abstract), структурный (Structural) или вспомогательный (Auxiliary).
Каждый объектный класс идентифицируется идентификатором объекта (OID) и, опционально, одним или несколькими короткими именами (дескрипторами).
Абстрактный объектный класс, как следует из названия, предоставляет базовый набор характеристик, от которого могут быть унаследованы определения других объектных классов. Запись не может принадлежать абстрактному объектному классу напрямую, она может принадлежать структурному или вспомогательному классу, унаследованному от этого абстрактного класса.
Абстрактные объектные классы не могут являться производными от структурных или вспомогательных объектных классов.
Все структурные объектные классы являются производными (напрямую или не напрямую) от абстрактного объектного класса 'top'. Вспомогательные объектные классы не обязательно являются производными от 'top'.
Определение объектного класса (смотрите раздел 4.1.1) для объектного класса 'top':
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
Все записи принадлежат к абстрактному объектному классу 'top'.
Как утверждается в стандарте [X.501]:
Объектный класс, определенный для использования в структурной спецификации DIT, называется структурным объектным классом. Структурные объектные классы используются в определении структуры имён объектов для согласующихся записей.
Запись-объект или запись-псевдоним характеризуется исключительно одной цепочкой суперкласса структурных объектных классов, которая имеет единственный структурный объектный класс в качестве наиболее нижестоящего объектного класса. Этот структурный объектный класс называется структурным объектным классом данной записи.
Структурные объектные классы соотносятся с ассоциированными записями следующим образом:
- запись, соответствующая структурному объектному классу, представляет объект реального мира, входящий в данных объектный класс;
- правила структуры DIT относятся только к структурным объектным классам; структурный объектный класс записи используется для указания местоположения записи в DIT;
- структурный объектный класс записи, наряду с соответствующим правилом содержимого DIT, используется для управления содержимым записи.
Структурный объектный класс записи не должен изменяться.
Каждый структурный объектный класс является подклассом (прямым или непрямым) абстрактного объектного класса 'top'.
Структурные объектные классы не могут быть подклассами вспомогательных объектных классов.
Каждая запись, как говорят, принадлежит к своему структурному объектному классу, а также ко всем классам в цепочке суперклассов своего структурного объектного класса.
Вспомогательные объектные классы используются для расширения характеристик записей. В основном они используются для расширения наборов атрибутов, наличие которых в записи необходимо и допускается. Они могут использоваться для описания записей или классов записей.
Вспомогательные объектные классы не могут быть подклассами структурных объектных классов.
Запись может принадлежать любому подмножеству множества вспомогательных объектных классов, разрешённых правилом содержимого DIT, связанным со структурным объектным классом этой записи. Если со структурным объектным классом записи не связано никакого правила содержимого DIT, эта запись не может принадлежать к какому-либо вспомогательному объектному классу.
Набор вспомогательных объектных классов, к которым принадлежит запись, может со временем изменяться.
Описание атрибута состоит из типа атрибута (смотрите раздел 2.5.1) и набора из нуля или более опций атрибута (смотрите раздел 2.5.2).
Описание атрибута представлено следующей ABNF:
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar
где <attributetype> идентифицирует тип атрибута и каждое <option> идентифицирует опцию атрибута. Обе конструкции <attributetype> и <option> нечувствительны к регистру символов. Порядок указания опций <option> значения не имеет. То есть, любые два описания атрибута <attributedescription>, состоящие из одинакового типа <attributetype> и одинакового набора опций <option>, являются эквивалентными.
Примеры допустимых описаний атрибутов:
2.5.4.0
cn;lang-de;lang-en
owner
Описание атрибута с нераспознанным типом атрибута должно трактоваться как нераспознанное. Серверам следует (SHALL) интерпретировать описание атрибута с нераспознанной опцией атрибута как нераспознанное. Клиенты могут (MAY) интерпретировать нераспознанную опцию атрибута как опцию пометки (смотрите раздел 2.5.2.1).
Все атрибуты записи должны иметь определённые (распознаваемые) описания атрибутов.
Тип атрибута определяет, может ли атрибут иметь несколько значений, синтаксис и правила соответствия, используемые для построения и сравнения значений этого атрибута, и другие функции.
Если для типа атрибута не определено соответствие equality, то:
В противном случае, для оценки утверждений значений атрибута соответствующего типа атрибута будет использоваться заданное правило соответствия equality. Заданное правило соответствия equality должно быть транзитивным и коммутативным.
Тип атрибута указывает, является этот атрибут пользовательским или операционным. В случае операционного атрибута, тип атрибута указывает операционное применение атрибута, а также возможно ли изменение атрибута пользователями. Операционные атрибуты обсуждаются в разделе 3.4.
Тип атрибута (подтип) может являться производным от более общего типа атрибута (его прямой супертип). На образование подтипов накладываются следующие ограничения:
Описание атрибута, состоящее из подтипа без указания опций, считается прямым подтипом описания атрибута, состоящего из прямого супертипа этого атрибута без указания опций.
Каждый тип атрибута идентифицируется идентификатором объекта (OID) и, опционально, одним или несколькими короткими именами (дескрипторами).
Существует несколько видов опций описания атрибута. В технической спецификации LDAP подробно описан один вид: опции пометки (tagging options).
Не все опции могут быть связаны с содержащимися в каталоге атрибутами. Опции пометки могут.
Не все опции могут использоваться в сочетании со всеми типами атрибутов. В таких случаях описание атрибута должно трактоваться как нераспознанное.
Описание атрибута, содержащее взаимоисключающие опции, должно трактоваться как нераспознанное. То есть, описание "cn;x-bar;x-foo", где опции "x-foo" и "x-bar" являются взаимоисключающими, должно трактоваться как нераспознанное.
В последующих документах могут быть определены другие виды опций. Такие документы должны детализировать как определённые в них новые виды опций соотносятся с опциями пометки. В частности, эти документы должны детализировать, могут ли новые виды опций быть связаны с содержащимися в каталоге атрибутами, как новые виды опций влияют на передачу значений атрибутов, и как новые виды опций трактуются в иерархиях описаний атрибутов.
Опции представляются в виде коротких, не чувствительных к регистру символов текстовых строк, соответствующих конструкции <option>, определённой в разделе 2.5 этого документа.
Процедуры регистрации опций подробно описаны в BCP 64 [RFC4520].
Содержащиеся в каталоге атрибуты могут иметь описания атрибутов с любым количеством опций пометки. Опции пометки никогда не бывают взаимоисключающими.
Описание атрибута с N опциями пометки является прямым подтипом (описания) всех описаний атрибута того же типа атрибута и всех, кроме одной, из этих N опций. Если у типа атрибута есть супертип, то описание этого атрибута также является прямым подтипом (описания) описания атрибута его сурептипа и N опций пометки. То есть, описание 'cn;lang-de;lang-en' является прямым подтипом (описания) 'cn;lang-de', 'cn;lang-en' и 'name;lang-de;lang-en' (поскольку 'cn' — это подтип 'name'; оба типа атрибута определены в [RFC4519]).
Описание атрибута может быть прямым подтипом нуля или более других описаний атрибутов по правилам образования подтипов от типов атрибутов (смотрите раздел 2.5.1), либо по правилам образования подтипов с опциями пометки (смотрите раздел 2.5.2.1). Эти отношения образования подтипов применяются для формирования иерархий описаний атрибутов и иерархий атрибутов.
Адаптированная выдержка из стандарта [X.501]:
Иерархия атрибутов позволяет осуществлять доступ к DIB с различной степенью детализации. Это достигается благодаря разрешению доступа к компонентам значения атрибутов путем использования либо их конкретного описания атрибута (прямая ссылка на атрибут), либо более общего описания атрибута (косвенная ссылка).
Семантически связанные атрибуты могут быть выстроены в иерархическую структуру, в которой более конкретные описания атрибутов располагаются как подчиненные по отношению к более общим. Поиск или считывание атрибутов и их значений облегчается при указании более общего описания атрибута; определенный таким образом элемент фильтра оценивается для более конкретных описаний, а также для указанного описания.
Если в качестве результата поиска выбраны конкретные описания атрибутов, являющиеся подчиненными, должны возвращаться эти описания, если таковые имеются. Если в качестве результата поиска выбраны более общие описания атрибутов, должны возвращаться как общие, так и конкретные описания, если таковые имеются. Значение атрибута всегда должно возвращаться как значение своего собственного описания атрибута.
При изменении пользователем содержимого записи все описания атрибутов в иерархии атрибутов трактуются как отдельные и несвязанные описания.
Значение атрибута, хранящееся в записи-объекте или записи-псевдониме, имеет только одно описание атрибута. Это описание указывается при первом добавлении значения в запись.
При администрировании подсхемы записи, спецификация того, что какой-либо атрибут является обязательным, считается выполненной, если запись содержит значение атрибута с описанием, принадлежащим иерархии атрибутов, и тип атрибута из этого описания совпадает с требуемым типом атрибута. То есть, спецификация "MUST name" считается выполненной при использовании 'name' или 'name;x-tag-option', но не считается выполненной при использовании 'CN' или 'CN;x-tag-option' (даже если 'CN' является подтипом 'name'). Также в записи разрешено иметь значение атрибута с описанием, принадлежащим иерархии атрибутов, когда тип атрибута из этого описания либо явно включен в определение объектного класса, к которому принадлежит запись, либо разрешён применимым к этой записи правилом содержимого DIT. То есть, 'name' и 'name;x-tag-option' являются разрешёнными определением "MAY name" (или "MUST name"), но 'CN' и 'CN;x-tag-option' не являются разрешёнными определением "MAY name" (или "MUST name").
При администрировании какой-либо другой политики, если иное не указано в спецификации конкретной административной модели, все описания атрибутов в иерархии атрибутов трактуются как отдельные и не связанные между собой описания.
Адаптированная выдержка из стандарта [X.501]:
Псевдоним или имя-псевдоним объекта — это альтернативное имя для объекта или записи объекта, обеспечиваемое использованием записей-псевдонимов.
Каждая запись-псевдоним содержит имя некоторого объекта в атрибуте 'aliasedObjectName' (в стандарте X.500 он назывался 'aliasedEntryName'). Таким образом, уникальное имя записи-псевдонима также является именем для этого объекта.
ПРИМЕЧАНИЕ - Считается, что псевдоним указывает на имя из атрибута 'aliasedObjectName'. Это имя не обязательно должно быть уникальным именем какой-либо записи.
Преобразование имени псевдонима в имя объекта называется разыменованием (псевдонима) и заключается в семантической замене имен-псевдонимов, которые обнаруживаются в ходе анализа потенциального имени, на значение соответствующего атрибута 'aliasedObjectName'. Этот процесс может потребовать анализа более одной записи-псевдонима.
Любая конкретная запись в DIT может иметь нуль или более имен-псевдонимов. Отсюда следует, что несколько записей-псевдонимов могут указывать на одну и ту же запись. Запись-псевдоним может указывать на запись, не являющуюся конечной (листовой) записью, а также может указывать на другую запись-псевдоним.
У записи-псевдонима не должно быть нижестоящих записей, то есть запись-псевдоним всегда является листовой записью.
Каждая запись-псевдоним должна принадлежать объектному классу 'alias'.
Запись с объектным классом 'alias' должна также принадлежать к объектному классу (или классам), либо регулироваться правилом содержимого DIT, которые позволили бы определить ей подходящие атрибуты именования.
Пример:
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com
Записи-псевдонимы принадлежат объектному классу 'alias'.
( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
Атрибут 'aliasedObjectName' содержит имя записи, на которую указывает псевдоним. В стандарте X.500 атрибут 'aliasedObjectName' назывался 'aliasedEntryName'.
( 2.5.4.1 NAME 'aliasedObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
Правило соответствия 'distinguishedNameMatch' и синтаксис DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) определены в [RFC4517].
В этом разделе рассматриваются избранные аспекты модели административной и операционной информации каталога X.500 [X.501]. Реализации LDAP могут (MAY) поддерживать другие аспекты этой модели.
Как определено в стандарте [X.501]:
Поддерево — это коллекция записей-объектов и записей-псевдонимов, расположенных в вершинах дерева. Поддеревья не содержат подзаписей. Приставка "под" в слове "поддерево" специально указывает на то, что база (или корень) вершины данного дерева, как правило, является подчиненной по отношению к корню DIT.
Поддерево начинается в какой-либо вершине и простирается до некоторой идентифицируемой нижней границы, и может простираться до листовых записей. Поддерево всегда определяется в контексте, который неявно указывает границы этого поддерева. Например, вершина и нижняя граница поддерева, определяющего реплицируемую область, ограничиваются контекстом именования.
Подзапись — это "специальный вид записи, известный каталогу, который используется для содержания информации, связанной с поддеревом или уточнением поддерева" [X.501]. Подзаписи используются в каталоге для хранения данных в административных и операционных целях, как определено в стандарте [X.501]. Их использование в LDAP подробно раскрыто в [RFC3672].
Термин "(под)запись" в данной спецификации указывает на то, что серверы, реализующие модели X.500(93), должны, согласно описанным в [RFC3672] определениям X.500(93), использовать подзаписи, а также на то, что другие серверы должны использовать записи-объекты, принадлежащие соответствующему вспомогательному классу, обычно используемому с подзаписями (например, 'subschema' для подзаписей подсхемы) для имитации подзаписей. RDN этих записей-объектов должны (SHALL) быть сформированы от значения атрибута 'cn' (commonName) [RFC4519] (поскольку все подзаписи именуются с использованием 'cn').
У каждой записи в DIT есть атрибут 'objectClass'.
( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
Правило соответствия 'objectIdentifierMatch' и синтаксис OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) определены в [RFC4517].
Атрибут 'objectClass' определяет объектные классы записи, которые (среди прочего) используются, в сочетании с управляющей схемой данных, для определения разрешённых атрибутов записи. Значения этого атрибута могут быть модифицированы клиентами, но атрибут 'objectClass' не может быть удалён.
Серверы, следующие моделям X.500(93), должны (SHALL) ограничивать модификации данного атрибута для предотвращения изменения основного структурного класса записи. То есть, никто не может изменить объектный класс с 'person' на 'country'.
При создании записи или добавлении к записи значения атрибута 'objectClass', все суперклассы указываемых классов должны (SHALL) быть также неявно добавлены, если это ещё не было сделано. То есть, если вспомогательный класс 'x-a' является подклассом класса 'x-b', добавления значения 'x-a' к атрибуту 'objectClass' приведёт к неявному добавлению 'x-b' (если его ещё не было в записи).
Серверы должны (SHALL) ограничивать модификации данного атрибута для предотвращения удаления суперклассов от других значений атрибута 'objectClass'. То есть, если вспомогательный класс 'x-a' является подклассом вспомогательного класса 'x-b' и атрибут 'objectClass' содержит 'x-a' и 'x-b', то попытка удалить только 'x-b' из атрибута 'objectClass' является ошибкой.
Некоторые атрибуты, называемые операционными, используются или поддерживаются серверами для административных или операционных целей. Как заявляется в стандарте [X.501]: "Есть три разновидности операционных атрибутов: операционные атрибуты каталога, операционные атрибуты, коллективно используемые агентами DSA (DSA-shared) и операционные атрибуты, специфичные для DSA (DSA-specific)".
Операционные атрибуты каталога используются для представления операционной и/или административной информации в информационной модели каталога. Сюда входят операционные атрибуты, поддерживаемые сервером (например, 'createTimestamp'), а также операционные атрибуты, содержащие управляемые пользователем значения (например, 'ditContentRules').
Операционные атрибуты, коллективно используемые агентами DSA, используются для представления общей для нескольких DSA информации информационной модели DSA.
Операционные атрибуты, специфичные для DSA, используются для представления специфичной для конкретного DSA информации информационной модели DSA (тем не менее, в некоторых случаях, эта информация может быть получена из общей для нескольких DSA информации; например, 'namingContexts').
Операционные атрибуты информационной модели DSA подробно описаны в стандарте [X.501].
Операционные атрибуты обычно невидимы. Они не возвращаются в результатах поисковых запросов, если не были явно запрошены по имени.
Не все операционные атрибуты доступны для модификации пользователем.
Среди прочих, записи могут содержать следующие операционные атрибуты:
Серверам следует (SHOULD) поддерживать атрибуты 'creatorsName', 'createTimestamp', 'modifiersName' и 'modifyTimestamp' для всех записей в DIT.
Этот атрибут появляется в записях, добавленных с использованием протокола (например, с использованием операции Add). Значение — уникальное имя записи создателя.
( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Правило соответствия 'distinguishedNameMatch' и синтаксис DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) определены в [RFC4517].
Этот атрибут появляется в записях, добавленных с использованием протокола (например, с использованием операции Add). Значение — время создания записи.
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Правила соответствия 'generalizedTimeMatch' и 'generalizedTimeOrderingMatch', а также синтаксис GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) определены в [RFC4517].
Этот атрибут появляется в записях, модифицированных с использованием протокола (например, с использованием операции Modify). Значение — уникальное имя записи пользователя, производившего последнюю модификацию.
( 2.5.18.4 NAME 'modifiersName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Правило соответствия 'distinguishedNameMatch' и синтаксис DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) определены в [RFC4517].
Этот атрибут появляется в записях, модифицированных с использованием протокола (например, с использованием операции Modify). Значение — время последней модификации.
( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Правила соответствия 'generalizedTimeMatch' и 'generalizedTimeOrderingMatch', а также синтаксис GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) определены в [RFC4517].
Этот атрибут указывает структурный объектный класс записи.
( 2.5.21.9 NAME 'structuralObjectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Правило соответствия 'objectIdentifierMatch' и синтаксис OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) определены в [RFC4517].
Этот атрибут указывает регулирующее запись правило структуры.
( 2.5.21.10 NAME 'governingStructureRule'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Правило соответствия 'integerMatch' и синтаксис INTEGER (1.3.6.1.4.1.1466.115.121.1.27) определены в [RFC4517].
Как определено в стандарте [X.501]:
Схема данных каталога — это совокупность определений и ограничений, касающихся структуры DIT, возможных способов именования записей, информации, которая может содержаться в записи, атрибутов, используемых для представления этой информации, и их организации в иерархии для упрощения поиска и извлечения информации, а также способов, по которым значения атрибутов могут быть сопоставлены в утверждениях значений атрибута и в утверждениях правил соответствия.
ПРИМЕЧАНИЕ 1 - Схема данных позволяет системе каталога, например:
- предотвращать создание подчиненных записей неверного объектного класса (например, country как подчиненный элемент по отношению к person);
- предотвращать добавление к записи типов атрибутов, не соответствующих объектному классу (например, serial number к записи с объектным классом person);
- предотвращать добавление значения атрибута, синтаксис которого не соответствует определенному для этого типа атрибута (например, printable string к bit string).
Формально схему данных каталога образуют:
- описания форм имен, которые определяют элементарные отношения именования для структурных объектных классов;
- описания правил структуры DIT, определяющие имена, которые могут иметь записи, и способы, с помощью которых записи могут быть связаны друг с другом в DIT;
- описания правил содержимого DIT, которые расширяют спецификацию разрешенных для включения в записи атрибутов, не являющихся атрибутами структурных объектных классов этих записей;
- описания объектных классов, определяющие базовое множество обязательных и необязательных атрибутов, которые, соответственно, должны и могут присутствовать в записи данного класса, и указывающие вид определяемого объектного класса;
- описания типов атрибутов, определяющие идентификатор объекта, по которому известен атрибут, его синтаксис, связанные правила соответствия, является ли этот атрибут операционным атрибутом, и, если является, то его тип, является ли этот атрибут коллективным атрибутом, разрешено ли ему иметь несколько значений, и является ли он производной другого типа атрибута;
- описания правил соответствия, определяющие правила сопоставления значений атрибутов.
И в LDAP:
- описания синтаксисов LDAP, определяющие используемые в LDAP кодировки.
Определения схемы данных в этом разделе описаны с использованием ABNF и основываются на общих конструкциях, определённых как в разделе 1.2, так и в этом разделе:
noidlen = numericoid [ LCURLY len RCURLY ]
len = number
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; экранированная строка UTF-8
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
; Любой символ Unicode, закодированный UTF-8,
; за исключением %x27 ("\'") и %x5C ("\")
QUTF8 = QUTF1 / UTFMB
; Любой символ ASCII, за исключением %x27 ("\'") и %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F
В определениях схемы данных в этом разделе также используются несколько общих именованных полей.
В поле NAME предоставляется набор коротких имён (дескрипторов), которые должны использоваться как псевдонимы для OID.
Поле DESC позволяет администратору каталога и/или тому, кто занимается реализацией, опционально предоставить строку описания. Хотя в спецификациях может предлагаться строка описания, требований о том, чтобы предлагаемая (или любая другая) строка описания использовалась, не выдвигается.
Поле OBSOLETE, при его наличии, указывает, что элемент является неактивным.
Тем, кто занимается реализацией, следует иметь ввиду, что в будущих версиях этого документа данные определения могут быть расширены за счёт включения дополнительных именованных полей. Поля, идентификаторы которых начинаются с "X-", зарезервированы для частных экспериментов, за ними должны следовать конструкции <SP> и <qdstrings>.
Определения объектных классов формулируются в соответствии со следующей ABNF:
ObjectClassDescription = LPAREN WSP
numericoid ; идентификатор объекта
[ SP "NAME" SP qdescrs ] ; короткие имена (дескрипторы)
[ SP "DESC" SP qdstring ] ; описание
[ SP "OBSOLETE" ] ; неактивен
[ SP "SUP" SP oids ] ; вышестоящие объектные классы
[ SP kind ] ; вид класса
[ SP "MUST" SP oids ] ; типы атрибутов
[ SP "MAY" SP oids ] ; типы атрибутов
extensions WSP RPAREN
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
здесь:
Определения типов атрибутов формулируются в соответствии со следующей ABNF:
AttributeTypeDescription = LPAREN WSP
numericoid ; идентификатор объекта
[ SP "NAME" SP qdescrs ] ; короткие имена (дескрипторы)
[ SP "DESC" SP qdstring ] ; описание
[ SP "OBSOLETE" ] ; неактивен
[ SP "SUP" SP oid ] ; супертип
[ SP "EQUALITY" SP oid ] ; правило соответствия equality
[ SP "ORDERING" SP oid ] ; правило соответствия ordering
[ SP "SUBSTR" SP oid ] ; правило соответствия substrings
[ SP "SYNTAX" SP noidlen ] ; синтаксис значения
[ SP "SINGLE-VALUE" ] ; единственное значение
[ SP "COLLECTIVE" ] ; коллективный
[ SP "NO-USER-MODIFICATION" ] ; не изменяемый пользователем
[ SP "USAGE" SP usage ] ; сфера применения
extensions WSP RPAREN ; расширения
usage = "userApplications" / ; пользовательский атрибут
"directoryOperation" / ; операционный атрибут каталога
"distributedOperation" / ; операционный атрибут DSA-shared
"dSAOperation" ; операционный атрибут DSA-specific
здесь:
Каждое описание типа атрибута должно содержать как минимум одно из полей SUP или SYNTAX. Если поле SYNTAX не предоставлено, описание типа атрибута принимает своё значение от супертипа.
Если предоставлено поле SUP, поля EQUALITY, ORDERING и SUBSTRING, если они не указаны, принимают свои значения от супертипа.
Сфера применения userApplications (по умолчанию) говорит о том, что атрибуты этого типа представляют пользовательскую информацию. То есть, это пользовательские атрибуты.
Сферы применения directoryOperation, distributedOperation или dSAOperation говорят о том, что атрибуты этого типа представляют операционную и/или административную информацию. То есть, это операционные атрибуты.
Сфера применения directoryOperation указывает, что атрибут этого типа является операционным атрибутом каталога. Сфера применения distributedOperation указывает, что атрибут этого типа является операционным атрибутом, коллективно используемым агентами DSA. Сфера применения dSAOperation указывает, что атрибут этого типа является операционным атрибутом, специфичным для DSA.
Поле COLLECTIVE требует, чтобы сфера применения типа атрибута была userApplications. Использование коллективных атрибутов в LDAP рассматривается в [RFC3671].
Поле NO-USER-MODIFICATION требует операционной сферы применения типа атрибута.
Обратите внимание, что в конструкции <AttributeTypeDescription> не перечисляются правила соответствия, которые можно использовать с этим типом атрибута в поисковом фильтре extensibleMatch [RFC4511]. Это делается с помощью атрибута 'matchingRuleUse', описанного в разделе 4.1.4.
В этом документе уточняется описание схемы данных X.501: выдвигается требование, что поле SYNTAX в конструкции <AttributeTypeDescription> должно быть строковым представлением идентификатора объекта для строкового определения синтаксиса LDAP с опциональным указанием рекомендуемой минимальной верхней границы значения этого атрибута.
Рекомендуемая минимальная верхняя граница (по количеству символов в значениях с синтаксисами, основанными на строках, либо по количеству байт в значениях с любыми другими синтаксисами), может быть указана путём добавления числа в фигурных скобках вслед за идентификатором объекта синтаксиса в описании типа атрибута. Эта граница не является частью самого названия синтаксиса. Например, в формулировке "1.3.6.4.1.1466.0{64}" рекомендуется, чтобы реализации сервера позволяли строке быть длиной в 64 символа, но они могут позволить и более длинные строки. Имейте ввиду, что один символ в синтаксисе Directory String может быть закодирован более чем одним октетом, поскольку UTF-8 [RFC3629] является кодировкой с переменным размером символа.
Правила соответствия используются при выполнении действий с утверждениями значений атрибутов, например, при выполнении операции Compare. Также они используются при оценке поисковых фильтров, определении того, какие индивидуальные значения должны быть добавлены или удалены в ходе выполнения операции Modify, и при сравнении уникальных имён.
Каждое правило соответствия идентифицируется идентификатором объекта (OID) и, опционально, одним или несколькими короткими именами (дескрипторами).
Определения правил соответствия формулируются в соответствии со следующей ABNF:
MatchingRuleDescription = LPAREN WSP
numericoid ; идентификатор объекта
[ SP "NAME" SP qdescrs ] ; короткие имена (дескрипторы)
[ SP "DESC" SP qdstring ] ; описание
[ SP "OBSOLETE" ] ; неактивно
SP "SYNTAX" SP numericoid ; синтаксис утверждения
extensions WSP RPAREN ; расширения
здесь:
В так называемом применении правила соответствия перечисляются типы атрибутов, которые подходят для использования с поисковым фильтром extensibleMatch.
Описания применений правил соответствия формулируются в соответствии со следующей ABNF:
MatchingRuleUseDescription = LPAREN WSP
numericoid ; идентификатор объекта
[ SP "NAME" SP qdescrs ] ; короткие имена (дескрипторы)
[ SP "DESC" SP qdstring ] ; описание
[ SP "OBSOLETE" ] ; неактивно
SP "APPLIES" SP oids ; типы атрибутов
extensions WSP RPAREN ; расширения
здесь:
Синтаксисы значений (атрибутов и утверждений) LDAP описываются в терминах ASN.1 [X.680] и, опционально, имеют кодировку строки октетов, известную как специфичная для LDAP кодировка. Обычно, специфичная для LDAP кодировка сводится к строке символов Unicode [Unicode] в форме UTF-8 [RFC3629].
Каждый синтаксис LDAP идентифицируется по идентификатору объекта (OID).
Определения синтаксисов LDAP формулируются в соответствии со следующей ABNF:
SyntaxDescription = LPAREN WSP
numericoid ; идентификатор объекта
[ SP "DESC" SP qdstring ] ; описание
extensions WSP RPAREN ; расширения
здесь:
Правило содержимого DIT — это "правило, регулирующее содержимое записей конкретного структурного объектного класса" [X.501].
Для записей DIT, построенных на конкретном структурном объектном классе, правило содержимого DIT указывает, каким вспомогательным объектным классам разрешено принадлежать этим записям, а также каким дополнительным атрибутам (по типу) требуется, разрешено или не разрешено появляться в записях.
Список исключённых атрибутов не может содержать каких-либо атрибутов, указанных в качестве обязательных в этом правиле, структурном объектном классе или в любом из разрешённых вспомогательных объектных классов.
Каждое правило содержимого идентифицируется идентификатором объекта, а также любым количеством коротких имён (дескрипторов) структурного объектного класса, к которому оно применяется.
Запись может принадлежать только тем вспомогательным объектным классам, которые перечислены в регулирующем правиле содержимого.
Запись должна содержать все атрибуты, требуемые объектными классами, к которым она принадлежит, а также все атрибуты, требуемые регулирующим правилом содержимого.
Запись может содержать любые неисключённые атрибуты, разрешённые объектными классами, к которым она принадлежит, а также все атрибуты, разрешённые регулирующим правилом содержимого.
Запись не может включать любые атрибуты, исключённые регулирующим правилом содержимого.
Запись регулируется правилом содержимого DIT (если оно присутствует и активно в подсхеме), применяющимся к структурному объектному классу этой записи (смотрите раздел 2.4.2). Если для структурного объектного класса записи не присутствует активного правила, содержание этой записи регулируется структурным объектным классом (и, возможно, другими аспектами пользовательской и системной схемы данных). Правила содержимого DIT для суперклассов структурного объектного класса записи не применяются к этой записи.
Описания правил содержимого DIT формулируются в соответствии со следующей ABNF:
DITContentRuleDescription = LPAREN WSP
numericoid ; идентификатор объекта
[ SP "NAME" SP qdescrs ] ; короткие имена (дескрипторы)
[ SP "DESC" SP qdstring ] ; описание
[ SP "OBSOLETE" ] ; неактивен
[ SP "AUX" SP oids ] ; вспомогательные объектные классы
[ SP "MUST" SP oids ] ; типы атрибутов
[ SP "MAY" SP oids ] ; типы атрибутов
[ SP "NOT" SP oids ] ; типы атрибутов
extensions WSP RPAREN ; расширения
здесь:
Иногда может возникнуть потребность регулировать местоположение записей объектов и псевдонимов в DIT, а также то, как они могут быть названы, основываясь на их структурном объектном классе.
Правило структуры DIT — это "правило, регулирующее структуру DIT путём указания взаимоотношений, разрешающих нижестоящей записи принадлежать определённой вышестоящей записи. Правило структуры по форме имени и, следовательно, по структурному объектному классу, соотносится с вышестоящими правилами структуры. Это позволяет записям, принадлежащим к структурному объектному классу, идентифицируемому по форме имени, существовать в DIT в качестве нижестоящих по отношению к записям, регулируемым указанными вышестоящими правилами структуры" [X.501].
Описания правил структуры DIT формулируются в соответствии со следующей ABNF:
DITStructureRuleDescription = LPAREN WSP
ruleid ; идентификатор правила
[ SP "NAME" SP qdescrs ] ; короткие имена (дескрипторы)
[ SP "DESC" SP qdstring ] ; описание
[ SP "OBSOLETE" ] ; неактивен
SP "FORM" SP oid ; форма имени
[ SP "SUP" ruleids ] ; вышестоящие правила
extensions WSP RPAREN ; расширения
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number
здесь:
Если идентификаторов вышестоящих правил не представлено, правило структуры DIT применяется к автономной административной точке (например, к корневой вершине поддерева, управляемого данной подсхемой) [X.501].
Форма имени "определяет допустимую RDN для записей конкретного структурного объектного класса. Форма имени идентифицирует объектный класс, на который будет распространяться правило именования, и один или несколько типов атрибутов, которые будут использоваться для именования (то есть, для RDN). Формы имени являются примитивами спецификации, применяемыми в определении правил структуры DIT" [X.501].
Каждая форма имени указывает структурный объектный класс, на который будет распространяться правило именования, набор требуемых типов атрибутов и набор разрешённых типов атрибутов. Один и тот же тип атрибута не может присутствовать в обоих наборах.
Записи, управляемые определённой формой имени, должны именоваться с использованием значений каждого требуемого типа атрибута и нуля или более значений разрешённых типов атрибутов.
Каждая форма имени идентифицируется идентификатором объекта (OID) и, опционально, одним или несколькими короткими именами (дескрипторами).
Описания форм имени формулируются в соответствии со следующей ABNF:
NameFormDescription = LPAREN WSP
numericoid ; идентификатор объекта
[ SP "NAME" SP qdescrs ] ; короткие имена (дескрипторы)
[ SP "DESC" SP qdstring ] ; описание
[ SP "OBSOLETE" ] ; неактивен
SP "OC" SP oid ; структурный объектный класс
SP "MUST" SP oids ; типы атрибутов
[ SP "MAY" SP oids ] ; типы атрибутов
extensions WSP RPAREN ; расширения
здесь:
Все типы атрибутов в списках требуемых ("MUST") и разрешённых ("MAY") атрибутов именования должны быть различными.
(Под)записи подсхемы используются для управления информацией о схеме данных каталога. Одна (под)запись подсхемы содержит все определения схемы данных (смотрите раздел 4.1), используемые записями в конкретной части дерева каталога.
Серверам, придерживающимся моделей X.500(93), следует (SHOULD) реализовывать подсхемы с помощью механизмов подсхемы X.500 (как описано в разделе 12 стандарта [X.501]), то есть не обычными записями объектов, а подзаписями (смотрите раздел 3.2). LDAP-клиентам не следует (SHOULD NOT) предполагать, что серверы реализуют какие-либо другие аспекты подсхемы X.500.
Серверы могут (MAY) разрешать модификацию подсхемы. Процедуры модификации подсхемы обсуждаются в разделе 14.5 стандарта [X.501].
Серверу, управляющему записями и позволяющему клиентам изменять эти записи, нужно (SHALL) реализовывать и предоставлять доступ к (под)записям подсхемы, в том числе предоставлять атрибут 'subschemaSubentry' в каждой записи, которую можно изменить. Так, клиенту предоставляется возможность узнать, какие атрибуты и объектные классы разрешены к использованию. Настоятельно рекомендуется (RECOMMENDED), чтобы и другие типы серверов реализовывали эти возможности.
Значение атрибута 'subschemaSubentry' — имя (под)записи подсхемы, содержащей подсхему, управляющую данной записью.
( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
Правило соответствия 'distinguishedNameMatch' и синтаксис DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) определены в [RFC4517].
Подсхема содержится в (под)записях, принадлежащих вспомогательному объектному классу subschema.
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
В записях подсхемы может также присутствовать операционый атрибут 'ldapSyntaxes'.
Серверы могут (MAY) предоставлять в (под)записях подсхемы дополнительные атрибуты (описанные в других документах).
Серверам следует (SHOULD) предоставлять атрибуты 'createTimestamp' и 'modifyTimestamp' в (под)записях подсхемы, чтобы дать возможность клиентам вести свои кэши информации схемы данных.
В последующих подразделах даны определения типов атрибутов, используемых для определения схемы данных в подзаписи подсхемы.
Данный атрибут содержит определения объектных классов.
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )
Правило соответствия 'objectIdentifierFirstComponentMatch' и синтаксис ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) определены в [RFC4517].
Данный атрибут содержит определения типов атрибутов.
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )
Правило соответствия 'objectIdentifierFirstComponentMatch' и синтаксис AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) определены в [RFC4517].
Данный атрибут содержит определения правил соответствия.
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation )
Правило соответствия 'objectIdentifierFirstComponentMatch' и синтаксис MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) определены в [RFC4517].
Данный атрибут содержит определения применений правил соответствия.
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )
Правило соответствия 'objectIdentifierFirstComponentMatch' и синтаксис MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) определены в [RFC4517].
Данный атрибут содержит определения синтаксисов LDAP.
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation )
Правило соответствия 'objectIdentifierFirstComponentMatch' и синтаксис SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) определены в [RFC4517].
В данном атрибуте перечислены присутствующие в подсхеме правила содержимого DIT.
( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )
Правило соответствия 'objectIdentifierFirstComponentMatch' и синтаксис DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) определены в [RFC4517].
В данном атрибуте перечислены присутствующие в подсхеме правила структуры DIT.
( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation )
Правило соответствия 'integerFirstComponentMatch' и синтаксис DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) определены в [RFC4517].
В данном атрибуте перечислены действующие формы имени.
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )
Правило соответствия 'objectIdentifierFirstComponentMatch' и синтаксис NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) определены в [RFC4517].
Вспомогательный объектный класс 'extensibleObject' позволяет принадлежащим к нему записям содержать любой пользовательский атрибут. Набор разрешённых типов атрибутов этого объектного класса представляет собой неявную совокупность всех типов атрибутов с областью применения userApplications.
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
Требование о наличии обязательных атрибутов других объектных классов записи остаётся в силе, так же как и запрет на присутствие исключенных атрибутов.
Чтобы определить DN (под)записи подсхемы, содержащей подсхему, управляющую конкретной записью, клиент считывает операционный атрибут 'subschemaSubentry' этой записи. Для чтения атрибутов схемы данных из (под)записи подсхемы клиент должен (MUST) выполнить операцию поиска Search [RFC4511], где baseObject — DN (под)записи подсхемы, диапазон поиска — baseObject, фильтр — "(objectClass=subschema)" [RFC4515], а в поле атрибутов перечислены имена требуемых атрибутов схемы данных (поскольку они являются операционными). Примечание: фильтр "(objectClass=subschema)" позволяет серверам LDAP, выполняющим роль шлюза к X.500, определить, что запрашивается информация о подзаписи.
Клиентам не следует (SHOULD NOT) предполагать, что опубликованная подсхема является полной, что сервер поддерживает все опубликованные им элементы схемы данных или что он не поддерживает неопубликованные.
Протокол LDAP подразумевает, что есть один или несколько серверов, совместно предоставляющих доступ к информационному дереву каталога (DIT). Сервер, на котором содержится исходная информация, называется "главным" ("master") (по отношению к этой информации). Серверы, на которых содержатся копии исходной информации, называются "теневыми" ("shadowing") или "кэширующими" ("caching") серверами.
Как определено в стандарте [X.501]:
Префикс контекста (context prefix): Последовательность RDN, ведущая от корня DIT до первоначальной вершины контекста именования; соответствует уникальному имени этой вершины.
Контекст именования (naming context): Поддерево записей, содержащееся в одном главном DSA.
То есть, контекст именования — это наибольшая совокупность записей, начинающаяся с записи, управляемой конкретным главным сервером, и включающая все нижестоящие по отношению к ней записи, а также нижестоящие по отношению к ним и так далее, вплоть до записей, управляемых различными главными серверами. Префикс контекста — это имя первоначальной записи.
Корнем DIT является специфичная для DSA запись (DSA-specific Entry, DSE). Она не входит в какой-либо контекст именования (или какое-либо поддерево). У каждого сервера значения атрибутов в корневой DSE различны.
LDAP-серверу следует (SHALL) предоставлять информацию о самом себе и другую информацию, специфичную для каждого сервера. Она представлена в виде группы атрибутов, расположенных в корневой DSE, имя которой — DN, состоящее из нуля RDN (строковое представление которой согласно [RFC4514] — строка нулевой длины).
Эти атрибуты можно затребовать, на них накладываются условия контроля доступа и другие ограничения. Для их запроса клиент выполняет операцию поиска Search [RFC4511] с пустым baseObject, диапазоном поиска — baseObject, фильтром — "(objectClass=*)" [RFC4515], а в поле атрибутов перечислены имена описанных атрибутов. Имейте ввиду, что атрибуты корневой DSE являются операционными и, как и другие операционные атрибуты, не возвращаются в ответ на поисковый запрос, если не были запрошены явно по имени.
Корневая DSE не должна (SHALL NOT) быть включена в возвращаемые клиенту данные, если тот выполняет поиск по поддереву, начиная от корня.
Серверы могут разрешить клиентам модифицировать атрибуты корневой DSE, если это уместно.
Ниже определены следующие атрибуты корневой DSE (дополнительные атрибуты могут быть определены в других документах):
Значения этих атрибутов могут зависеть от конкретной сессии и других факторов. Например, сервер, поддерживающий механизм SASL EXTERNAL, может указать только "EXTERNAL" в списке поддерживаемых механизмов, если клиент прошёл проверку подлинности на более низком уровне. Смотрите [RFC4513].
Корневая DSE может также включать атрибут 'subschemaSubentry', в этом случае он указывает на (под)запись подсхемы, содержащей схему данных, управляющую корневой DSE. Клиентам не следует (SHOULD NOT) предполагать, что данная (под)запись подсхемы управляет другими записями на этом сервере. Общие процедуры изучения подсхемы даны в разделе 4.4.
В атрибуте 'altServer' перечисляются URI, указывающие на альтернативные серверы, с которыми можно связаться в случае, если этот сервер станет недоступен. URI для серверов, реализующих LDAP, составляются в соответствии с [RFC4516]. Могут предоставляться другие типы URI. Если серверу неизвестно о каких-либо других серверах, которые могут быть использованы, данный атрибут опускается. Клиенты могут кэшировать эту информацию на случай, если предпочитаемый ими сервер позже станет недоступен.
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation )
Синтаксис IA5String (1.3.6.1.4.1.1466.115.121.1.26) определён в [RFC4517].
В атрибуте 'namingContexts' перечисляются префиксы контекстов именования, для которых этот сервер является главным или теневым (для части или всего контекста именования). Если сервер представляет собой DSA первого уровня [X.501], он должен (дополнительно) указать в этом атрибуте пустую строку (обозначающую корень DIT). Если сервер не является главным или теневым для какой-либо информации (например, он представляет собой шлюз LDAP к публичному каталогу X.500), данный атрибут опускается. Если сервер считает, что является главным или теневым для всего каталога, то в этом атрибуте будет единственное значение — пустая строка (обозначающая корень DIT).
Этот атрибут может быть использован, к примеру, для выбора подходящего имени записи в последующих операциях с этим сервером.
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )
Синтаксис DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) определён в [RFC4517].
В атрибуте 'supportedControl' перечисляются идентификаторы объектов, идентифицирующие поддерживаемые сервером элементы управления запроса [RFC4511]. Если сервер не поддерживает никаких элементов управления запроса, данный атрибут опускается. Идентификаторы объектов, идентифицирующие элементы управления ответа, перечислять не нужно.
Процедуры запроса идентификаторов объектов, используемых для идентификации механизмов протокола, описаны в BCP 64, RFC4520.
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
Синтаксис OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) определён в [RFC4517].
В атрибуте 'supportedExtension' перечисляются идентификаторы объектов, идентифицирующие поддерживаемые сервером расширенные операции [RFC4511]. Если сервер не поддерживает никаких расширенных операций, данный атрибут опускается.
В общем случае расширенная операция состоит из расширенного запроса и расширенного ответа, но также может включать и другие элементы протокола (такие как промежуточные ответы). Для идентификации расширенной операции используется идентификатор объекта, ассоциированный с расширенным запросом. Другие используемые в расширенной операции идентификаторы объектов в значениях этого атрибута перечислять не нужно.
Процедуры запроса идентификаторов объектов, используемых для идентификации механизмов протокола, описаны в BCP 64, RFC4520.
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
Синтаксис OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) определён в [RFC4517].
В атрибуте 'supportedFeatures' перечисляются идентификаторы объектов, идентифицирующие поддерживаемые сервером факультативные возможности. Если сервер не поддерживает никаких распознаваемых факультативных возможностей, данный атрибут опускается.
( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
Процедуры запроса идентификаторов объектов, используемых для идентификации механизмов протокола, описаны в BCP 64, RFC4520.
Синтаксис OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) и правило соответствия objectIdentifierMatch определены в [RFC4517].
В атрибуте 'supportedLDAPVersion' перечисляются поддерживаемые сервером версии LDAP.
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation )
Синтаксис INTEGER (1.3.6.1.4.1.1466.115.121.1.27) определён в [RFC4517].
В атрибуте 'supportedSASLMechanisms' перечисляются распознаваемые и/или поддерживаемые сервером механизмы SASL [RFC4422] [RFC4513]. Содержимое этого атрибута может зависеть от состояния текущей сессии. Если сервер не поддерживает никаких механизмов SASL, данный атрибут опускается.
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )
Синтаксис Directory String (1.3.6.1.4.1.1466.115.121.1.15) определён в [RFC4517].
Могут быть определены синтаксисы, у которых задано требование сохранности в неизменном виде специфического значения и/или формы (представления) значения. Например, синтаксис хранения данных цифровой подписи может выдвигать требования сохранности сервером в неизменном виде как значения, так и формы представления значения, чтобы гарантировать, что подпись не станет недействительной.
В случаях, когда такое требование не задано явно, серверу следует (SHOULD) поддерживать сохранность значения пользовательской информации, но он может (MAY) возвращать значение в форме, отличной от оригинала. А в случаях, когда сервер не может (или не желает) поддерживать сохранность значения пользовательской информации, ему следует (SHALL) обеспечить возврат эквивалентного значения (согласно разделу 2.3).
Короткие имена, известные также как дескрипторы, используются в качестве более читабельных псевдонимов для идентификаторов объектов. Применяются для идентификации различных элементов схемы данных. Однако, не ожидается, что реализации LDAP с интерфейсом, рассчитанным на вывод информации человеку, будут отображать пользователю такие короткие имена (или идентификаторы объектов, на которые они ссылаются). Вместо этого, таким реализациям предпочтительнее выполнять трансляции (например, представлять эти короткие имена на одном из национальных языков). Например, короткое имя "st" (stateOrProvinceName) пользователю, говорящему на немецком, может выводиться как "Land".
Одно и то же короткое имя может иметь разные значения в разных подсхемах. Кроме того, в рамках одной конкретной подсхемы одно и то же короткое имя может указывать на различные идентификаторы объектов, каждый из которых идентифицирует разные типы элементов схемы данных.
Реализации должны (MUST) быть готовы к тому, что одно и то же короткое имя может быть использовано в подсхеме для указания на разные типы элементов схемы данных. То есть, в одной подсхеме может быть объектный класс 'x-fubar' и тип атрибута 'x-fubar'.
Реализации должны (MUST) быть готовы к тому, что одно и то же короткое имя может быть использовано в разных подсхемах для указания на разные элементы схемы данных. То есть, в разных подсхемах могут быть два разных правила соответствия 'x-fubar'.
Процедуры регистрации коротких имён (дескрипторов) описаны в BCP 64, RFC4520.
Некоторые серверы могут хранить кэшированные или теневые копии записей. Такие серверы могут быть использованы для ответов на запросы поиска и сравнения, но при получении запросов операций модификации они будут возвращать отсылки или устанавливать соединения с другими серверами. Серверы, выполняющие роль теневых копий или кэшей, должны (MUST) гарантировать, что они не нарушают никаких ограничений контроля доступа, накладываемых на информацию исходным сервером.
Серверы должны (MUST) распознавать все имена типов атрибутов и объектных классов, определённых в этом документе, но, если не указано иное, от них не требуется поддерживать соответствующую функциональность. Серверам следует (SHOULD) распознавать все имена типов атрибутов и объектных классов, определённых в, соответственно, в разделах 3 и 4 [RFC4519].
Серверы должны (MUST) обеспечить удовлетворение записями правил пользовательской и системной схем данных или других ограничений модели данных. Серверы могут (MAY) поддерживать правила содержимого DIT. Серверы могут (MAY) поддерживать правила структуры DIT и формы имён.
Серверы могут (MAY) поддерживать записи-псевдонимы.
Серверы могут (MAY) поддерживать объектный класс 'extensibleObject'.
Серверы могут (MAY) поддерживать подзаписи. Если это так, они должны (MUST) делать это в соответствии с [RFC3672]. Серверам, не поддерживающим подзаписи, следует (SHOULD) использовать записи-объекты для имитации подзаписей, как описано в разделе 3.2.
Серверы могут (MAY) реализовывать дополнительные элементы схемы данных. Серверам следует (SHOULD) предоставлять определения всех поддерживаемых ими элементов схемы данных в подзаписях (записях) подсхемы.
При отсутсвии предварительных договорённостей с серверами, клиентам не следует (SHOULD NOT) предполагать, что серверы поддерживают какие-либо конкретные элементы схемы данных помимо тех, которые упоминаются в разделе 7.1. Клиенты могут получить информацию подсхемы с помощью последовательности действий, описанных в разделе 4.4.
Клиенты не должны (MUST NOT) отображать или пытаться декодировать значение как конструкцию ASN.1, если синтаксис этого значения неизвестен. Клиенты не должны (MUST NOT) предполагать, что специфичная для LDAP кодировка строк ограничивается закодированными UTF-8 строками символов Unicode или какого-то конкретного подмножества Unicode (например, подмножества печатных символов), если подобное ограничение не установлено явно. Клиентам не следует (SHOULD NOT) посылать в запросе значения атрибута, которые не являются верными в соответствии с синтаксисом, определенным для этого атрибута.
Атрибуты записей каталога используются для предоставления описательной информации об объектах реального мира, которые они представляют. Такими объектами могут быть люди, организации или устройства. В большинстве стран имеются законы, касающиеся защиты конфиденциальности при публикации информации о людях.
Основные соображения безопасности при доступе к информации каталога посредством LDAP обсуждаются в [RFC4511] и [RFC4513].
Администрация адресного пространства Интернет (Internet Assigned Numbers Authority, IANA) обновила регистрацию дескрипторов LDAP как указано в следующей форме:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment
Specification: RFC 4512
Author/Change Controller: IESG
Comments:
The following descriptors (short names) has been added to
the registry.
NAME Type OID
------------------------ ---- -----------------
governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.9
The following descriptors (short names) have been updated to
refer to this RFC.
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0
Этот документ основан на RFC 2251, авторы M. Wahl, T. Howes и S. Kille; RFC 2252, авторы M. Wahl, A. Coulbeck, T. Howes, S. Kille; RFC 2556, авторы M. Wahl, все они разработаны рабочей группой IETF Access, Searching and Indexing of Directories (ASID). Он также основан на части стандарта "The Directory: Models" [X.501], разработанного International Telephone Union (ITU). Дополнительный текст был заимствован из RFC 2253, авторы M. Wahl, T. Howes и S. Kille.
Этот документ разработан рабочей группой IETF LDAP Revision (LDAPBIS).[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, ноябрь 2003 г.
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight Directory Access Protocol (LDAP)", RFC 3671, декабрь 2003 г.
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory Access Protocol (LDAP)", RFC 3672, декабрь 2003 г.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, октябрь 2005 г.
[RFC4422] Под редакцией Melnikov, A. и K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, июнь 2006 г.
[RFC4510] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, июнь 2006 г.
[RFC4511] Под редакцией Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): Определение протокола", RFC 4511, июнь 2006 г.
[RFC4513] Под редакцией Harrison, R., "Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms", RFC 4513, июнь 2006 г.
[RFC4514] Под редакцией Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, июнь 2006 г.
[RFC4515] Под редакцией Smith, M. и T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, июнь 2006 г.
[RFC4516] Под редакцией Smith, M. и T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, июнь 2006 г.
[RFC4517] Под редакцией Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, июнь 2006 г.
[RFC4519] Под редакцией Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, июнь 2006 г.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 4520, июнь 2006 г.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version 3.2.0", определён в "The Unicode Standard, Version 3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-5), с поправками, внесенными в "Unicode Standard Annex #27: Unicode 3.1" (http://www.unicode.org/reports/tr27/) и в "Unicode Standard Annex #28: Unicode 3.2" (http://www.unicode.org/reports/tr28/).
[X.500] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Overview of concepts, models and services", X.500(1993) (also ISO/IEC 9594-1:1994).
[X.501] International Telecommunication Union - Telecommunication Standardization Sector, "The Directory: Models", X.501(1993) (also ISO/IEC 9594-2:1994).
[X.680] International Telecommunication Union - Telecommunication Standardization Sector, "Abstract Syntax Notation One (ASN.1) - Specification of Basic Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
Это приложение не является нормативным.
Этот документ состоит из практически неизменённых частей RFC 2251, RFC 2252 и RFC 2256. Такая компоновка была предпринята для повышения общей ясности технической спецификации. В этом приложении приводится обзор основных изменений, внесённых во включённые в этот документ части перечисленных документов. Обзор оставшихся частей перечисленных документов смотрите в [RFC4510], [RFC4511], [RFC4517] и [RFC4519].
В этот документ включены разделы 3.2 и 3.4, а также части разделов 4 и 6 RFC 2251, как описано ниже.
В разделе 3.2 RFC 2251 было представлено краткое введение в модель данных X.500 с точки зрения ее использования в LDAP. Предыдущая спецификация опиралась на [X.501], но не хватало ясности в том, как модели X.500 адаптированы для использования в LDAP. Этот документ описывает модели данных X.500, с точки зрения их использования в LDAP, более детально, особенно в тех областях, где требуется адаптация.
В разделе 3.2.1 RFC 2251 атрибут определялся как "тип с одним или несколькими ассоциированными значениями". В LDAP атрибут определён более точно как описание атрибута, то есть тип с одной или несколькими опциями и с одним или несколькими ассоциированными значениями.
В разделе 3.2.2 RFC 2251 выдвигалось требование, что подзаписи подсхемы должны содержать атрибуты objectClasses и attributeTypes, а в X.500(93) эти атрибуты определяются как необязательные. Хотя практически все реализации, поддерживающие механизмы подсхемы X.500(93), будут предоставлять оба эти атрибута, для обеспечения функциональной совместимости со стандартом X.500(93) требование о поддержке этих атрибутов всеми серверами не должно быть абсолютным. Итак, это требование было снято для соответствия со стандартом X.500(93). Кроме того, был уточнён механизм изучения подсхемы: управляющая записью подсхема может быть получена путём чтения (под)записи, на которую указывает значение атрибута 'subschemaSubentry' исходной записи.
В разделе 3.4 RFC 2251 были даны "Требования к специфичной для сервера информации". Этот материал, с изменениями, был включён в раздел 5.1 этого документа.
Изменения:
Части раздела 4 RFC 2251, касающиеся аспектов используемой в LDAP информационной модели, включены в этот документ, в том числе:
Уточнения этих частей:
В этот документ включены раздел 6.1 и второй параграф раздела 6.2 RFC 2251.
В этот документ включены разделы 4, 5 и 7 RFC 2252.
Спецификация была обновлена: используется расширенная форма Бэкуса-Наура (Augmented BNF, ABNF) [RFC4234]. Строковое представление идентификатора объекта было ограничено: запрещены начальные нули, как описано в RFC 2252.
Синтаксис <descr> был изменён: запрещён символ точки с запятой (U+003B) для соответствия с описательной спецификацией "descr — это синтаксическое представление дескриптора объекта, состоящее из букв и цифр, начинающееся с буквы". Связанное с этим изменение: утверждение "AttributeDescription может быть использовано в качестве значения в части NAME конструкции AttributeTypeDescription" было удалено. В RFC 2252 не дана спецификация семантики опций атрибута, которые могут присутствовать в полях NAME.
В RFC 2252 утверждалось, что форма <descr> <oid> должна (SHOULD) быть предпочтительнее формы <numericoid>. Однако, форма <descr> может быть неоднозначной. Для решения этой проблемы это утверждение было заменено (в разделе 1.4): хотя форма <descr> в общем случае предпочтительнее, в тех случаях, когда <descr> не обеспечивает однозначность, следует использовать <numericoid>. В дополнение к этому, в разделе 6.2 ("Короткие имена") предоставлено расширенное обсуждение вопросов дескрипторов.
Была обновлена ABNF для экранированной строки (qdstring): отражена поддержка механизма экранирования, описанного в разделе 4.3 RFC 2252.
В этот документ включены определения операционных атрибутов, данные в разделе 5 RFC 2252.
Уточнено описание 'namingContexts'. DSA первого уровня должны публиковать "" (пустую строку) в дополнение к другим значениям, отражая тем самым корень DIT.
Уточнено описание 'altServer'. В этом атрибуте могут содержаться любые URI.
Уточнено описание 'supportedExtension'. Серверу необходимо перечислять только идентификаторы объектов расширенных запросов тех расширенных операций, которые он распознаёт.
Уточнено описание 'supportedControl'. Серверу необходимо перечислять только идентификаторы объектов элементов управления запроса, которые он распознаёт. Добавлены описания типов операционных атрибутов 'structuralObjectClass' и 'governingStructureRule'.
Откорректировано определение атрибута 'subschemaSubentry': поля SINGLE-VALUE и NO-USER-MODIFICATION перечислены в правильном порядке.
В разделе 7 RFC 2252 были даны определения объектных классов 'subschema' и 'extensibleObject'. Эти определения были интегрированы в разделы 4.2 и 4.3 этого документа, соответственно. Также в разделе 7 RFC 2252 содержались требования к реализации объектных классов. Они включены в раздел 7 этого документа.
Уточнена спецификация 'extensibleObject' в том, как этот объектный класс взаимодействует с исключёнными атрибутами.
В этот документ включены разделы 5.1, 5.2, 7.1 и 7.2 RFC 2256.
В разделе 5.1 RFC 2256 было дано определение типа атрибута 'objectClass'. Оно было интегрировано в раздел 2.4.1 этого документа. Утверждение "одно из значений — это либо 'top', либо 'alias'" заменено на утверждение, что одно из значений — это 'top', поскольку запись, принадлежащая к классу 'alias', также принадлежит к классу 'top'.
В разделе 5.2 RFC 2256 было дано определение типа атрибута 'aliasedObjectName'. Оно было интегрировано в раздел 2.6.2 этого документа.
В разделе 7.1 RFC 2256 было дано определение объектного класса 'top'. Оно было интегрировано в раздел 2.4.1 этого документа.
В разделе 7.2 RFC 2256 было дано определение объектного класса 'alias'. Оно было интегрировано в раздел 2.6.1 этого документа.
В этот документ без существенных изменений включена техническая спецификация 'supportedFeatures', данная в RFC 3674.
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Copyright (C) Internet Society (2006).
На этот документ распространяются права, лицензии и ограничения, содержащиеся в BCP 78, и, за исключением случаев, изложенных в нем, авторы сохраняют все свои права.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и АВТОР ДОКУМЕНТА, ОРГАНИЗАЦИЯ, КОТОРУЮ ОН/ОНА ПРЕДСТАВЛЯЕТ, ИЛИ КОТОРОЙ ОН/ОНА СПОНСИРУЕТСЯ (ЕСЛИ ТАКОВЫЕ ИМЕЮТСЯ), INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
IETF не занимает никакой позиции относительно действительности или области действия каких-либо прав на интеллектуальную собственность, или других прав, которые могут заявляться как относящиеся к реализации или использованию технологий, описанных в данном документе, либо в подтверждении которых могут или не могут быть доступны какие-либо лицензии; кроме того, IETF не заявляет о том, что она будет предпринимать какие-либо независимые усилия по выявлению подобных прав. Информацию по процедурам в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии поданных в секретариат IETF заявлений о правах на интеллектуальную собственность (Intellectual Property Rights, IPR), а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации из он-лайн репозитория IPR IETF по адресу http://www.ietf.org/ipr.
IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию в IETF по адресу ietf-ipr@ietf.org.
Финансирование функций RFC Editor обеспечивается IETF Administrative Support Activity (IASA).