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

8.2.1 Авторитетные источники

Сохраненная в записи каталога пользователя информация упорядочена в виде раздельных атрибутов (attributes) или полей. Диапазон сохраненной в каталоге информации зачастую устанавливается требованиями приложения или множеством использующих ее приложений. Мы определяем авторитетный источник (authoritative source) как наивысший, компетентный орган в организации, который генерирует, назначает или проверяет достоверность значений атрибутов данных.

Например, рассмотрим следующие атрибуты в очень простой записи каталога для пользователя:

В этом примере обратите внимание на то, что мы имеем три авторитетных источника для четырех атрибутов. Кадровый ресурс является авторитетным источником для имени и номера служащего, обслуживающий персонал связи является авторитетным источником для номера телефона, а ИT-персонал является авторитетным источником для адреса электронной почты. В интересах этого примера нам не надо было точно определять, из чего состоит атрибут name (имя) (мы обсуждаем проблемы, связанные с именами, в разделе "Множество личностей").

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

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

8.2.2 Опорные точки

Опорная (контрольная) точка (point of control) определяется как интерфейс, который предоставляет возможность выполнения операций записи во всей или части записи данных личности. Операция записи может состоять из добавления новой записи, изменения существующей записи или удаления всей существующей записи. Операция чтения является только выборкой данных без их изменения. Большинство каталогов спроектированы в расчете на значительно большие пропорции операций чтения по отношению к операциям записи.

Как правило, опорные точки имеют ограничения доступа, которые ограничивают или разрешают определенным людям, серверам или приложениям выполнять операции записи. Опорные точки могут быть исключительными и неисключительными. Уровни исключительности могут варьироваться от всего каталога до единственной записи либо даже до отдельного атрибута. Исключительность для опорной точки означает, что другая опорная точка не может перекрывать ее рамки относительно того, какие данные могут быть записаны.

Примером исключительной опорной точки может служить процесс генерирования уникального номера служащего. Процесс должен иметь единоличную возможность определения значения данного атрибута, и никакой другой интерфейс не может предоставить средства его изменения. Этот процесс может подвергаться управлению со стороны вышестоящего процесса или интерфейса, которые располагают единоличной способностью добавлять новую запись служащего.

Примером неисключительной опорной точки может быть атрибут псевдонима человека. Служащий может располагать интерфейсом и возможностью изменять его самостоятельно в дополнение к другим людям или группам, которые располагают интерфейсами и возможностями по изменению этого атрибута, таким, как их менеджер и кадровый персонал.

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

8.2.3 Управление данными

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

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

Для содействия улучшению совместимости данных относительно множества каталогов опорные точки для различных атрибутов, совместно используемых в различных каталогах, должны быть ограничены одним каталогом. Это не говорит о том, что единственный каталог должен быть опорной точкой для всех принадлежащих личности атрибутов. Мы имеем в виду, что любой заданный атрибут должен иметь ограниченное число опорных точек, хотя различные опорные точки атрибута могут быть размещены в различных каталогах. К примеру, атрибут "А" должен быть ограничен до возможности изменения из единственной опорной точки в каталоге "1", в то время как атрибут "Б" должен быть ограничен до возможности изменения из единственной опорной точки в каталоге "2" и т. д. Но при наличии множества каталогов это подразумевает, что должно существовать нечто взамен для внесения изменений, сделанных в одном атрибуте из опорной точки в одном каталоге, и в другие каталоги, которым также необходимо хранить этот атрибут. Нам необходимо применять сделанные в одном месте изменения во всех остальных местах (каталогах), в которых должны сохраняться идентичные данные. Это "нечто", что должно применяться взамен, является синхронизацией данных между различными каталогами, которую мы рассмотрим в следующем разделе.

8.3 Синхронизация каталогов

Синхронизация данных между двумя или более различными каталогами называется синхронизацией каталогов. Синхронизация каталогов требует обмена данными между двумя или более системами каталогов. Направление изменений, или поток данных, должно быть согласовано с авторитетными источниками. Данные должны перемещаться от авторитетных источников к неавторитетным источникам. Синхронизация каталогов может быть использована как средство для объединения хранилища мандатов, применяемых для аутентификации пользователей, и употребления единообразных личностей пользователей в интересах элементов управления доступом. Мы обсудили практические приложения для объединения мандатов пользователей в лекции 7, "Принцип единого входа (Single sign-on)".

Проект синхронизации каталогов должен подробно описывать все аспекты обмена данными или взаимодействия. Такое взаимодействие может быть разложено на следующие составляющие:

8.3.1 Источники данных

Ранее в этой лекции мы уже обсуждали понятие авторитетных источников. В контексте синхронизации каталогов источниками данных являются каталоги или хранилища (репозитории), между которыми нам необходимо организовать обмен данными.

Перед тем как вы сможете определить инструменты, или методы, которые можно использовать для обмена данными, в первую очередь вы должны обозначить каталоги и интерфейсы, поддерживаемые каждым из них. Как правило, каталоги поддерживают некоторую форму интерфейса прикладного программирования [application programming interface (API)], также они могут поддерживать операции чтения и обновления LDAP, групповой импорт или экспорт файлов. Инструменты для синхронизации каталогов мы обсудим в этой лекции позднее. В практических целях мы можем использовать термины "источник данных" и "каталог" поочередно. Однако обратите внимание на то, что мы должны проводить различие между источником и целевым объектом. Обратите внимание на то, что одинаковые данные могут иметь множество целевых каталогов, но будут иметь только один каталог-источник.

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

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 (которое в текущий момент имело нулевое значение).

Преобразование идентификатора личности

