Приложение A — LDAP: Наследование объектных классов

Для 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: [email protected]
ou: sales
title: super hero
...

# В большинстве современных LDAP-систем достаточно определить только
# объектный класс самого последнего уровня иерархии, используемый в записи
dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: [email protected]
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.

Использование иерархии объектных классов LDAP

На практике, OpenLDAP версий 2.x+ способен обработать иерархию объектных классов, таким образом, следующий фрагмент LDIF, который функционально идентичен первому фрагменту LDIF на этой странице, будет прекрасно работать (и, возможно, немного меньше смущать):

dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: [email protected]
ou: sales
....

Внимание: Если Вы экспортируете данное определение из OpenLDAP, на выходе будет именно то, что Вы указали в LDIF, с помощью которого записи были созданы. Не все серверы LDAP способны автоматически обработать иерархию объектных классов. Если затем Вы попытаетесь загрузить экспортированный LDIF в LDAP-сервер, не способный обработать иерархию объектных классов, скорее всего Вы не получите желаемого результата. Если Вы используете только серверы с поддержкой обработки иерархии (например, только OpenLDAP), то можно сэкономить время, не печатая лишнего.