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

8.3.3 Атрибуты

Каждый класс объекта определяет атрибуты, или типы элементов данных, содержащиеся в этом виде объекта. Некоторыми примерами типичных атрибутов являются cn [ common name (общее имя) ], sn [ surname (фамилия) ], givenName, mail, uid и userPassword. Как классы объектов определяются с помощью уникальных идентификаторов OID, так и каждый атрибут имеет заданный ему уникальный номер OID.

Атрибуты LDAP V3 следуют описанию синтаксиса, аналогичному описанию языка ASN.1 для классов объектов. Далее следуют примеры определений атрибутов.

attribute: name
attributetypes=( 2.5.4.41 NAME 'name' DESC 'The name attribute type is the
attribute supertype from which string attribute types typically used for
naming may be formed. It is unlikely that values of this type itself will
occur in an entry.' EQUALITY 1.3.6.1.4.1.1466.109.114.2 SUBSTR 2.5.13.4
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
attribute: sn
attributetypes=( 2.5.4.4 NAME ( 'sn' 'surName' ) DESC 'This is the
X.500
surname attribute, which contains the family name of a person.' SUP
2.5.4.41 EQUALITY 2.5.13.2 ORDERING 2.5.13.3 SUBSTR 2.5.13.4 USAGE
userApplications )
attribute: mail
attributetypes=( 0.9.2342.19200300.100.1.3 NAME ( 'mail' 'rfc822mailbox' )
DESC 'Identifies a users primary email address (the email address retrieved
and displayed by white-pages lookup applications).' EQUALITY 2.5.13.2
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )

Во втором примере обратите внимание на то, что вышестоящим ( SUP ) для sn является атрибут 2.5.4.41, который представляет собой атрибут name (приведенный в первом примере). Но описание атрибута name говорит о том, что "маловероятно, что значения самого этого типа встретятся". Это иллюстрирует только одну из множества особенностей способа определения атрибутов. Он просто предоставляет способ условных обозначений при определении именных атрибутов, таких, как фамилия. Нам не надо определять синтаксис для sn, так как он наследуется от name.

Обратите внимание на то, что в третьем примере атрибут mail имеет также альтернативное имя (псевдоним) rfc822mailbox. Как вы могли догадаться, EQUALITY и SYNTAX являются еще одними определениями языка ASN.1.

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

8.3.4 Преобразование записей и атрибутов

Чтобы диалог имел смысл для всех участников, каждый вовлеченный в него должен понимать, обмен какой информацией происходит в процессе его. Но вы, наверно, сможете назвать источники данных, представляющие свой контент различными способами. Одна система может представлять телефонный номер как текстовую информацию, включая тире и круглые скобки, которые используются для облегчения прочтения номера. Другая система может сохранять номер как цифровые данные.

Если эти две системы взаимодействуют относительно этих данных, то информация в процессе диалога должна быть преобразована. Кроме того, информация в одном источнике может быть неполной и может нуждаться в дополнении атрибутами из других источников данных. К тому же в потоке к некоторым из источников и целевых объектов данных может иметь отношение только часть данных.

Выбор того, какие поля или атрибуты обрабатываются в потоке данных или передаются источнику данных, а также того, как каждая из связанных систем обращается к этой информации и представляет ее, называется преобразованием атрибутов (attribute mapping). Обработка данных, требуемая для "перевода" данных из одного собственного синтаксиса в другой собственный синтаксис каталога, называется трансформацией данных (data transformation).

Метод, используемый для согласования элементов каталога-источника и каталогацели, известен как преобразование записей (record mapping). Преобразование записей в рамках синхронизации каталогов является методом, посредством которого мы устанавливаем соответствие между элементом пользователя в каталоге "А" и его элементом в каталоге "Б". Исходя из нашего опыта, это зачастую тяжелая задача. Проблема состоит в несовместимости имен, используемых в различных каталогах. К примеру, "James L Smith" из кадрового каталога существует как "Jim Smith" в каталоге корпоративной электронной почты и как "JLSmith" в сетевой операционной системе. Таким образом, в большинстве организаций для пользователей существует то, что известно как множество личностей ( multiple identities ): более одного представления имени для одного и того же человека (или группы людей).

Множество идентификаторов личности