В предыдущем примере мы имели три различных элемента каталога для одного и того же человека. Теперь рассмотрим, что мы должны сделать для преобразования идентификатора личности ( identity ), или отличительного имени (DN), этого человека в рамках приложения, когда одно имя представляется как аутентифицированный пользователь, а нам необходимо применить другое имя в интересах элементов управления доступом. В разделе 7.2, "LTPA", мы обсуждали использование для аутентификации пользователя cookie сеанса браузера. Маркер LTPA компании IBM является характерным примером cookie сеанса, который был определен компанией IBM. Для преобразования DN из cookie LTPA, полученного HTTP-сервером Domino, в другое DN в целях управления доступом мы используем прямое преобразование (direct mapping). Это преобразование конфигурируется в рамках Domino Directory Assistance при условии, что для аутентификации браузером мы применяем каталог LDAP. Требуемые элементы каталогов показаны в примере 8.2.

LDAP Directory: cn=Brendan C Hinkle,ou=West,o=Acme,dc=acme,dc=com
empid=10543
mail=b_hinkle@acme.com
notesname=cn=Brendan Hinkle,OU=Finance,O=Acme
Domino Directory: CN=Brendan Hinkle/OU=Finance/O=Acme
internetaddress=b_hinkle@acme.com
employeeid=BC10543

В этом примере, если именем DN из cookie LTPA является "cn=Brendan C Hinkle, ou=West, o=Acme, dc=Acme, dc=com" и конфигурация в рамках Domino Directory Assistance определяет атрибут notesname как содержащий иерархическое имя Notes атрибут LDAP, сервер Domino способен осуществить выборку преобразованного имени прямо из элемента LDAP путем сначала поиска DN в каталоге LDAP, а затем получения значения атрибута notesname как части запроса. Итак, Domino получает "преобразованное имя" "cn=Brendan Hinkle, OU=Finance, O=Acme", которое интерпретирует как иерархическое каноническое имя "CN=Brendan Hinkle/OU=Finance/O=Acme". Таким образом, после этого данному пользователю был бы предоставлен доступ при условии, что это иерархическое имя содержится в запрашиваемом списке управления доступом ACL базы данных Domino. Такое преобразование имен, как было описано, доступно в качестве свойства Domino 6 и выше.

Обратите внимание на то, что мы можем реализовать преобразование имен и с использованием другого метода, как более целесообразного для Domino 6.02+ и Domino 5.x. Вместо синхронизации иерархического имени Notes и атрибута в вашем каталоге LDAP, конфигурирования атрибута в Directory Assistance мы можем применить "противоположный подход". Если мы добавляем отличительное имя (DN) LDAP пользователя в список полных имен Domino (с расположением иерархического имени Notes как первого значения), мы будем иметь элементы каталогов, показанные в примере 8.3.

LDAP Directory: cn=Brendan C Hinkle,ou=West,o=Acme,dc=acme,dc=com
mail=b_hinkle@acme.com
Domino Directory: CN=Brendan Hinkle/OU=Finance/O=Acme
fullname= "CN=Brendan Hinkle/OU=Finance/O=Acme",
"cn=Brendan C Hinkle,ou=West,o=Acme,dc=acme,dc=com"
internetaddress=b_hinkle@acme.com

В этом примере, когда сервер Domino представлен cookie LTPA с отличительным именем (DN) "cn=Brendan C Hinkle, ou=West, o=Acme, dc=acme, dc=com", в каталоге Domino он найдет документ person, а с помощью Directory Assistance как результат того же запроса поиска имени он также найдет элемент LDAP. Почтовые SMTP-адреса двух элементов сравниваются, и так как они являются одинаковыми, то после этого Domino будет использовать иерархическое имя документа person в целях всего последующего доступа.

Опции преобразования имен в Domino описаны более детально в разделе 11.9.4, "Сопоставление имен в Domino".

В сеансовых cookie возможны и другие схемы преобразований, однако они приводят к возникновению проблем с производительностью в тех случаях, когда в cookie не содержится DN пользователя. Непрямое преобразование (indirect mapping) – это когда представленный в cookie сеанса идентификатор пользователя требует проведения более чем одной операции поиска и выборки для преобразования имени маркера (cookie) или идентификатора в отличительное имя (DN) для использования его в целях предоставления доступа. Если мы применяем те же записи, которые показаны в примере 8.2, но не имеем в записи LDAP атрибута notesname, обратите внимание на то, что у нас есть атрибут empid, который находится в связи с частью атрибута "emploeeid" в каталоге Domino. В этом случае мы предположим, что для выполнения преобразования имен в Domino применяется пользовательский фильтр DSAPI. Таким образом, если пользовательская архитектура cookie сеанса предоставляет нам значение LDAP "empid=10543", то Domino в первую очередь будет необходимо осуществить выборку DN для пользователя, в связи с чем в каталоге LDAP будет производиться поиск по значению "empid=10543", в результате которого будет найдено значение "cn=Brendan C Hinkle, ou=West, o=Acme, dc=acme, dc=com".

Выборку отличительного имени DN необходимо осуществлять, так как Domino требуется проверить, что DN предварительно аутентифицированного пользователя соответствует правилам среды присваивания имен, определенным в Directory Assistance для каталога LDAP. Итак, теперь наш фильтр DSAPI знает, что мандат пользователя является действительным, но ему все еще требуется осуществить преобразование идентификатора cookie, "empid", в иерархическое имя Notes. Таким образом, далее нашему фильтру DSAPI будет необходимо найти для empid=10543 элемент каталога Domino. Так как по формату атрибут employeeid в Domino является номером ID служащего, в начале которого стоят инициалы пользователя, то результат нашего поиска в каталоге Domino необходимо преобразовать в "новый" формат, по нахождению которого мы смогли бы передать имя пользователя в форме "CN=Brendan Hinkle/OU=Finance/O=Acme". Таким образом, при определении преобразованного имени для использования в целях управления доступом нам необходимо произвести два поиска в каталоге.

