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

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

Управление доступом с использованием LTPA основано на содержащемся внутри маркера имени пользователя. Это имя будет отличительным именем [distinguished name (DN)] из каталога LDAP, применяемым в мандате пользователя. Если DN в маркере не соответствует элементу управления доступом [к примеру, элементу таблицы управления доступом (ACL) базы данных Domino], то, если была подтверждена достоверность маркера LTPA, пользователь рассматривается как авторизованный, но он не будет иметь доступа к запрашиваемому ресурсу.

Domino 6, а именно 6.0.2 и выше, обеспечивает чрезвычайно полезные возможности, которые позволяют устанавливать соответствие между содержащимся в маркере LTPA отличительным именем (DN) и другим именем в интересах управления доступом (осуществлять их преобразование). Сам по себе маркер LTPA не изменяется (не генерируется повторно), но аутентифицированное имя пользователя преобразовывается из отличительного имени LDAP в другое отличительное имя (DN), такое, как стандартное имя каталога Domino. Это преобразование имен происходит каждый раз, когда сервер Domino получает HTTP-запрос, в котором присутствует маркер LTPA. В связи с этим могут возникнуть некоторые непроизводительные издержки в работе сервера, вытекающие из выполнения дополнительного поиска имен. В целях ограничения до минимума потенциального количества требуемых поисков имен LDAP Domino проверяет внутренний кеш пользователя, и поэтому для уменьшения потенциального воздействия на производительность может использоваться настройка размера кеша пользователя. Мы говорим о потенциальном воздействии, так как авторы данного курса не выполняли испытаний "под нагрузкой" в целях измерения действительного влияния этого явления на производительность сервера.

Дополнительная информация о функциях преобразования различных имен в Domino описана в разделе 11.9.4, "Преобразование имен в Domino".

В дополнение к возможностям преобразования имен в Domino Tivoli WebSeal в связке с Tivoli Access Manager могут предоставлять функции преобразования имен на базе ресурса, к которому пользователь осуществляет попытку доступа.

7.2.3 Решение связанных с LTPA проблем

Если при конфигурировании инфраструктуры LTPA возникают проблемы, должны быть тщательно проанализированы значения различных параметров, связанных с LDAP. При использовании Lotus-технологий неправильная установка параметров "search filters" и "base dn" является причиной не менее 75 % связанных с LDAP-аутентификацией проблем.

Фактически для изменения связанных с аутентификацией фильтров поиска (search filters) существует множество мест, и все из них должны быть проверены тщательным образом:

• фильтры поиска Domino Directory Assistance;
• фильтры поиска Sametime;
• фильтры поиска QuickPlace;
• фильтры поиска "global security" ("глобальной безопасности") WebSphere Application Server.

Пример фильтра поиска Sametime показан на рис. 7.1.

Рис. 7.1. Фильтр поиска LDAP Sametime

Устранение связанных с LTPA проблем в Domino

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

В NOTES.INI существует отладочная переменная, которая доступна в целях содействия в отыскании проблем с шифрованием и расшифровкой маркеров единственной подписи (Single Sign-On). Для получения информации о том, как извлекается Web SSO Configuration, а также о том, как шифруются и расшифровываются маркеры, установите DEBUG_SSO_TRACE_LEVEL=1. Для получения подробных дампов памяти, содержащих информацию о том, как шифруются и расшифровываются маркеры, установите DEBUG_ SSO_TRACE_LEVEL=2.

Примечание. Domino 6 может иметь различные конфигурации SSO для разных служб (Web, POP и т. д.), даже на одном и том же сервере, использующем интернет-сайты. Однако, конфигурируя SSO в смешанной среде Domino 5/6, вы можете столкнуться с проблемами, так как версия 5 не распознает документы Internet Site. Хорошо, что Domino 6 все еще поддерживает "R5 Web config", и поэтому вы можете разрешить использование SSO в среде с различными версиями. Два метода конфигурации SSO на сервере Domino 6 взаимно исключают друг друга, и поэтому для смешанных сред вам надо выполнять только Web-конфигурацию версии 5. Не используйте документы Internet Site. Важными моментами здесь являются следующие:

1. Убедитесь в том, что для серверов Domino 6 на закладке Basics документа сервера запрещены (Disabled) интернет-сайты.
   

   
   
2. Создайте документ конфигурации SSO, используя клиент администратора Domino и открыв один из документов сервера. В строке меню выберите пункт "Create Web (R5)…" [Создать Web (R5)..] и далее SSO Configuration (Конфигурация SSO), назовите документ LTPAToken.
   

   
   
3. Не используйте название организации (Organization name) в документе конфигурации Web SSO (это поле применяется только для поддержки интернет-сайтов). Если вы укажете это название, документ SSO не будет виден с закладки интернет-протокола сервера.
   

   
   

7.3 Сертификаты X.509

Аутентификация клиента с использованием сертификатов X.509 предусматривает двустороннюю аутентификацию между пользователем браузера и сервером с применением для аутентификации пользователя как SSL, так и каталога LDAP. Множество приложений, совместно применяющих данный, одинаковый для них каталог LDAP, могут использовать одинаковую аутентификацию с применением сертификата. Это не одно и то же с использованием сертификата сервера для аутентификации сервера со стороны клиента, где клиенту просто необходимо доверять корневому центру сертификации (CA), который выпустил сертификат сервера. Мы сфокусируем внимание на выполняемой сервером аутентификации клиента.

Как правило, сертификат X.509 клиента защищен паролем, поэтому в данном случае использование сертификатов X.509 рассматривается как двухфакторный метод аутентификации: что-то у вас есть (сертификат на рабочей станции), а что-то вы знаете (пароль). Так как сертификаты могут также быть проверены, проконтролированы на предмет аннулирования и истечения срока действия, то сертификаты X.509 могут быть очень безопасным методом аутентификации пользователей. Однако в связи с тем, что сертификат X.509 сделан переносимым (или экспортируемым) и он может быть установлен в другие приложения или на другие рабочие станции, появляются как проблемы логистики для пользователя, так и потенциальные уязвимости в безопасности. Достоин упоминания тот факт, что Internet Explorer хранит сертификаты X.509 клиента в реестре Windows. Полное удаление сертификата с рабочей станции может потребовать ручного удаления его из реестра. Только недавно получили толчок в своем развитии смарт-карты как средства, обеспечивающие как переносимость, так и безопасность в хранении сертификатов клиента, причем несмотря на то, что недостаток, связанный с отсутствием повсеместного использования устройств считывания смарт-карт в персональных компьютерах, определенно затрудняет их широкое использование.

При аутентификации клиента клиент LDAP, а именно браузер, установленный на рабочей станции клиента, должен иметь цифровой сертификат (на основе стандарта X.509). Другими словами, сертификат X.509 содержит мандат пользователя и передается различным Web-серверам, которые требуют одинаковой аутентификации X.509. Каталогу LDAP необходимо иметь как корневой сертификат от соответствующего CA, который выпустил сертификат клиента, так и открытый SSL-сертификат клиента (ключ), который должен быть сохранен в соответствующей записи каталога. Этот цифровой сертификат используется для аутентификации клиента LDAP (браузера) по отношению к каталогу LDAP, применяемому для аутентификации. Таким образом, чтобы использовать сертификаты X.509, должна быть реализована инфраструктура интернет-сертификатов (PKI), в которой пользователи могут получать сертификаты X.509, являющиеся доверенными по отношению к службе каталога LDAP (серверу), а открытые сертификаты пользователей (ключи) хранятся в каталоге.

В дополнение к SSL-аутентификации клиентов Web-браузеров для добавления к протоколам на основе соединений поддержки аутентификации на базе сертификатов X.509 может использоваться протокол SASL (Simple Authentication and Security Layer). Данный протокол содержит команду для идентификации и аутентификации пользователя по отношению к серверу. По выбору он может согласовывать уровень безопасности для последующего взаимодействия в рамках протокола. Если более точно, то существует как минимум семь различных типов поддерживаемой SASL аутентификации, но лишь тип аутентификации SASL "External" (Внешняя) использует сертификаты X.509. Спецификации SASL описаны в RFC-2222, который можно найти на адресу:

http://www.ietf.org/rfc/rfc2222.txt

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