Тэрри Хоуэлл, руководитель проекта Navy Enterprise Portal командования Space and Naval Warfare Systems Command (SPARWAR), был недавно процитирован в прессе, как сказавший "Пользователи могли бы иметь 100 000 личностей ( identities, или ID ), причем все из них со своим собственным методом предоставления авторизации…". Он имел в виду приблизительно 720 000 пользователей интранет-портала флота США и усилия, требуемые для связи воедино каких-нибудь 200 000 существующих приложений с целью использования единственного, общего (для каждого пользователя) ID. "100 000 ID" для каждого из пользователей может быть критическим пределом диапазона; однако сегодня не редкость иметь для каждого из различных существующих приложений свои собственные каталоги аутентификации специализированных пользователей. Поэтому перед тем, как полагать, что ваша организация "лучше, чем флот США", задумайтесь, а подсчитали ли вы на самом деле все те старые серверы и приложения, которые вы еще используете, и которые имеют зарегистрированные на них идентификаторы ID специализированных пользователей? Когда вы обратитесь к отдельным хостам, таким как общие UNIX-модули и разнообразные приложения, развернутые на уровне отделов, то количество идентификаторов ID для любого предоставленного пользователя может действительно стать огромным.

Множество личностей может состоять из вариаций имени и различных идентификаторов входа в систему и паролей. Мы не ограничиваем эти вариации только самими именными атрибутами: различия в структурах иерархических деревьев могут представлять аналогичные трудности (или даже более сложные). Например, пользователь может иметь следующие отличительные имена [distinguished names ( DN )] элементов каталогов:

LDAP Directory: cn=Brendan C Hinkle,ou=West,o=Acme,dc=acme,dc=com
Domino Directory: CN=Brendan Hinkle/OU=Finance/O=Acme
Active Directory: uid=bhinkle,cn=users,dc=corp,dc=acme,dc=com

Это показывает, что мы можем иметь не только различные общие имена, но и различные отличительные имена и не существует должного способа установить их соответствие одному и тому же человеку со 100 %-й уверенностью.

Итак, что же мы можем сделать, когда пользователи, по существу, имеют две подобные, но необязательно соответствующие личности, под которыми они известны? Ответ состоит в том, что мы должны идентифицировать корреляцию (согласование) данных, или ключи корреляции (correlation keys), которые могут быть использованы для установления соответствия записей пользователя с гарантированной достоверностью. Если мы расширим предыдущий пример в целях отображения некоторых дополнительных атрибутов, мы сможем увидеть несколько опций для корреляции.

LDAP Directory: cn=Brendan C Hinkle,ou=West,o=Acme,dc=acme,dc=com
uid=bhinkle
empid=10543
mail=""
Domino Directory: CN=Brendan Hinkle/OU=Finance/O=Acme
internetaddress=b_hinkle@acme.com
employeeid=BC10543
Active Directory: uid=bhinkle,cn=users,dc=corp,dc=acme,dc=com
logonPrincipalName=bhinkle
mail=b_hinkle@acme.com

Несмотря на то что это может показаться очень простым примером, все становится достаточно сложным, когда вы начнете задаваться вопросом, откуда появились значения атрибутов. Помните нашу дискуссию об опорных точках? Рассмотрим атрибут mail в LDAP и AD и атрибут internetaddress в Domino. Предположим, что SMTP-адрес пользователя был задан администратором Domino. Насколько достоверным будет это как ключ корреляции между Domino и AD? Между Domino и LDAP? Чтобы ответить на этот вопрос, вы должны знать, как заполняется этот атрибут в AD и LDAP. Если в AD для этого атрибута существует самообслуживаемая опорная точка, что означает предоставление пользователю возможности вводить свой собственный SMTP-адрес, то это не является достоверным ключом между Domino и AD. При ближайшем рассмотрении мы обнаружим, что каталог Domino раз в неделю получает от LDAP определенные "подачи" и использует их для заполнения идентификатора служащего в Domino. Единственным отличием здесь является то, что к номеру служащего предварительно добавлены первый и последний инициалы пользователя. Другими словами, существует трансформация данных, но мы знаем алгоритм, и этот алгоритм является реверсивным. Теперь мы идентифицировали ключ корреляции, который можно использовать для автоматической синхронизации между нашими каталогамм LDAP и Domino, и мы способны также достоверно преобразовывать записи пользователей между двумя этими каталогами. Теперь мы в состоянии взять SMTP-адрес пользователя из авторитетного источника – Domino – и заполнить поле mail в каталоге LDAP (которое в текущий момент имело нулевое значение).