Если этот пример был для вас довольно труден, то теперь вы знаете, почему мы не рекомендуем использовать любые схемы с применением cookie сеанса, которые влекут за собой непрямое преобразование имен!

8.3.5 Потоки данных

Потоки данных (data flows) являются потоками информации между каталогами и их содержимым (контентом). Потоки данных обычно обозначаются как стрелки, указывающие направление движения данных, от каталога-источника к каталогу-цели.

Каждый поток данных представляет уникальную информацию, передаваемую от одного набора источников данных к другому. Это связывает нас с приведенным ранее понятием авторитетных источников (authoritative sources), определяемых на основе атрибутов. Таким образом, вместо того чтобы предполагать, что все атрибуты одного каталога передаются в другой каталог, правильным будет считать, что из источника берутся только авторитетные атрибуты и такие же данные источника могут быть использованы во множестве каталогов-целей.

Единственным исключением в назначении потоков данных являются пароли пользователей. Мы обсуждали вопросы безопасности и проблемы, связанные со способностью извлекать пароли пользователей и записывать их в другие каталоги-цели, в разделе "Синхронизация паролей".

8.3.6 Событийно-управляемая синхронизация

События (events) могут быть описаны как предписание условий относительно того, когда один набор источников данных взаимодействует с другим. Примером события является каждый случай, когда служащий добавляется, изменяется или удаляется в рамках кадровой системы. Другим примером является случай, когда система управления доступом обнаруживает карточку-ключ, используемую в закрытой зоне. В основе события может также лежать календарь или часовой таймер, например начало взаимодействия может назначаться на полночь каждого дня за исключением воскресенья. Это может быть даже одноразовое событие, например заполнение каталога.

Обычно события связаны с источником данных и имеют отношение к потокам данных, которые запускаются в случае возникновения заданного набора условий.

8.3.7 Инструменты

Для выполнения синхронизации каталогов существует несколько доступных инструментов. В этом разделе мы опишем три инструмента, доступные на текущий момент у компании IBM. Эти инструменты поддерживают синхронизацию каталогов между Lotus Domino и другими сторонними каталогами.

ADSync

Инструмент Active Directory Synchronization, или ADSync, позволяет администраторам Active Directory управлять (регистрировать, удалять или переименовывать) пользователями и группами в Active Directory и в Domino Directory как унифицированной операцией из Active Directory Users и Computers Console.

Для использования Lotus Active Directory Synchronization клиент Domino Administration должен быть установлен на той же рабочей станции, которая применяется для управления пользователями и компьютерами в вашем Active Directory. Несмотря на свое название, ADSync на самом деле не является инструментом синхронизации каталогов. Он более подобен "средству коммуникации" клиента администратора, который позволяет администраторам Windows управлять как пользователями Domino Directory, так и ADSync из единого пользовательского интерфейса. И Domino и Windows имеют свои собственные мандаты пользователей, консоли управления и каталоги. ADSync соединяет их двоих на одной машине, и таким образом сделанные в ADSync изменения продвигаются в Domino с применением установленного, но, по существу, скрытого клиента Domino Administrator. Другими словами, этот инструмент выполняет функции администратора одновременно, но скрывает вторичные изменения в Domino с экрана администратора.

ADSync является новой возможностью, включенной в Domino 6. C его помощью вы можете создать новых пользователей и группы в Active Directory и отобразить эти изменения в Domino Directory, включая создание для пользователей документов person или group, идентификаторов Notes ID, паролей и почтовых файлов. С целью выполнения этих задач администратор Active Directory должен иметь надлежащим образом сертифицированный Notes ID и соответствующий уровень доступа для внесения изменений в Domino Directory. Сервером регистрации должен быть Domino 6 или выше, клиент Domino Administration должен быть версии 6 или выше. В дополнение к этому должны быть созданы политики, которые содержат политики нижнего уровня (sub policies), либо явные, либо неявные, для всех органов сертификации Domino, где будут создаваться пользователи. В заключение вы должны иметь соответствующие права в Active Directory для добавления пользователей и групп, а также для синхронизации паролей.

Подробности и примеры конфигурирования и использования ADSync можно найти в документе компании IBM Active Directory Synchronization with Lotus ADSync, REDP0605, который доступен в PDF-формате по адресу:

http://www.redbooks.ibm.com/redpapers/pdfs/redp0605.pdf

LDAPSync Solution

LDAPSync Solution является комбинацией программного продукта и службы, предлагаемой IBM Software Services for Lotus. Он включает в себя инструментарий, который может быть использован для предоставления средств синхронизации данных между каталогами, имеющими возможность работать с LDAP, и базами данных Domino. Если быть более точным, он предоставляет средства для импортирования информации корпоративных каталогов, не имеющих отношения к Domino, в среду Lotus.

Типичным способом использования такого продукта является предоставление пользователям Notes средств для обеспечения наличия в их открытых адресных книгах списка работающих для компании людей, а также их телефонных номеров или адресов электронной почты. Однако возможны также и более сложные способы использования, потому что это решение способно синхронизировать каталоги с базами данных Domino любого типа.

Инструментарий включает три компонента:

Комбинация трех этих программ предоставляет мощные средства синхронизации между каталогами LDAP и Domino.

LDAPSync может использоваться в различных целях. Например, этот компонент может быть использован:

RunAgent может использоваться для запуска специальных агентов, например для обновления данных "на лету". Классическим способом использования этого компонента является вызов его в командном файле после LDAPSync. В свою очередь, агент может форматировать полные имена Notes (Notes Full Names), так как их часто надо получать из отличительных имен X.500 (X.500 Distinguished Name).

SynchroNSF может реплицировать поля данных из баз данных Domino разнородной структуры. Телефонные номера служащих могут быть автоматически вставлены в базу данных, содержащую "Software Bug Reports", а также в каталог Domino.

Рис. 8.1 отображает типичное приложение, использующее этот инструментарий.

