Принцип единого входа (Single sign-on)

7.4.1 Аутентификация

DSAPI обеспечивает достаточную гибкость для аутентификации Web-пользователя Domino с применением практически любого критерия. Такой критерий может основываться на сравнении имени и пароля в Domino или во внешнем каталоге LDAP, на сравнении представленного в cookie имени или на каком-либо другом механизме. Вместе с большой гибкостью присутствуют и издержки, связанные с обеспечением безопасности используемого механизма. Решать проблему таких издержек приходится разработчику DSAPI. Другая потенциальная проблема и издержки связаны с производительностью. К примеру, если DSAPI требуется соединение с каталогом из внешней области, то время поиска может чрезмерно влиять на производительность. Разработчик может либо предпочесть проверку кеша пользователя, либо игнорировать кеш и производить внешний поиск при каждом случае доступа.

7.4.2 Управление доступом

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

Разработчик способен предоставить полный контроль относительно того, как пользовательское имя может преобразовываться или ставиться в соответствие другому имени посредством установки "authname" в любое желаемое значение и формат. См. описанный ранее сценарий 1 для события kFilterAuthUser.

7.5 Заголовки HTTP

Для ID пользователей и паролей Domino 6 поддерживает заголовки HTTP, что позволяет вам применять сторонний Web-сервер в качестве входного для сервера Domino. Это свойство часто описывается как WebSphere Application Server plug-in (Плагин сервера приложений WebSphere) для Domino, что является отчасти дезориентирующим названием, так как это не то же самое, что и плагин (plug-in) аутентификации или Перехватчик доверительных связей [Trust Association Interceptor (TAI)] сервера приложений WebSphere, и также это не включает в себя плагин Domino, так как это только параметр файла notes.ini, который сообщает HTTP Domino о приеме в заголовках HTTP ID пользователей и паролей, относящихся по стилю к серверу приложений WebSphere. Реальный плагин для поддержки этой архитектуры SSO установлен на входном HTTP-сервере. Плагины для входных HTTP-серверов, которые совместимы с внутренними серверами Domino, доступны для Microsoft IIS и IBM HTTP Server, а в будущих редакциях Domino 6 планируется поддержка таких плагинов для Apache и iPlanet.

В целях поддержания принципа единого входа с применением заголовков HTTP на внутреннем сервере Domino, добавьте в файл NOTES.INI следующую строку:

HTTPEnableConnectorHeaders=1

Этот параметр позволяет задаче HTTP Domino обрабатывать специальные заголовки, добавленные к запросам плагином сервера приложений WebSphere для IIS или для IBM HTTP Server. Такие заголовки включают информацию о конфигурации входного сервера и о статусе аутентификации пользователей.

В качестве меры безопасности задача HTTP Domino игнорирует эти заголовки в том случае, если параметр файла NOTES.INI не разрешен. Это предотвращает имитацию плагина со стороны атакующего.

Необходимо понимать, что при использовании этой архитектуры для обеспечения безопасности канала между входным HTTP-сервером и сервером Domino должны быть использованы брандмауэры и ограничения по портам; в противном случае сервер Domino подвергается риску, потому что заголовки HTTP могут легко быть подделаны. Другими словами, обеспечьте безопасность канала "HTTP-сервер – HTTP Domino" таким образом, чтобы только HTTP-серверу было разрешено подключаться к порту Domino 80/443. Целостность этой архитектуры SSO полностью зависит от безопасности канала между производящим аутентификацию входным HTTP-сервером и сервером Domino.

7.5.1 Аутентификация

При использовании поддержки плагина заголовков HTTP в Domino, последний возлагает обязанности по проведению аутентификации всех пользователей на входной HTTP-сервер.

7.5.2 Управление доступом

Элементы управления доступом Domino при использовании для аутентификации заголовков HTTP зависимы от имен пользователей, предоставленных плагином на внешнем Web-сервере. Списки управления доступом (ACL) баз данных Domino по-прежнему используются для определения того, должен ли быть предоставлен пользователю доступ к заданному ресурсу. Так как аутентифицированное имя пользователя в заголовке обычно не является иерархическим именем Notes пользователя, то списки управления доступом баз данных должны содержать элементы, которые соответствуют предполагаемой форме имени пользователя в заголовке. Общим подходом при решении этой проблемы является разрешение анонимного доступа к базам данных Domino и доверие аутентификации и элементам управления доступом входного сервера, которые определены в его реестре безопасности для URL-адресов Domino.

Главным недостатком этого подхода является невозможность реализации элементов управления доступом на уровне документов, таких, как осуществление доступа к документам с правами читателя (reader) или автора (writer). Аналогично не могут быть использованы элементы управления доступом на уровне полей, такие, как формулы hide when (скрыть когда) в форме Domino, которые используют принадлежность к группам или роли групп. Так как документы Domino получают сгенерированные идентификаторы (ID документов и UNID), то непрактично пытаться осуществлять доступ и управлять им с применением URL-адресов.

Для преобразования имени пользователя из заголовка HTTP в иерархическое имя Notes может быть реализовано преобразование имен Notes. Так как обычно иерархическое имя Notes – это то, что применяется в ACL базы данных Domino, то для этого могут быть использованы списки управления доступом (ACL) Domino, обеспечивая тем самым соответствие требуемым для поддержки преобразования имен условиям. Дополнительную информацию относительно того, как Domino может преобразовывать имя из внешнего каталога LDAP в иерархическое имя Notes, можно найти в разделе 11.9.4, "Преобразование имен в Domino".

