Стратегии каталогов

8.3.2 Классы объектов

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

Класс объекта является термином LDAP, который означает тип объекта, представленного элементом или записью каталога. Обычными типами объектов являются "человек, личность" (person), "организация" (organization), "подразделение организации" (organizational unit), "компонент домена" (domain component) и "группа имен" (groupOfNames). Существуют также классы объектов, которые определяют отношение объектов к другим объектам, такие? как класс "вершина" (top), который означает, что объект может иметь субординантные (подчиненные) объекты ниже себя в структуре иерархического дерева. Обратите внимание на то, что некоторые классы объектов LDAP могут быть комбинированными. К примеру, класс объекта organizational unit очень часто одновременно будет также определяться как класс объекта top, так как он будет иметь элементы, находящиеся в структуре ниже его.

Классы объектов LDAP определяют наборы стандартных атрибутов, которые регистрируются как обязательное содержимое MUST (обязательные атрибуты) и содержимое MAY (необязательные атрибуты). Различные классы объектов могут назначать некоторые атрибуты, которые перекрываются либо являются резервными по отношению к другим классам объектов. Общепринятой практикой в каталогах LDAP является использование множества классов объектов для определения единственного элемента каталога. Большинство классов объектов определяется в иерархическом порядке, когда говорят, что один класс объекта "наследует" другой, старший класс объекта.

Например, рассмотрим объект LDAP, который определяется следующими классами объектов:

objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: eDominoAccount

Порядок, показанный для классов объекта, отображает иерархические взаимоотношения между этими классами объекта, но не обязательно. Класс объекта top находится, конечно, на вершине иерархии. Большинство других классов объектов, которые не предназначены для подчинения другому классу, должны иметь класс top как верхний класс в иерархии. Не все каталоги LDAP предполагают, что запись пользователя имеет заданный ей класс объекта top, в то время как другие требуют его в целях применения списков управления доступом [Access Control Lists (ACL)] для объекта. Класс "person" является подчиненным для класса top и требует, чтобы были заполненными атрибуты общего имени cn (Common Name) и фамилии sn (Surname), а также разрешает применение некоторых других необязательных атрибутов. Класс organizationalPerson наследует класс person. Класс inetOrgPerson наследует класс organizationalPerson. А теперь хитрая комбинация: eDominoAccount является подчиненным для класса top и требует, чтобы были заполнены атрибуты sn и userid. Отметьте, что это перекрывается с требованием класса объекта person относительно атрибута sn. Означает ли это, что нам необходимо cохранить атрибут sn дважды? Нет, так как это стандартный атрибут. В этом разделе мы поговорим об атрибутах немного позже. Данный пример иллюстрирует, что вы не сможете точно указать иерархические отношения классов объектов по порядку их появления в списке.

Так как же их указывать? Мы указываем (или в реальности ваш интерфейс каталога LDAP показывает вам) это путем обзора самих определений классов объектов. Методы определения классов объектов для LDAP V3 описаны в RFC-2251 и RFC-2252. Следующие определения классов объектов были взяты с сервера каталогов IBM Directory Server, который использует тот же синтаксис, что и сервер OpenLDAP.

objectclass: top
objectclasses=( 2.5.6.0 NAME 'top' DESC 'Standard ObjectClass' ABSTRACT
MUST ( objectClass ) )
objectclass: person
objectclasses=( 2.5.6.6 NAME 'person' DESC 'Defines entries that
generically represent people.' SUP 'top' STRUCTURAL MUST ( cn $ sn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
objectclass: organizationalPerson
objectclasses=( 2.5.6.7 NAME 'organizationalPerson' DESC 'Defines entries
for people employed by or associated with an organization.' SUP 'person'
STRUCTURAL MAY ( title $ x121Address $ registeredAddress $
destinationIndicator $ preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ internationalISDNNumber $
facsimileTelephoneNumber $ street $ postalAddress $ postalCode $
postOfficeBox $ physicalDeliveryOfficeName $ ou $ st $ l ) )
objectclass: inetOrgPerson
objectclasses=( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' DESC 'Defines
entries representing people in an organizations enterprise network.' SUP
'organizationalPerson' STRUCTURAL MAY ( audio $ businessCategory $
carLicense $ departmentNumber $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $
manager $ mobile $ pager $ photo $ preferredLanguage $ roomNumber $
secretary $ uid $ userCertificate $ userSMIMECertificate $
x500UniqueIdentifier $ displayName $ o $ userPKCS12 ) )
objectclass: eDominoAccount
objectclasses=( 1.3.18.0.2.6.122 NAME 'eDominoAccount' DESC 'Represents a
Domino account.' SUP 'top' STRUCTURAL MUST ( sn $ userid ) MAY (
certificateExpirationDate $ certifierId $ certifierPassword $ clienttypereg
$ createAddressBookEntry $ createFullTextIndex $ createIdFile $
createMailDatabase $ createNorthAmericanId $ createNotesUser $ description
$ fullName $ givenName $ idFilePath $ idtype $ initialPassword $
initialPopulation $ internetAddress $ l $ localadmin $ location $ mail $
mailDomain $ mailFile $ mailFileOwnerAccess $ mailFileTemplate $
mailProgram $ mailServer $ mailSystem $ middleName $ minPasswordLength $ ou
$ overwriteaddressbook $ overwriteidfile $ principalPtr $ profiles $
proposedaltcommonname $ proposedAltFullNameLanguage $ proposedAltOrgUnit $
registrationServer $ saveIdInAddressBook $ saveIdInFile $ setDbQuota $
setWarningThreshold $ shortName ) )

