Стратегии каталогов
Преобразование идентификатора личности
В предыдущем примере мы имели три различных элемента каталога для одного и того же человека. Теперь рассмотрим, что мы должны сделать для преобразования идентификатора личности ( 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Пример 8.2. Элементы каталогов
В этом примере, если именем 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Пример 8.3. Элементы каталогов
В этом примере, когда сервер 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-формате по адресу: