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

Процесс связывания

Для понимания проблемы паролей и факта хранения хешированного значения пароля в "безопасных" каталогах, вам необходимо понять процесс аутентификации. Когда пользователь предоставляет регистрационное имя ( ID ) и пароль, строка пароля хешируется и затем сравнивается с значением хеша сохраненного в каталоге. Хорошим примером этого процесса является bind -запрос протокола LDAP, при использовании LDAP для хранения ID и пароля ( credentials ). Если полученный после ввода имени и пароля пользователя хеш соответствует хеш, сохраненному в каталоге, считается что "связывание" ( "bind" ) прошло успешно. Несмотря на то, что некоторые каталоги хранят как исходный пароль, так и его хеш-значение, безопасные каталоги не подразумевают доступ к исходному паролю; вы можете получить доступ только к хеш.

Рассмотрим следующий пример.

Пароль пользователя состоит из строки символов "password" и сохранен в IBM Directory Server как хеш-значение "[B@7a8ea817". Что случится, если мы попытаемся синхронизировать это хеш-значение с документом Person пользователя в каталоге Domino? Хеш-значение, которое сгенерирует наш сервер Domino когда мы войдем (log in) ( bind ) с паролем "password", будет выглядеть как "355E98E7C7B59BD810ED845AD0FD2FC4". Так как это значение не идентично хеш-значению из каталога LDAP, с которым мы синхронизировались ( "[B@7a8ea817" ), аутентификация с Domino будет неудачной.

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

7.2 LTPA

Маркеры Lightweight Third Party Authentication (LTPA) компании IBM, или cookies, обеспечивают средства совместного использования информации аутентификации между Web-серверами приложений Lotus, WebSphere и Tivoli. Пользователь, который однажды уже был подвергнут аутентификации со стороны сервера приложений, будет автоматически аутентифицирован на других серверах приложений в том же домене DNS при предоставлении ключей LTPA, находящихся в совместном использовании у всех приложений. LTPA применяет маркер, который сохраняется как cookie в браузере пользователя.

Маркер LTPA содержит данные, которые уникально идентифицируют пользователя, такие, как отличительное имя [Distinguished Name (DN)] пользователя и датa истечения срока действия, которая фактически ограничивает время сеанса до значения, когда пользователь будет вынужден повторно пройти аутентификацию.

Особые примечания относительно использования LTPA включают:

• Все серверы приложений, использующие маркеры LTPA, должны находиться в одном и том же домене DNS.
• Все серверы приложений должны совместно использовать один и тот же реестр пользователей (каталог LDAP). Поддерживаемые каталоги включают Lotus Domino (сконфигурированный как каталог LDAP), IBM Directory Server, MS Active Directory и iPlanet.
• Браузеры, обеспечивающие доступ к серверам приложений, должны быть сконфигурированы на принятие cookies, которые используются для хранения содержащего информацию аутентификации маркера.
• Необязательно, но SSO может быть настроен на работу только по зашифрованным HTTPS-соединениям.
• LTPA является решением, разработанным компанией IBM; другие производители серверов приложений обеспечивают лишь ограниченную поддержку LTPA (или вообще ее отсутствие).

Условие относительно того, что все серверы приложений должны находиться в одном и том же домене DNS, не является ограничением, предъявляемым только LTPA. Маркер LTPA является cookie сеанса браузера, а свойства таких cookies определены в RFC-2965, который доступен по адресу:

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

Этот RFC устанавливает, что агент пользователя (браузер) не предоставит cookie серверу, находящемуся в домене DNS, отличном от того, в котором находится выпустивший (установивший) cookie хост (сервер). Существуют прокси-архитектуры, которые могут распространяться за пределы отдельного домена DNS, но рассмотрение подобных развитых архитектур выходит за рамки данного курса.