7.6 Сценарий единого входа (принципа единственной подписи)

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

При базовом сценарии SSO, который мы здесь описываем, существует объединенная инфраструктура на основе Domino, составленная из Lotus Domino и Lotus Sametime, в зависимости от которой организация принимает решение о реализации среды портала WebSphere. Для обеспечения общей связки технологий выбирается вариант SSO с применением LTPA, после чего он подлежит реализации в целях предоставления непрерывного взаимодействия с пользователями.

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

Рис. 7.3. Взаимодействие браузера и портала при использовании SSO с применением LTPA

На шаге "1-Аутентификация" пользователь осуществляет запрос портала и предоставляет набор полномочий аутентификации (мандат). После этого сервер портала проверяет мандат (2) и при условии успешной аутентификации (3) создает маркер LTPA. Затем этот маркер LTPA не только передается обратно браузеру клиента (4), но и размещается в службе мандатов портала (5).

Далее для демонстрации того, как этот "кешированный" маркер LTPA может быть использован порталом, мы рассмотрим операции взаимодействия системы, представленные на рис. 7.4.

увеличить изображение
Рис. 7.4. Взаимодействие портала и Domino при использовании SSO с применением LTPA

В этом наборе операций взаимодействия клиент в лице браузера запрашивает портлет Domino с сервера портала (1). Сервер портала знает, что для получения данных для портлета он должен осуществить доступ к Domino от имени пользователя, и поэтому он обращается к серверу мандатов и осуществляет выборку маркера LTPA, который был кеширован для пользователя по исходному регистрационному имени (2 & 3). После этого портал отправляет Domino запрос с маркером LTPA (4). При доверии со стороны Domino маркеру LTPA производится проверка по ACL для запрашиваемого ресурса на основе имени пользователя из маркера LTPA (5). При условии, что пользователь авторизован, Domino отправит данные назад серверу портала (6), который затем предоставляет их обратно пользователю как часть изначально запрошенного портлета.

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

Наконец, на рис. 7.5 мы имеем одну финальную схему для демонстрации взаимодействия в рамках SSO с применением LTPA. В данном случае использующий браузер пользователь запрашивает портлет Web-конференции Sametime (1). Снова сервер портала знает, что для получения списка встреч (meeting) для портлета он должен осуществить доступ к Sametime от имени пользователя, и поэтому он обращается к серверу мандатов и осуществляет выборку маркера LTPA, который был кеширован для пользователя по исходному регистрационному имени (2 & 3). После этого портал отправляет Sametime запрос с маркером LTPA (4). При доверии Sametime маркеру LTPA производится проверка по ACL для списка встреч на основе имени пользователя из маркера LTPA (5). При условии, что пользователь авторизован, Sametime отправит данные назад серверу портала (6), который затем предоставляет данные обратно пользователю как часть изначально запрошенного портлета Web-конференции (7).

увеличить изображение
Рис. 7.5. Взаимодействие браузера, портала и Sametime при использовании SSO с применением LTPA

При условии, что после этого пользователь изъявит желание присутствовать на встрече, браузер начнет непосредственно взаимодействовать с сервером Sametime (8), который может запросить у пользователя браузера его мандат (9). После этого браузер ответит предоставлением маркера LTPA из своего кеша (10) и начнется установка встречи (11).

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

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

Мы обсудили четыре основных метода для поддержки SSO в случае применения объединенных технологий Lotus на базе Lotus Domino. Эти методы различаются в плане проблем обеспечения безопасности и сложности проектирования.

LTPA имеет преимущество, выражающееся в поддержке со стороны практически всех программных продуктов IBM Lotus, WebSphere и Tivoli Access Manager. Этот метод является зависимым от общего, доверенного каталога, используемого в интересах мандатов пользователей. Возможность поддержки каталогов Domino (Domino's Directory Assistance) обеспечивает поддержку использования мандатов, сохраненных за пределами каталога Domino.

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

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

Заголовки HTTP имеют преимущество, выражающееся в относительной легкости реализации; однако они приносят высокую степень риска для безопасности, если канал между входным HTTP-сервером и внутренним сервером Domino является не полностью безопасным. В большинстве случаев они реализуются в связке с системой управления доступом организации (Enterprise Access Management), которая централизованно управляет всем доступом к Web-ресурсам.

Наконец, при принятии решения относительно выбора одного или другого метода SSO пользователь должен рассмотреть, возможно ли будет:

1. Попытаться произвести объединение с существующим решением SSO, либо построенным по техническим условиям заказчика, либо не являющимся решением от компании IBM. Весьма правдоподобно, что в этом случае отвечать всем требованиям будут решения либо на основе DSAPI, либо на основе заголовков HTTP.
2. Попытаться реализовать "специфическое для приложения" решение SSO либо произвести объединение с другими существующими приложениями от компании IBM. В этом случае наибольшим смыслом будет обладать применение решения на основе LTPA.
3. Попытаться реализовать общее для всей организации решение SSO, покрывающее все системы и инфраструктуры. В этом случае правильным направлением может быть использование решения по управлению доступом в организации как части общего решения по управлению подлинностью. Для удовлетворения этих потребностей должно быть внимательно проанализировано и принято во внимание семейство программных продуктов "управления подлинностью (identity management)" Tivoli от компании IBM.