Для LDAP определено множество правил, но одно из самых основных — то, что у записи может быть только один структурный (STRUCTURAL) объектный класс. В ситуации, показанной ниже, может создаться впечатление (неверное), что это правило нарушается.
Примечание: Во многих документах утверждается, что в LDIF-файлах, описывающих DIT и его записи, должна указываться полная иерархия объектных классов, как показано в первой части приведённого ниже фрагмента LDIF. Но есть и другой подход, поддерживаемый большинством современных LDAP-серверов, при котором требуется указать только объектный класс самого последнего уровня в иерархии (содержащий атрибуты, которые будут использоваться); этот подход показан во втором фрагменте LDIF, который функционально идентичен первому фрагменту (есть некоторый побочный эффект от использования данной структуры):
# явное определение всех объектных классов, используемых в записи dn:cn=Jim Bob,ou=people,dc=example,dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: Jim Bob sn: Bob mail: jimbob@example.com ou: sales title: super hero ... # В большинстве современных LDAP-систем достаточно определить только # объектный класс самого последнего уровня иерархии, используемый в записи dn:cn=Jim Bob,ou=people,dc=example,dc=com objectclass: inetOrgPerson cn: Jim Bob sn: Bob mail: jimbob@example.com ou: sales title: super hero ...
Все объектные классы person, organizationalPerson и inetOrgPerson являются структурными (в первом фрагменте все указаны явно, во втором первые два неявно подразумеваются). Кажется, правило о том, что запись может содержать только один объектный класс структурного типа, нарушено.
Но это не так.
Объектные классы могут быть частью иерархии, что указывается в определении объектного класса с помощью параметра SUP с именем вышестоящего объектного класса, отличного от top. Когда объектные классы определяются таким способом, каждый дочерний объектный класс ДОЛЖЕН быть того же типа (STRUCTURAL или AUXILLIARY), что и его вышестоящий (родительский) объектный класс. Кроме того, он наследует все атрибуты своего родителя (родителей). В приведённом выше фрагменте LDIF мы просто имеем иерархию структурных объектных классов. Для иллюстрации, объектный класс organizationalPerson содержит атрибут title. Однако, когда мы указываем в записи объектный класс inetOrgPerson, в определении которого присутствует SUP organizationalPerson, то есть organizationalPerson является родительским по отношению к inetOrgPerson, мы можем использовать атрибут title (даже если указывается только один inetOrgPerson, как во втором фрагменте LDIF выше). Мы унаследовали title (как и все остальные атрибуты) от родительского объектного класса. В свою очередь, в определении organizationalPerson есть указание SUP person, таким образом, мы можем использовать любые атрибуты, присутствующие в определении объектного класса person.
LDAP не может поддерживать множественное наследование в полном смысле этого слова. Однако, в особых условиях, объектные классы могут иметь в определениях несколько имён вышестоящих (SUP) объектных классов и могут наследовать свойства от нескольких родителей:
# Из RFC 1274 objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization' SUP ( organization $ organizationalUnit ) STRUCTURAL MAY buildingName )
В определении pilotOrganization указано два вышестоящих объектных класса: organization и organizationUnit, и оба они являются структурными. Теперь у нас действительно нарушается правило единственного структурного объектного класса в записи? Не совсем. Посмотрим немного поглубже на то, как определяются объектные классы. Вот ASN.1-определение pilotOrganization:
pilotOrganization OBJECT-CLASS SUBCLASS OF organization, organizationalUnit MAY CONTAIN { buildingName} ::= {pilotObjectClass 20}
Данное ASN.1-определение говорит о том, что pilotOrganization является подклассом (SUBCLASS OF) сразу и oganization, и organizationalUnit. Теперь посмотрим на ASN.1-определения organization и oganizationalUnit:
organizationalUnit OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { organizationalUnitName} MAY CONTAIN { organizationalAttributeSet} ::= {objectClass 5} organization OBJECT-CLASS SUBCLASS OF top MUST CONTAIN { organizationName} MAY CONTAIN { organizationalAttributeSet} ::= {objectClass 4}
Оба они являются подклассом (SUBCLASS OF) top, то есть они представляют собой самый верхний уровень своих иерархий. Таким образом, если в определении OBJECT-CLASS указано несколько родителей, то допустимо использовать множественное наследование, в ином случае — нет. Почти не существует определений OBJECT-CLASS, предоставляющих такую возможность — кроме pilotOganization мы не нашли ни одного.
Примечание: RFC 1274, определяющее pilotOrganization, стало устаревшим с выходом RFC 4524, и приведённых выше определений ASN.1 в этом RFC больше нет. Однако, файл cosine.schema (OpenLDAP 2.4.11) всё ещё содержит pilotOrganization.
На практике, OpenLDAP версий 2.x+ способен обработать иерархию объектных классов, таким образом, следующий фрагмент LDIF, который функционально идентичен первому фрагменту LDIF на этой странице, будет прекрасно работать (и, возможно, немного меньше смущать):
dn:cn=Jim Bob,ou=people,dc=example,dc=com objectclass: inetOrgPerson cn: Jim Bob sn: Bob mail: jimbob@example.com ou: sales ....
Внимание: Если Вы экспортируете данное определение из OpenLDAP, на выходе будет именно то, что Вы указали в LDIF, с помощью которого записи были созданы. Не все серверы LDAP способны автоматически обработать иерархию объектных классов. Если затем Вы попытаетесь загрузить экспортированный LDIF в LDAP-сервер, не способный обработать иерархию объектных классов, скорее всего Вы не получите желаемого результата. Если Вы используете только серверы с поддержкой обработки иерархии (например, только OpenLDAP), то можно сэкономить время, не печатая лишнего.
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 21 октября 2015 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2017 г.