Для преодоления проблемы наличия множества доменов DNS существуют некоторые обходные маневры. Важным для понимания понятием является то, что домен или некая область из cookie сеанса LTPA используется только браузером клиента, но не серверами приложений. Таким образом, ключом для решения этой проблемы является использование псевдонимов DNS способом, при котором браузер отправляет cookie всем серверам, вовлеченным в доверенную среду LTPA, даже если реально они находятся в других доменах. К примеру, если ваши серверы Domino находятся в домене alpha.com, а вы имеете сервер портала в домене beta.com со страницей, на которой пользователи могут получать свою почту iNotes посредством iframe, то в Domino R5 вам необходимо сконфигурировать виртуальные серверы таким образом, чтобы они работали так, как если бы находились в домене beta.com. В Domino 6 для beta.com используйте документы Internet Site. В любом случае вам необходимо убедиться в том, что для серверов Domino в домене beta.com существуют записи псевдонимов DNS.

Для обеспечения поддержки принципа единого входа между протоколами, такими, как HTTP и DIIOP (а также с сервером приложений IBM WebSphere), Domino предусматривает криптографический механизм на основе маркеров. Серверы, которые участвуют в обеспечении принципа единого входа, применяют зашифрованную "Web-конфигурацию SSO" ( "Web SSO Configuration" ) для совместного использования секретных данных в каталоге Domino в целях генерирования и проверки достоверности маркеров единого входа. Эта секретная информация используется сервером для проверки того, что представленный пользователем маркер был сгенерирован сервером, который совместно использует тот же секрет. В оставшейся части этой лекции мы ограничимся рассмотрением маркеров LTPA в WebSphere.

WebSphere использует формат, называемый Lightweight Third Party Authentication (LTPA), который был реализован в Domino начиная с версии R5.0.5 и далее. Разрешение Domino взаимодействовать с WebSphere в вопросах обеспечения единого входа требует генерирования секретной информации в рамках административной среды WebSphere и последующего импортирования ее в Web-конфигурацию SSO (Web SSO Configuration). За дополнительной информацией о конфигурировании LTPA в WebSphere обратитесь к документации WebSphere.

Примечание. В среде, где WebSphere используется совместно с продуктами Lotus, или Tivoli, или обоими вместе, ключи LTPA должны генерироваться WebSphere и импортироваться в другие продукты. Когда взаимодействие с WebSphere не требуется, Domino использует для маркера единого входа свой собственный формат, который незначительно отличается от реализованного в WebSphere. Серверы, участвующие в Domino SSO, совместно используют 20-байтовый секрет, который применяется для генерирования и проверки достоверности хеша SHA-1, доказывающего целостность маркера. Эта версия LTPA "Domino server only" ("Только для серверов Domino") не взаимодействует с LTPA WebSphere.

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

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

1. Создание (шифрование) маркера LTPA первоначальным сервером, к которому подключается пользователь.
2. Опрос (расшифровка) маркера LTPA, предоставленного браузером в запросе HTTP к серверу.

Создание маркера LTPA (шифрование)

Пользователи подвергаются аутентификации один раз за время сеанса. Первоначальная аутентификация с использованием LTPA основана на имени и пароле, хранящихся в каталоге LDAP, когда каталогу доверяют все приложения, которые совместно используют cookie сеанса LTPA. Обратите внимание на то, что сервер каталога LDAP упоминается как "доверенная третья сторона (trusted third party)", отсюда и часть названия: "сторонняя аутентификация (аутентификация третьей стороной) (Third Party Authentication)". Когда пользователь предоставляет регистрационное имя ( ID ) и пароль первоначальному серверу в среде LTPA, тот предоставляет этот мандат пользователя в соответствующем запросе серверу каталога LDAP. Сервер каталога LDAP хеширует строку пароля, после чего она сравнивается с сохраненным хеш-значением пароля из записи пользователя в каталоге. Если полученный при регистрации пользователя хеш соответствует хешу, сохраненному в каталоге, то "связывание" считается успешным. При успеш ном связывании LDAP первоначальный Web-сервер (обычно сервер портала) сгенерирует маркер LTPA и предоставит этот cookie обратно браузеру. После этого браузер будет предоставлять этот cookie при каждом последующем HTTP-запросе пользователя к серверам, находящимся в указанном в cookie домене. Количество информации, содержащейся в cookie, минимально, отсюда термин "облегченная" (Lightweight). Структура маркера LTPA показана в табл. 7.1.

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