LDAPSync может быть использован для выполнения одного или более следующих типов синхронизации данных:

Простая синхронизация

Простая синхронизация (simple synchronization) означает, что содержимое базы данных-источника синхронизируется с единственной базой данных-целью (одна к одной).

Это наиболее распространенный случай, при котором вы хотите создать базу данных Domino (Цель), которая будет включать только часть документов другой базы данных (Источника). В этих документах вы можете захотеть хранить только некоторые из полей.

Например, при использовании каталога LDAP как базы данных-источника рассмотрим создание базы данных "Business card", содержащей только элементы, относящиеся к человеку ( ObjectClass=Person ). Из этих элементов может быть осуществлена выборка только полей имени ( Name ), имени человека ( First Name ), адреса ( Address ) и номера телефона ( Phone number ).

Синхронизация может также быть реализована, когда база данных-цель уже существует (со всеми своими документами) и вы желаете только оказать воздействие на одно или два поля в существующих документах. К примеру, если вы работаете с кадровым каталогом LDAP, включающим номера телефонов служащих компании, вы можете обновлять номера телефонов в документах Person каталога Domino.

Рассылка

Синхронизация в виде рассылки (broadcast) – это когда вы синхронизируете единственную базу данных-источник со множеством баз данных-целей (одна ко многим).

Рассылка позволяет распространять содержимое базы данных-источника по направлению ко многим базам данных-целям, например, если вы использовали каталог LDAP для обновления одной базы данных, включающей людей, и другой базы данных, включающей группы. Процесс рассылки данных из одной базы данных-источника во множество баз данных-целей может быть представлен как последовательность простых синхронизаций, которые совместно используют общую базу данных-источник.

Резюмирование

Резюмирование (summarization) – это когда вы синхронизируете множество баз данных-источников с единственной базой данных-целью (многие к одной).

Процесс резюмирования позволяет вам сгруппировать содержимое нескольких баз данных (источника) в единственную базу данных (цель). Резюмирование данных из нескольких баз данных-источников в единственную базу данных-цель можно представить как последовательность простых синхронизаций различных источников с общей базой данных-целью.

Согласованность данных

При синхронизации в виде обеспечения согласованности данных (data consistency) содержимое базы данных-источника синхронизируется с другой базой данных (одна к одной), однако документы и атрибуты данных необязательно находятся между собой в отношении "один к одному".

В отличие от других типов синхронизации процесс обеспечения согласованности данных не создает документы в базе данных-цели в соответствии со взаимно, однозначным отношением с документами в базе данных-источнике. Основной целью тут является поддержание взаимосвязи между некоторыми значениями, сохраненными в базе данных-источнике, и другими значениями, сохраненными в базе данных-цели.

В отличие от реляционных баз данных Domino не может установить связи между полями, которые сохранены в различных документах. К примеру, документы Person в вашем каталоге Domino содержат имена и телефонные номера ваших торговых агентов. Теперь предположим, что эти телефонные номера хранятся также в других базах данных Domino, каких, как Customer management (Управление клиентами), Sales leads (Потенциальные покупатели) и Purchasing (Покупки). Если телефонный номер изменен в документе Person, Domino не может в действительности передать это изменение документу другой базы данных, которая также содержит этот телефонный номер.

При таком сценарии не существует взаимно-однозначных отношений между документами, хранящимися в указанном порядке в двух базах данных. Значения, связанные с одним-единственным документом в базе данных-источнике (которые мы рассматриваем как "контрольные значения" авторитетного источника), синхронизируются с несколькими документами в базе данных-цели (неавторитетными "вторичными значениями"). Как и в реляционных базах данных, такая синхронизация в виде обеспечения согласованности данных является способом сохранения упорядоченности данных (единственности значений).

LDAPSync может использоваться для поддержания строгого соответствия (постоянства) между значениями полей, которые сохранены в различных документах/базах данных, без необходимости модифицировать уже используемые базы данных. Вы должны определить базу данных, содержащую контрольные значения (например, это будет каталог LDAP вашей компании), как авторитетную базу данных-источник, а также определить базы данных, содержащие вторичные значения [каталог Domino, база данных Contacts (Контакты) и т. д.], как базы данных-цели. LDAPSync будет выполнять обновление этих значений всякий раз, когда будут изменяться контрольные значения.

Обратите внимание на то, что LDAPSync ограничен до выборки данных из баз данных-источников LDAP или Domino и способен обновлять только базы данных Domino. Для обеспечения способности к взаимодействию с дополнительными типами источников и целей данных мы рекомендуем инструмент IBM Tivoli Directory Integrator, который мы обсудим далее.

IBM Tivoli Directory Integrator

Интегратор каталогов IBM Tivoli Directory Integrator синхронизирует личностные данные, постоянно хранящиеся в каталогах; базах данных; объединенных системах; приложениях, используемых для кадровых приложений (HR), приложений по управлению взаимодействием с клиентами (CRM), приложений по планированию и управлению ресурсами предприятий (ERP) и других корпоративных приложений.

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

С некоторыми встроенными соединительными элементами (connectors), средой разработки Java с открытой архитектурой для расширения или модификации этих соединительных элементов и c инструментами для применения определенной логики к данным на этапе их обработки Directory Integrator может использоваться:

IBM Tivoli Directory Integrator является компонентом решения по управлению идентификаторами личностей (identity management) компании IBM, который может помочь вам достичь того, что пользователи, системы и приложения будут работать в темпе поступления информации (online), а также достичь устойчивой производительности, уменьшения стоимости и максимального возврата инвестиций. Решение по управлению идентификаторами личности от компании IBM предусматривает управление жизненным циклом идентификаторов личности (самообслуживание, регистрация и подготовка к работе пользователей), контроль идентификаторов личности (управление доступом и секретностью, единый вход и аудит), объединение идентификаторов личности (совместное использование доверенными приложениями Web-служб аутентификации пользователей и информации об атрибутах) и учреждение идентификаторов личности (каталог и последовательность выполняемых действий) в целях обеспечения эффективного управления внутренними пользователями, а также увеличения количества кли ентов и партнеров посредством применения Интернета.

Архитектура программного обеспечения Directory Integrator включает:

Интегратор каталогов устраняет временные и финансовые затраты, обычно требуемые для заказной разработки интерфейсов соединений в интересах широкого множества репозиториев данных. Предусмотренные при создании соединительные элементы (допускаются изменения) включают:

Ключевой концепцией продукта Directory Integrator является конструкция сборочного конвейера (assembly line), причем может быть использовано множество сборочных конвейеров. Каждый сборочный конвейер может состоять из множества входов или множества выходов либо из того и другого вместе, как это выглядит на схеме простого потока данных на рис. 8.6

Здесь вы видите третий источник данных (data source) DS3, получающий данные от исходного источника данных DS1. Параллельно с этим поток данных агрегирует информацию от второго источника данных DS2. В терминологии Directory Integrator подобный поток данных упоминается как "сборочный конвейер" (assembly line).

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

Хотя и не существует ограничений на количество соединительных элементов, которые могут содержать сборочные конвейеры, последние должны содержать настолько мало соединительных элементов, насколько это возможно (например, по одному на участвующий в потоке источник данных), несмотря на то что в то же время они должны включать достаточное количество компонентов и скриптовой логики для обеспечения своей максимально возможной автономности. Помимо указанного, основанием для этого является выполнение сборочного конвейера простым для понимания и обслуживания. К тому же это приведет к более простым, более быстрым и более масштабируемым решениям. За пределами Directory Integrator весь подход сводится к тому, что мы имеем дело с потоками как с одним целым единовременно, что упрощает формулировку задачи, и таким образом вы можете сфокусировать внимание на потоке, идущем от одного каталога к другому.

Для конфигурирования сборочных конвейеров и составляющих соединительных элементов Directory Integrator предоставляет мощный графический интерфейс пользователя (GUI). В последующих нескольких изображениях мы отобразим некоторые виды экранов GUI из сборочного конвейера Idaptodom.

Входным каталогом является каталог LDAP, и мы назвали соединительный элемент readldap. Он был создан с применением стандартного типа соединительного элемента LDAP. Выходным каталогом будет каталог Domino, соединительный элемент называется updatedomuser и использует тип соединительного элемента Domino User. Когда будет сконфигурирована информация соединения для каталога LDAP, для идентификации атрибутов LDAP в GUI будет использован автоматический инструмент получения схемы. Рис. 8.8 отображает получение схемы с использованием GUI.

Как только для индикации доступных атрибутов будет сконфигурирована схема каталога-источника, атрибуты должны быть преобразованы в промежуточные рабочие элементы (атрибуты), как показано на рис. 8.9 (преобразование идет справа налево).

Как показано на рис. 8.9, у нас выбран атрибут соединительного элемента InternetAddress, и он определен для внутреннего рабочего атрибута с тем же именем. Следующим шагом осуществляют преобразование атрибутов данных промежуточных рабочих элементов в выходные атрибуты (Domino). Рис. 8.10 отображает, как определяется выходное преобразование для каждого доступного атрибута соединитель конвейера при использовании GUI администратора ного элемента Domino User. На рис. 8.10 обратите внимание на то, что на панели Connector Attribute подсвечен InternetAddress и рабочим элементом, от которого он будет получать данные, является InternetAddress (преобразование идет слева направо).

В этом случае на выходе используется соединительный элемент Domino User, который имеет предопределенные атрибуты и предусматривает специфицированные дополнительные атрибуты.

Этот пример не отображает все виды экранов (закладки), задающие конфигурацию для сборочного конвейера. Мы представили некоторые избранные виды экранов для демонстрации того, как может быть сконфигурировано преобразование атрибутов сложных данных при использовании GUI администратора Directory Integrator. С помощью этого инструмента без необходимости проведения какого бы то ни было программирования может быть построено множество различных сложных сборочных конвейеров.

Обратите внимание на то, что Directory Integrator с его обширной библиотекой соединительных элементов предоставляет все необходимое для создания информационных решений типа "запрос-ответ", таких, как Web-службы.

8.4 Служба унифицированных каталогов

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

Мы определяем службу унифицированных каталогов (unified directory service) как стратегию управления данными объединенных каталогов. Как правило, она базируется либо вокруг центрального, основного каталога, либо вокруг централизованно управляемого метакаталога, используемого для синхронизации каталогов либо их обоих вместе. Метакаталог (metadirectory) не является традиционным пользовательским каталогом; скорее он хранит информацию о том, где расположены данные, как к ним можно осуществить доступ и как протекают данные между различными каталогами. Так как он хранит только данные о данных, "метакаталог" является репозиторием этих "метаданных".

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

Идентификация авторитетных источников

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

Примером авторитетного источника может служить каталог служащих кадрового органа, где генерируется уникальный идентификатор ( ID ) служащего.

Идентификация уникальных ключей

Уникальные ключи (unique keys) являются уникальными идентифицирующими атрибутами для каждого человека, компьютера или другого ресурса. Чтобы быть ключом, атрибут должен быть универсально-используемым и универсально-уникальным. Если не применяется одиночный уникальный ключ, то для формирования уникального ключа может использоваться комбинация атрибутов. Заметьте, то, что выглядит как идеальный уникальный ключ, на самом деле может иметь ограничения. Например, SMTP-адрес электронной почты обычно уникален для каждого служащего; однако не все служащие могут иметь электронную почту.