Обратите внимание на то, что каждый класс объекта начинается со строки чисел, разделенных десятичными дробями. Этот номер упоминается как идентификатор объекта OID (object identifier). После OID находится имя класса объекта (NAME), за которым следует описание (DESC). Если класс является подчиненным по отношению к другому классу объекта, то приводится вышестоящий [SUP (superior)] класс объекта. Наконец, в определении класса объекта указывается, какие атрибуты являются обязательными (MUST), а какие необязательными (MAY).

OID является числовой строкой, которая используется для уникальной идентификации объекта. Идентификаторы OID относятся к управляемой иерархии, которую администрируют Международная организация по стандартизации [International Organization for Standardization (ISO)] (Web-сайт организации ISO расположен по адресу http://www.iso.ch/) и Международный институт электросвязи [International Telecommunication Union (ITU)[ (Web-сайт организации ITU расположен по адресу http://www.itu.ch/). Организации ISO и ITU делегируют управление идентификаторами OID другим организациям путем задания им номеров OID. Эти организации могут затем назначать идентификаторы OID объектам или далее делегировать полномочия по их управлению другим организациям. Идентификаторы OID, связанные с объектами в протоколах и структурах данных, определяются с использованием языка для описания абстрактного синтаксиса данных ASN.1 (Abstract Syntax Notation).

Подразумевается, что идентификаторы OID являются глобально уникальными. Они формируются путем взятия уникальной числовой строки (к примеру, 1.3.4.7.4.17 ) и добавления к ней дополнительных разрядов в уникальной форме (например, 1.3.4.7.4.17.1, 1.3.4.7.4.17.2, 1.3.4.7.4.17.3 и т. д.). Организация может получить "ветвь" (branch) от некоторого корня (root) или вершины ( vertex ) в структуре дерева OID. Подобная ветвь обычно упоминается как сектор или дуга ( b ) (в предыдущем примере это был 1.3.4.7.4.17 ). После этого организация может продолжить сектор [с помощью подсекторов ( subarc )], как это показано, с целью создания дополнительных идентификаторов OID и секторов. Мы не имеем представления, почему терминология для дерева OID использует слова "вершина" ( vertex ) и "сектор" ( arc ) вместо "корень" ( root ) и "branch" ( ветвь ), которые обычно используются в LDAP и его наследстве в виде X.500.

Если у вас есть каталог LDAP, который является производным исходного кода LDAP Мичиганского университета (как множество серверов коммерческих и открытых каталогов LDAP), то определения ваших классов объектов содержатся в файлах, заканчивающихся на ".oc". Для тех из вас, кто интересуется тем, где расположено определение класса объекта "eDominoAccount", отвечаем, что это непременно индивидуально для сервера IBM Directory Server. Обратите внимание на то, что специфические для IBM идентификаторы OID начинаются с сектора 1.3.18.0.2 ; это уникальное частное корпоративное число, которое было задано компании IBM. Число разбивается следующим образом:

1 (Идентификатор OID, заданный ISO)

1.3 (Идентифицированная ISO организация)

1.3.18 (IBM)

1.3.18.0 (Объекты IBM)

1.3.18.0.2 (Распределенный каталог IBM)

Как вы уже могли понять, "обозначение с применением точки" ( dot notation ), впервые использованное организацией IETF для IP-адресов, в целях упрощения было адаптировано для идентификаторов OID. Однако, в отличие от IP-адресов, по длине OID не существует ограничений.

Если ваша организация должна определить свои собственные атрибуты для использования в ваших внутренних каталогах, вы должны рассмотреть получение своего собственного частного корпоративного числового сектора для идентификации этих атрибутов. Мы не рекомендуем вам "выдумывать" свои собственные числа, так как вы, вероятно, не сможете взаимодействовать с другими организациями (или с продуктами LDAP некоторых производителей). Это не говорит о том, что получение собственного сектора OID от организаций ISO, IANA или какого-либо другого авторитетного источника для определения собственных классов объектов и атрибутов будет гарантировать вам возможность взаимодействия. Но это позволит предотвратить использование вами идентификаторов OID, которые уже были заданы кому-то или кем-то еще. Идентификаторы OID используются только для "сравнения на предмет равенства". Это значит, что два объекта (например, атрибуты каталога или политики сертификата) рассматриваются как равные, если они имеют точно такие же OID. При использовании идентификаторов OID не предполагаются навигационные и иерархические возможности (в отличие от IP-адресов, к примеру); при заданном OID вы не сможете быстро выяснить, кто владеет этим OID, связанными OID и т. д. OID существует для предоставления уникального идентификатора. Ничто не мешает двум организациям осуществить выбор одних и тех же идентичных имен для тех объектов, которыми они управляют; однако идентификаторы OID будут уникальными при условии, что они были определены от законных чисел секторов.

Если вы заинтересованы в получении частного корпоративного числа (arc) для своей организации, вы можете подать заявку на его выделение (бесплатно) на Web-сайте организации IANA по адресу:

http://www.iana.org/cgi-bin/enterprise.pl

За дополнительной информацией относительно идентификаторов OID, деревьев заданных чисел и регистрации мы рекомендуем обратиться сначала к Web-сайту с информацией о часто задаваемых вопросах по ASN.1:

http://asn1.elibel.tm.fr/oid/faq.htm