Network Working Group Request for Comments: 3671 Категория: Standards Track K. Zeilenga (OpenLDAP Foundation) Декабрь 2003 года
Этот документ определяет стандарт протокола Интернет для сообщества Интернет, а также приглашает к обсуждению и подаче предложений по его усовершенствованию. Пожалуйста, сверяйтесь с текущей редакцией "Официальных стандартов протоколов Интернет" (STD 1), чтобы узнать состояние стандартизации и статус этого протокола. Ограничений на распространение данного документа не накладывается.
Copyright (C) The Internet Society (2003). Все права защищены.
Коллективные атрибуты X.500 позволяют совместно использовать общие характеристики в коллекциях записей. В этом документе обобщается информационная модель X.500 для коллективных атрибутов и описывается использование коллективных атрибутов в LDAP (Lightweight Directory Access Protocol). Также в этом документе приводится определение схемы данных для использования коллективных атрибутов в LDAP.
В X.500 [X.500] коллективный атрибут — это "пользовательский атрибут, значения которого одинаковы для каждого элемента коллекции записей" [X.501]. В этом документе подробно описывается использование таких атрибутов в протоколе Lightweight Directory Access Protocol (LDAP) [RFC3377].
Коллекция записей представляет собой общность записей-объектов и записей-псевдонимов, сгруппированную на основании общих свойств или общей взаимосвязи между этими записями, разделяющими некоторые атрибуты. Коллекция записей состоит из всех записей в области действия подзаписи коллективных атрибутов [RFC3672]. Запись может принадлежать к нескольким коллекциям записей.
Атрибуты, разделяемые записями, входящими в коллекцию записей, называются коллективными атрибутами. Значения коллективных атрибутов доступны для просмотра, но не доступны для обновления клиентам, обращающимся к записям в коллекции. Коллективные атрибуты обновляются (то есть модифицируются) через связанную с коллекцией подзапись коллективных атрибутов.
Когда запись принадлежит нескольким коллекциям записей, значения каждого коллективного атрибута в этой записи объединяются таким образом, что независимые источники этих значений не отображаются клиентам.
Конкретный коллективный атрибут может быть исключён из записей путём указания имени этого атрибута в качестве значения атрибута collectiveExclusions. Как и любые другие пользовательские атрибуты, коллективные атрибуты подчиняются различным видам контроля, в том числе контролю доступа, административным ограничениям и ограничениям контента.
Определения схемы данных предоставляются с использованием формата описания объектных классов и типов атрибутов [RFC2252] стандарта LDAPv3 [RFC2251]. Представленные в этом документе определения отформатированы (разбиты на несколько строк) для повышения читабельности.
Ключевые слова "MUST" (необходимо), "MUST NOT" (недопустимо), "REQUIRED" (требуется), "SHALL" (нужно), "SHALL NOT" (не нужно), "SHOULD" (следует), "SHOULD NOT" (не следует), "RECOMMENDED" (рекомендуется), "MAY" (возможно) и "OPTIONAL" (необязательно) в данном документе должны интерпретироваться так, как описано в BCP 14 [RFC2119].
Описанные ниже операционные атрибуты используются для управления коллективными атрибутами. При предоставлении таких сервисов серверам LDAP [RFC3377] необходимо (MUST) действовать в соответствии с моделью каталога X.500 [X.501].
Подзаписи с этим объектным классом используются для администрирования коллективных атрибутов и называются подзаписями коллективных атрибутов.
( 2.5.17.2 NAME 'collectiveAttributeSubentry' AUXILIARY )
В подзаписи коллективных атрибутов должен (SHOULD) содержаться как минимум один коллективный атрибут. Коллективные атрибуты, содержащиеся в подзаписи коллективных атрибутов, доступны для обнаружения, поиска и сравнения в каждой записи в области действия этой подзаписи. Однако администрирование (например, модификация) коллективных атрибутов выполняется через данную подзапись.
Реализации данной спецификации должны (SHOULD) поддерживать подзаписи коллективных атрибутов как в административной области collectiveAttributeSpecificArea (2.5.23.5), так и в административной области collectiveAttributeInnerArea (2.5.23.6) [RFC3672][X.501].
Операционный атрибут collectiveAttributeSubentries идентифицирует все подзаписи коллективных атрибутов, влияющие на данную запись.
( 2.5.18.12 NAME 'collectiveAttributeSubentries'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE directoryOperation NO-USER-MODIFICATION )
Операционный атрибут collectiveExclusions позволяет исключать из записи конкретные коллективные атрибуты. Он может (MAY) присутствовать в любой записи и может (MAY) иметь несколько значений.
( 2.5.18.7 NAME 'collectiveExclusions'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE directoryOperation )
Дескриптор excludeAllCollectiveAttributes ассоциирован с OID 2.5.18.0. Если этот дескриптор или OID присутствует в качестве значения атрибута collectiveExclusions, из записи исключаются все коллективные атрибуты.
Пользовательский (userApplications) тип атрибута может быть определен как коллективный с использованием ключевого слова COLLECTIVE [RFC2252]. Это указывает на то, что одни и те же значения атрибута будут присутствовать в записях, составляющих коллекцию записей, с учётом использования атрибута collectiveExclusions и других административных ограничений. Эти административные ограничения могут (MAY) включать правила содержимого DIT, если они реализованы.
Обычно типы коллективных атрибутов определяются как подтипы типов неколлективных атрибутов. По соглашению, коллективные атрибуты именуются тем же именем, что и их неколлективные надтипы, с добавлением префикса "c-". Например, коллективный атрибут с номером телефона называется c-TelephoneNumber по имени своего неколлективного надтипа telephoneNumber.
Неколлективным типам атрибутов не следует (SHALL NOT) быть подтипами коллективных атрибутов.
Коллективным атрибутам не следует (SHALL NOT) быть однозначными (SINGLE-VALUED). Коллективным типам атрибутов не следует (SHALL NOT) присутствовать в списке типов атрибутов в определении какого-либо объектного класса.
Не следует (SHALL NOT) определять операционные атрибуты как коллективные.
Далее в этом разделе приводится краткое изложение коллективных атрибутов, полученных на основании аналогичных атрибутов, определённых в стандарте [X.520]. Используемые в LDAP вышестоящие (SUP) типы атрибутов описаны в [RFC 2256].
Реализациям данной спецификации следует (SHOULD) поддерживать приведённые ниже коллективные атрибуты, также они могут (MAY) поддерживать дополнительные коллективные атрибуты.
Тип атрибута c-l определяет наименование местности для коллекции записей.
( 2.5.4.7.1 NAME 'c-l'
SUP l COLLECTIVE )
Тип атрибута c-st определяет наименование штата или провинции для коллекции записей.
( 2.5.4.8.1 NAME 'c-st'
SUP st COLLECTIVE )
Тип атрибута c-street определяет наименование улицы для коллекции записей.
( 2.5.4.9.1 NAME 'c-street'
SUP street COLLECTIVE )
Тип атрибута c-o определяет наименование организации для коллекции записей.
( 2.5.4.10.1 NAME 'c-o'
SUP o COLLECTIVE )
Тип атрибута c-ou определяет наименование подразделения организации для коллекции записей.
( 2.5.4.11.1 NAME 'c-ou'
SUP ou COLLECTIVE )
The c-PostalAddress определяет почтовый адрес для коллекции записей.
( 2.5.4.16.1 NAME 'c-PostalAddress'
SUP postalAddress COLLECTIVE )
Тип атрибута c-PostalCode определяет почтовый индекс для коллекции записей.
( 2.5.4.17.1 NAME 'c-PostalCode'
SUP postalCode COLLECTIVE )
Тип атрибута c-PostOfficeBox определяет идентификатор почтового ящика для коллекции записей.
( 2.5.4.18.1 NAME 'c-PostOfficeBox'
SUP postOfficeBox COLLECTIVE )
Тип атрибута c-PhysicalDeliveryOfficeName определяет наименование почтового отделения для коллекции записей.
( 2.5.4.19.1 NAME 'c-PhysicalDeliveryOfficeName'
SUP physicalDeliveryOfficeName COLLECTIVE )
Тип атрибута c-TelephoneNumber определяет номер телефона для коллекции записей.
( 2.5.4.20.1 NAME 'c-TelephoneNumber'
SUP telephoneNumber COLLECTIVE )
Тип атрибута c-TelexNumber определяет номер телекса для коллекции записей.
( 2.5.4.21.1 NAME 'c-TelexNumber'
SUP telexNumber COLLECTIVE )
Тип атрибута c-FacsimileTelephoneNumber определяет телефонный номер для факсимильной связи для коллекции записей.
( 2.5.4.23.1 NAME 'c-FacsimileTelephoneNumber'
SUP facsimileTelephoneNumber COLLECTIVE )
Тип атрибута c-InternationalISDNNumber определяет интернациональный номер ISDN для коллекции записей.
( 2.5.4.25.1 NAME 'c-InternationalISDNNumber'
SUP internationalISDNNumber COLLECTIVE )
Как и другие атрибуты, коллективные атрибуты подлежат ограничениям контроля доступа и другим административным политикам. В общем случае, при обращении к коллективным атрибутам через запись, входящую в коллекцию записей, к ним применяются правила, ограничивающие доступ к атрибутам этой записи. А при обращении к коллективным атрибутам через подзапись к ним применяются правила, ограничивающие доступ к атрибутам этой подзаписи. Однако, поскольку в LDAP нет стандартной модели доступа, характеристики системы контроля доступа каждого сервера могут отличаться.
Также к коллективным атрибутам применяются общие соображения безопасности LDAP [RFC3377].
IANA произвела регистрацию описанных в данной технической спецификации дескрипторов LDAP [RFC3383]. Был предложен следующий шаблон регистрации:
Subject: Request for LDAP Descriptor Registration
Descriptor see comments
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment
Specification: RFC3671
Author/Change Controller: IESG
Comments:
NAME Type OID
------------------------ ---- -----------------
c-FacsimileTelephoneNumber A 2.5.4.23.1
c-InternationalISDNNumber A 2.5.4.25.1
c-PhysicalDeliveryOffice A 2.5.4.19.1
c-PostOfficeBox A 2.5.4.18.1
c-PostalAddress A 2.5.4.16.1
c-PostalCode A 2.5.4.17.1
c-TelephoneNumber A 2.5.4.20.1
c-TelexNumber A 2.5.4.21.1
c-l A 2.5.4.7.1
c-o A 2.5.4.10.1
c-ou A 2.5.4.11.1
c-st A 2.5.4.8.1
c-street A 2.5.4.9.1
collectiveAttributeSubentries A 2.5.18.12
collectiveAttributeSubentry O 2.5.17.2
collectiveExclusions A 2.5.18.7
where Type A is Attribute and Type O is ObjectClass.
Используемые в этом документе идентификаторы объектов были назначены для идентификации элементов схемы данных X.500 [X.520] Объединённым техническим комитетом 1, подкомитетом 6 ISO/IEC. В этом документе назначений OID не производится, в нём приводятся только описания схемы данных LDAP для существующих элементов схемы данных X.500.
IETF не занимает никакой позиции относительно действительности или области действия каких-либо прав на интеллектуальную собственность или других прав, которые могут заявляться как относящиеся к реализации или использованию технологий, описанных в данном документе, либо в подтверждении которых могут или не могут быть доступны какие-либо лицензии; кроме того, IETF не заявляет о том, что она будет предпринимать какие-либо независимые усилия по выявлению подобных прав. Информацию по процедурам IETF в отношении прав в стандартах и относящихся к ним документах можно найти в BCP-11. Предоставленные для публикации копии заявлений о правах, а также какие-либо документы, подтверждающие лицензию и предназначенные для предоставления доступа к ним, либо результаты попыток получения генеральных лицензий или разрешений на пользование подобными правами собственности могут быть получены теми, кто занимается реализацией, или пользователями данной спецификации в секретариате IETF.
IETF просит всех заинтересованных лиц довести до её сведения любые авторские права, патенты или патентные заявки, либо другие права собственности, которые могут касаться технологий данного стандарта и могут потребоваться для его реализации. Пожалуйста, направляйте информацию исполнительному директору IETF.
Этот документ основан на рекомендациях ITU для каталогов [X.501][X.520].
[RFC2119] Bradner, S., "Ключевые слова для обозначения уровня требований в RFC", BCP 14, RFC 2119, март 1997 г.
[RFC2251] Wahl, M., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, декабрь 1997 г.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. и S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, декабрь 1997 г.
[RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, декабрь 1997 г.
[RFC3377] Hodges, J. и R. L. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, сентябрь 2002 г.
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, сентябрь 2002 г.
[RFC3672] Zeilenga, K. и S. Legg, "Подзаписи в Lightweight Directory Access Protocol (LDAP)", RFC 3672, декабрь 2003 г.
[X.501] "The Directory: Models", Рекомендация ITU-T X.501, 1993 г.
[X.500] "The Directory: Overview of Concepts, Models", Рекомендация ITU-T X.500, 1993 г.
[X.520] "The Directory: Selected Attribute Types", Рекомендация ITU-T X.520, 1993 г.
Kurt D. Zeilenga
OpenLDAP Foundation
EMail: Kurt@OpenLDAP.org
Copyright (C) Internet Society (2003). Все права защищены.
Этот документ и его переводы могут быть скопированы и переработаны в другие документы. Производные работы, комментирующие или иным способом поясняющие данный документ, либо оказывающие помощь в его реализации, могут быть подготовлены, скопированы, опубликованы и распространены, целиком или частями, без каких-либо ограничений, при условии, что указанное выше уведомление об авторском праве и этот параграф будут включены во все такие копии и производные работы. Однако, в этот документ как таковой не может быть внесено каких-либо изменений, таких как удаление уведомления об авторских правах или ссылок на Internet Society или другие организации Интернет, за исключением случаев, когда это требуется для разработки стандартов Интернет (при этом должны быть пройдены процедуры получения авторских прав, определённые в стандартах Интернет), либо когда это требуется при переводе на языки, отличные от английского.
Предоставляемые выше ограниченные права являются бессрочными и не подлежат отзыву Internet Society, его наследниками или правопреемниками.
Этот документ и содержащаяся в нём информация распространяются "КАК ЕСТЬ" и INTERNET SOCIETY И INTERNET ENGINEERING TASK FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБЫЕ ГАРАНТИИ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ ПРИВЕДЁННОЙ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШАЕТ КАКИХ-ЛИБО ПРАВ ИЛИ ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ПРИГОДНОСТИ ДЛЯ КОНКРЕТНЫХ ЦЕЛЕЙ.
Финансирование функций RFC Editor в настоящий момент обеспечивается Internet Society.