Вторым аспектом идентификации уникальных ключей является определение границ данных, к которым может применяться ключ. Несмотря на то что ID служащего организации может быть уникальным в пределах США, он может быть не представлен или недоступен в других странах. Когда в заданном репозитории доступно множество ключей, они должны быть классифицированы как первичные (primary) и вторичные (secondary) ключи на основе их надежности. Например, первичным ключом может быть ID служащего, вторичным ключом – корпоративный SMTP-адрес электронной почты, а третичным ключом – полное имя пользователя, объединенное с номером телефона и местом работы.

Определение стратегии интеграции

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

Для большинства организаций реализация метакаталога является более быстрым и простым решением, чем реализация центрального многоцелевого основного каталога. Важно понимать различие между метакаталогом и центральным основным каталогом.

Метакаталог определяет взаимоотношения и потоки данных между различными существующими каталогами. Типично они имеют соединительные элементы, которые специально разработаны для конкретных каталогов, таких, как Domino, Active Directory, PeopleSoft HRMS и т. д. Соединительные элементы могут использоваться для преобразования данных между различными каталогами, отчасти независимо (например, А в Б, Б в А и В ). Как правило, сами они не используют постоянное хранилище данных, полагаясь на хранилища данных каталогов, к которым они подключаются для создания "виртуального" каталога. Подобный виртуальный каталог может предоставлять службу LDAP, которая осуществляет доступ к данным из множества каталогов в целях получения способности отвечать на запросы LDAP. Однако сам он может ничего не хранить в базе данных. Каждый запрос требует подключения и поиска по отношению к существующим базам данных-источникам, а метакаталог для ответа на исходный запрос LDAP выполняет объеди нение собранных данных "на лету".

Как показано на рис. 8.12, атрибут Dept изменен в базе данных 3 с применением данных из базы данных 1, а атрибут Mail добавлен в базу данных 2 по информации из базы данных 3. Это простой пример синхронизации данных между различными каталогами, выполняемой метакаталогом.

Центральный каталог принимает данные от различных существующих второстепенных каталогов и может предоставлять объединенные данные обратно различным второстепенным каталогам. Как и метакаталог, он требует наличия соединительных элементов с разнообразными каталогами-"спицами" для чтения и записи данных. В отличие от метакаталога он предусматривает свое собственное хранилище, а преобразование данных всегда определяется исходя из атрибутов, сохраненных в центральном каталоге (например, A в Д, Б в Д, В в Д ). Объединение данных выполняется как часть постоянной синхронизации с каталогами-"спицами", а сохраняются уже объединенные данные.

Как показано на рис. 8.13, центральный основной каталог выполняет функцию группирования всех атрибутов и сохранения их в "основной записи" (master record). Нанесенные стрелки отображают поток данных, идущий от каталогов-источников (базы данных 1, 2 и 3) к центральному основному каталогу. Обратите внимание на то, что атрибуты CN и EmpID используются в качестве ключей корреляции для данных, предоставляемых из баз данных 1 и 2. Это типичный сценарий, когда основной каталог группирует "подачи" от всех других второстепенных каталогов (каталогов"спиц"). Хотя это и не отображено на схеме, обратите внимание на то, что существует также возможность помещать атрибуты, которые сохранены в центральном основном каталоге и пришли от одного второстепенного каталога, из основного каталога в другой второстепенный каталог. Для этой архитектуры типично, что между второстепенными каталогами совместно используется ограниченное количество атрибутов. При изменении атрибутов во второстепенных каталогах чрезвычайно важно отслеживать авторитетный источник для каждого из атрибутов. Центральный каталог, как правило, не строго осуществляет эти изменения в авторитетных источниках. Как результат, надо быть внимательным при разрешении приема идентичного атрибута (отличного от ключей корреляции) из второстепенных каталогов.

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

Центральные каталоги имеют преимущество, состоящее в способности немедленно предоставлять объединенные данные. Однако частота синхронизации с каталогами"спицами" (источниками) может ограничивать точность предоставленных данных. Такие каталоги могут также требовать серьезного сервера и ресурсов для хранения данных.

Альтернативным подходом является комбинация двух стратегий. Комбинированный подход, как показано на рис. 8.14, использует метакаталог для выполнения гибкого объединения данных из различных каталогов-источников, а также центральный каталог-хранилище как долговременное хранилище объединенных данных для использования приложениями, требующими службы каталогов. При этом гибридном подходе центральный каталог является приемником данных и обычно не позволяет производить прямые изменения, но представляется как нечто большее, чем служба LDAP с ее возможностями только чтения. Единственной областью, когда может быть необходимо разрешение на прямые изменения, вероятно, будут случаи изменения паролей пользователей, так как они не могут быть синхронизированы (дополнительную информацию относительно проблем с паролями и их синхронизацией см. в разделе "Синхронизация паролей"). При наличии каталога LDAP, который содержит объединенные данные, можно избежать проблем с запаздывани ем данных, вызываемых виртуальным динамическим объединением данных.

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

В этом примере наш основной каталог LDAP содержит все сгруппированные атрибуты. Данный пример также иллюстрирует, как применялась синхронизация каталогов между базой данных 3 и нашим основным каталогом LDAP. В этом случае база данных 3 представляет каталог Domino и в целях использования каталога LDAP для управления доступом к Domino мы синхронизировали иерархическое имя Notes с основным каталогом LDAP. Также настало время указать, что синхронизация на рис. 8.14 может быть выполнена при использовании трех сборочных конвейеров, сконфигурированных в интеграторе каталогов IBM Tivoli Directory Integrator, а основной каталог LDAP может быть реализован с помощью IBM Directory Server.

Определение схемы

Схема каталога имеет три главных компонента. Ими являются:

Хотя DIT технически и не является частью "схемы", структура иерархического дерева имеет прямое отношение к каждому отличительному имени ( DN ) объекта. DN является полностью уточненным иерархическим именем. Напримеру, DN может быть "CN=john q public,OU=sales,O=acme,C=us" или другой типичной формой "UID=jsmith4 ,CN=users,DC=acme,DC=com". В первом примере дерево следует более традиционной структуре X.500, со страной "C=US" в качестве корня. Второй пример отображает корень, который следует соглашениям по именованию DNS с доменными компонентами "DC=acme, DC=com" в качестве корня. Отличительные имена должны быть уникальными, поэтому "плоские" деревья предписывают использование уникальных идентификаторов, таких, как во втором примере, когда вместо DN (общего имени) используется идентификатор пользователя UID (User ID). Как правило, наш опыт говорит о том, что плоские деревья, несмотря на связанные с необходимостью наличия методов генерирования уникальных идентификаторов или имен накладные расходы, в конечном счете более просты в администрировании. Но в больших организациях (более 10 000 пользователей) присутствует компромисс в этом плане. Структура плоского дерева в большой организации требует наличия неинтуитивной схемы именования пользователей, которая зачастую вынуждает употреблять дополнительные идентификационные атрибуты. Например, рассмотрим существование двух уникальных пользователей:

DN= uid=bhinkle,cn=users,dc=acme,dc=com
cn=Brendan C Hinkle
mail=b_c_hinkle@acme.com
DN= uid=bhinkle2,cn=users,dc=acme,dc=com
cn=Bill Hinkle
mail=b_hinkle@acme.com

Обратите внимание на то, что из элементов примера трудно или даже невозможно определить, какого пользователя мы намереваемся выбрать на основе DN. Нашим приложениям, таким, как электронная почта, необходимо нести дополнительные непроизводительные издержки по выборке атрибутов для элемента в дополнение к DN, чтобы пользователь или приложение смогли установить соответствующий элемент. В приведенном примере общее имя может позволить нам отличить человека, которого мы хотим выбрать. Но в больших организациях с большой долей вероятности будут существовать идентичные или подобные общие имена. Таким образом, далее, возможно, будет необходимо также запрашивать другой атрибут, такой, как департамент или место работы. Значит, если мы пересмотрим дерево с целью сделать его "более высоким" (или менее "плоским"), мы легко сможем создать отличительные имена, которые предоставляют более гранулированную информацию об элементах без необходимости доступа к дополнительным атрибутам:

DN= uid=bhinkle,ou=sales,dc=acme,dc=com
mail=b_c_hinkle@acme.com
DN= uid=bhinkle2,ou=hr,dc=acme,dc=com
mail=b_hinkle@acme.com

Использование ветви OU либо ветви DC под корнем обычно рекомендуется в меньших организациях (до 10 000 элементов) только в тех случаях, если администрирование пользователей распределено. Так рекомендуется, потому что элементы управления доступом проще реализовать на уровне узла ветви, чем на уровне каждого индивидуального листового (пользовательского) узла. Какой корень лучше – традиционный корень страны X.500 или корень компонента домена DNS, – является предметом спора. Учитывая, что интернациональная служба X.500 никогда не рассматривалась на предмет общего соединения корней стран унифицированным образом, доменная структура стала более популярным подходом. Теоретически использование компонентов домена DNS может в конечном счете поддерживать способность к получению чьих-либо открытых сертификатов X.500 для отправки зашифрованных SMIME-сообщений. Но мы чувствуем, что этого не случится в реальности на протяжении еще как минимум 3–5 лет, если случится вообще. Наш опыт свидетельству ет о том, что коммерческие организации вряд ли когда-либо предоставят свободно доступную службу каталогов для своих внутренних пользователей. Беспокойства по поводу неправильного применения, такого, как почтовый "спам", несомненно, в этом случае оправданны. Но при повсеместности распространения DNS как наиболее пригодный вариант мы можем рекомендовать использование DIT компонентов домена для тех организаций, которые рассматривают вопрос новой реализации LDAP.

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

Ключевые элементы при рассмотрении вопроса проектирования вашего DIT должны включать:

Итак, что же можно сказать насчет ваших уже существующих каталогов, которые не являются каталогами LDAP? Помните о том, что очень немногие LDAP-каталоги основаны на X.500 или Open LDAP. Несмотря на то что важно быть способными к определению схемы в стандартных показателях LDAP, еще более важно определить схему в показателях, специфичных для заданного каталога. Хотя LDAP предусматривает стандартные классы объектов и имена полей атрибутов, большинство LDAP-каталогов применяют различные внутренние имена полей для атрибутов данных пользователей. Некоторые программные продукты разрешают преобразование своих собственных атрибутов в атрибуты LDAP с целью настройки, в то время как в других преобразование невозможно. При первых попытках установить связь собственного атрибута с его именем поля атрибута LDAP имена атрибутов LDAP становятся универсальным языком, с которым могут проводить сравнение все каталоги.

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

Для тех организаций, которые только начали формулировать корпоративную стратегию каталогов, мы предлагаем прочесть некоторые из работ, выполненных образовательным сообществом как часть проектов каталогов комитета Middleware Architecture Committee for Education (MACE). Этот материал доступен по адресу:

http://middleware.internet2.edu/dir/

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

За отличной, полной дополнительной информацией относительно корпоративной стратегии каталогов, ее планирования и разработки обратитесь к следующему источнику:

Charles Carrington (Editor), Timothy Speed, Juanita Ellis, and Steffano Korper, Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization.

8.4.1 Предоставление учетных записей

Интеграция и синхронизация каталогов могут быть использованы для поддержки предоставления учетных записей. Предоставление учетной записи (account provisioning) с точки зрения каталогов означает, что для заданного пользователя неким автоматическим способом могут быть разрешены различные службы системы. Путем автоматического предоставления учетных записей общим приложениям могут быть радикально сокращены требуемые административные ресурсы.

В целях поддержки такого автоматического предоставления интеграция каталогов должна поддерживать несколько требуемых функций.

Служба

Служба (service) является логическим набором функций, типично предоставляемых отдельным приложением, или набором интегрированных приложений. В интересах предоставления учетных записей служба является синонимом приложения. Примером служит электронная почта Notes.

Учетная запись

Учетная запись (account) является определенными службой деталями о пользователе и заданными службой ресурсами. Например, адрес электронной почты с соответствующим почтовым ящиком для приема сообщений могут быть определенными пользователю ресурсами, требуемыми службой электронной почты. Службе может понадобиться распознать предопределенный мандат (credential) пользователя для доступа к службе, ей может понадобиться определить элементы управления доступом к службе для разрешения пользователям отправлять или принимать сообщения в своих почтовых ящиках, и к тому же не допустить доступа к своим почтовым ящикам со стороны других пользователей службы электронной почты. Взаимосвязь между аутентификацией и управлением доступом с точки зрения учетной записи заключается в следующем:

Учетная запись необходима, потому что специфические для пользователя данные должны быть сохранены в приложении. Типы данных, которые мы рассматриваем как часть учетной записи, не сохраняются в службе Enterprise Directory. Примерами являются почтовые ящики электронной почты, папки favorites, предпочтения или опции пользователя для заданного приложения. Мы можем хранить местоположение почтового ящика пользователя в каталоге, но сам почтовый ящик и его содержимое сохраняются в приложении.

Регистрация

Регистрация (registration) является актом или процессом подписки определенного пользователя на сервис. Пользователь может самостоятельно осуществить регистрацию идентификаторов ID, подписок и т. д. В качестве альтернативы от лица пользователя подписаться на службы (сервисы) могут администратор или руководство пользователя. Третьим типом регистрации может быть автоматическая регистрация или регистрация на основе ролей, когда роли являются функциональными, зависящими от уровня работы, названия должности, корпоративной иерархии и т. д. Требуемые службой параметры (детали учетной записи) должны быть предусмотрены участвующей стороной или агентом, выполняющим регистрацию, хотя некоторые параметры могут быть сгенерированы алгоритмически на основе атрибутов каталогов.

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

Предоставление прав

Предоставление прав (entitlement) является актом предоставления пользователю с определенным набором мандатов доступа к информации или функциям. Как правило, пользователю должно быть предоставлено право применения службы перед тем, как может быть настроена учетная запись на службу. В качестве альтернативы, учетная запись может быть настроена без каких-либо прав доступа в ожидании предоставления прав, хотя результатом такой последовательности может быть резервирование ресурсов, которые затем никогда не будут использованы, и возможная потребность в некоторых действиях по очистке для освобождения неиспользуемых ресурсов.

Автоматическое предоставление учетных записей

Несмотря на то что существует возможность выполнять автоматическое предоставление без центрального основного каталога, оно будет ограничено до определенных событийно-управляемых процессов. Например, добавление в кадровую систему нового служащего может привести к автоматической настройке учетной записи электронной почты в Domino, если используется такой инструмент, как интегратор каталогов (Directory Integrator). Этот тип событийно-управляемого предоставления учетной записи может быстро стать трудноразрешимым, если предоставление прав для учетной записи определяется множеством факторов, таких, как название должности, отдел, место работы и т. д. Например, если служащим с определенным названием должности или уровнем работы автоматически дается учетная запись службы мгновенного обмена сообщениями (Instant Messaging), это может быть автоматизировано. Но это не предусматривает средства для допущения исключений, здесь нет способа внесения изменений в политики предоставления прав для изменения существующих пользователей. Другими словами, для существующего пользователя нет "события" до тех пор, пока для этого пользователя не будут внесены некоторые изменения в каталог-источник.

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

8.4.2 Элементы управления доступом организации

Обзор унифицированных каталогов не будет полным без упоминания о появившемся классе систем, которые позволяют объединить управление идентификаторами личностей и централизованные элементы управления доступом. В целях потенциального включения всех приложений организации, разработанных различными производителями, требуются специализированные системы обеспечения безопасности, которые управляют идентификаторами личностей и элементами управления доступом. Полная стратегия принципа единственной регистрации (SSO) типично включает системы управления идентификаторами личностей, объединенные системы каталогов и развитые политики и процедуры, которые централизованно осуществляются и управляются. Системы обеспечения безопасности, которые предоставляют "центральную точку" по управлению идентификаторами личностей и элементами управления доступом для неравноправных внутренних систем, упоминаются обычно как "системы управления доступом организации" (enterprise access management systems). Примерами таки х систем являются IBM Tivoli Access Manager и Netegrity Siteminder. Организации, которые занимаются реализациями системы управления доступомобычно имеют следующие характеристики:

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

Подробный обзор IBM Tivoli Access Manager представлен в документе компании IBM Tivoli Access Manager for e-business, REDP3677.

8.5 Краткие выводы

Множество каталогов сегодня является проблемой для многих организаций. Непостоянство данных в каталогах вызвано наличием множества точек управления одними и теми же или подобными личными данными. Объединение точек управления требует либо тактического решения, такого, как синхронизация данных, или стратегического решения, такого, как объединение данных в службу каталогов организации.

Множество идентификаторов личностей пользователей представляют величайшую проблему для возможности разработки архитектуры обеспечения принципа единого входа [single sign-on (SSO)]. Так как невозможно потребовать миграции всех существующих приложений для использования отдельного общего каталога, то для обеспечения способности преобразования одних идентификаторов пользователей в известные для различных каталогов требуется проведение синхронизации каталогов.

Ключом к успешной синхронизации каталогов является исчерпывающее и точное определение потоков данных. При подходе к синхронизации на уровне потоков данных вы уменьшаете сложность. Это предоставляет вам выгоды во всем: в скорости ввода в действие, точности решения, надежности и удобстве сопровождения.

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

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

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

В дополнение к упомянутым ранее основным преимуществам реализация центрального (корпоративного) основного каталога может предоставлять следующие дополнительные преимущества: