 | Уровень сложности: средний Джейн Маркус (Jane Marcus), старший инженер-программист,
IBM
Терри Уоррен, инженер-программист,
IBM
Эмми Е. Смит (Amy E. Smith), главный разработчик, IBM
20.04.2007 Узнайте о единой регистрации (Single Sign-on - SSO) в Notes/Domino от международного шпиона Джима Блэнда (Jim Bland). В этой первой статье серии из двух частей мы исследуем основы SSO и рассмотрим проблемы, возникающие в мире разных программ и каталогов.
Если вы считаете, что ваша рабочая среда трудна в управлении, представьте Джима Блэнда, секретного агента правительственной службы разведки (назовем ее, скажем, TSGA). Как и другие международные шпионы, Джим работает в быстро меняющемся мире, в котором информация является наиболее ценой валютой. Однако, в отличие от своих более известных коллег, наш Джим (номер жетона 013) должен сражаться, опираясь на поддержку более традиционной рабочей среды, включающей перегруженный работой и недофинансируемый отдел информационных технологий; кроме того, как и большинство из нас, Блэнд должен обеспечить максимальный результат с минимальными затратами.
Джим Блэнд шпион, получающий только внутригосударственные задания. В данное время он осуществляет наблюдение за "шишками", наживающимися на таинственном исчезновении просроченных билетов за парковку. Совершенно секретные файлы последней миссии Блэнда скрыты в защищенной области хранилища (в данное время в общей комнате отдыха в торговом центре), и Блэнд должен доказать свою подлинность, чтобы получить доступ к файлам. Блэнд идет к стене дальней кабинки и кладет руку на полированную плитку. На самом деле, это сканер, считывающий отпечатки его пальцев. Естественно, Блэнда распознают, и голос произносит: "Личность подтверждена". Затем открывается дверь лифта, который может доставить его к месту хранения файлов, но возникает проблема: нет пола, на который можно стать! Вместо него Блэнд видит зияющую пустоту. Что делать? Прыгать? Спускаться по водосточной трубе? Естественно, наш находчивый шпион точно знает, что он должен делать: он идентифицирует себя еще раз, произнеся магические слова "Блэнд. Джим Блэнд". Неожиданно появляется мостик, предлагая Блэнду безопасный путь, и он покидает лифт, слыша подтверждающий его личность голос: "Доступ агенту 013 разрешен". Блэнд может теперь делать свое дело - пусть не спасать мир от беды, но определенно противостоять жульничеству с парковкой. Однако эта процедура была утомительной, и мы уверены, что Блэнд думает про себя, почему единая регистрация опять не сработала?
Единая регистрация (single sign-on, или SSO), хотя и сложна в управлении, полностью предназначена для удобства пользователей, которые устают от повторяющихся запросов регистрационной информации (особенно при попытке выйти из общей комнаты отдыха). Те, кому поручено развернуть или обслуживать SSO-среду, найдут в данной статье некоторые советы и приемы по настройке комплексной среды для надежной работы с пользователями. Возможно, ваша среда имеет скрытые проходы, активизируемые голосом, но вероятнее всего она представляет собой обычную Web SSO-среду. Типичный сценарий: пользователь, у которого запрашивается имя пользователя и пароль, для того чтобы предоставить доступ к среде, содержащей такие компоненты IBM как WebSphere Portal и Domino. В данную среду могут также входить Lotus-портлеты, и она может предоставлять подключения к Sametime, Quickplace и почте Domino через Domino Web Access (DWA).
В этой серии из двух статей мы сконцентрируемся на среде Portal, имеющей дополнительную сложность из-за развертывания нескольких каталогов. Такие компоненты как DWA могут требовать наличия Domino Directory, а другие, например, Portal, могут быть развернуты с IBM Directory Server, Active Directory или любой другой службой каталогов, поддерживающей LDAP. В данной статье рассматривается работа SSO в средах с несколькими развернутыми службами каталогов; мы выделим проблемы, возникающими тогда, когда пользователи известны под несколькими именами.
Также как и в мире шпионажа, где агенты имеют несколько имен, очень часто имеют место SSO-сценарии, когда пользователи могут работать под несколькими именами. Имена являются критичными элементами в SSO-мире. Чтобы понять, почему это так, мы начнем первую часть этой серии статей с повторения основ SSO и рассмотрения того, как пользователи идентифицируются в нашей SSO-среде. Затем мы обсудим проблемы, возникающие в работе сайта с несколькими службами каталогов и несколькими системами регистрации.
Основы SSO
Обычно, говоря об SSO, мы имеем в виду работу Web-пользователя (взгляните на эту информацию, если интересуетесь SSO для регистрации в операционной системе). У нас есть пользователь, сидящий за Web-браузером, допустим, Джим Блэнд, который просматривает свой любимый URL разведывательного центра (http://spycentral.spies.com/fun). Хорошо спроектированная система SSO запросила бы у Блэнда его регистрационную информацию только один раз за сеанс работы. Когда Блэнд первый раз пытается обратиться по этому URL-адресу, он должен ввести свое имя пользователя jb013 и пароль LazyEye. Сервер Web-приложений разведывательного центра успешно удостоверяет пароль Блэнда и предоставляет ему доступ к URL. После регистрации Блэнд получает доступ к SSO-среде и может просматривать другие URL в этой среде без повторной регистрации (см. рисунок 1).
Рисунок 1. SSO-регистрация
На рисунке 1:
A. Блэнд просматривает свой любимый URL и получает запрос на ввод информации для регистрации. Сервер Web-приложений проверяет пароль Блэнда и разрешает доступ к URL. Блэнд теперь может идентифицироваться в SSO-среде.
B. Блэнд просматривает другой URL в SSO-среде и не должен повторять действия по регистрации.
Для реализации SSO необходимо, чтобы SSO-серверы и приложения распознавали пользователей после их регистрации. В Web-среде, в которой развернуты продукты IBM, магия, используемая за кулисами для реализации SSO, называется Lightweight Third Party Authentication (LTPA). Технология LTPA позволяет SSO-серверам идентифицировать пользователей после их регистрации. IBM поддерживает открытые стандарты, но поскольку нет де-факто широко используемого стандарта для SSO, IBM реализовала свою собственную SSO-технологию. LTPA может использоваться с различными продуктами IBM, а поскольку IBM предана открытым архитектурам, существуют точки подключения модулей для WebSphere и Domino, позволяющие внедрять SSO-приложения третьих фирм в LTPA-решение. Для того чтобы помочь вам понять LTPA-технологию, а также поддержать наше утверждение о том, что имена являются критичными элементами в SSO-мире, мы должны начать наш рассказ с обсуждения браузеров и куки.
Поддерживающая роль браузеров в защите SSO
Предположим, что Джим Блэнд вводит WebSphere URL в браузере, и ему отображается запрос на ввод имени пользователя и пароля для регистрации. Сервер приложений WebSphere проверяет идентичность Блэнда по введенному им паролю. Web-сервер может затем передать обратно содержимое Web-сайта, которое должно отобразиться в Web-браузере Блэнда. Web-пользователь работает как обычно: он вводит корректный пароль и начинает просматривать Web-сайт. В данном случае, и полностью за кулисами процесса, WebSphere посылает также куки, которые будут записаны браузером Блэнда (см. рисунок 2). Отметим, что для успешного сохранения куки браузер должен разрешать прием куки, а браузеры, обычно, по умолчанию так и настроены. LTPA-куки - это кратковременные куки, поскольку они живут только в памяти браузера и навсегда удаляются при его закрытии.
Рисунок 2. При регистрации в браузер возвращаются LTPA-куки
LTPA-куки - это стандартные куки браузера. Если вы не знакомы с понятием куки, знайте, что они являются стандартным методом сохранения информации на компьютере пользователя для дальнейшего использования. Информация, сохраняемая в этих LTPA-куки, указывает, что Блэнд уже зарегистрировался. Все куки имеют несколько стандартных атрибутов, таких как имя. В частности, имя LTPA-куки - LtpaToken (кстати, при конфигурировании SSO обратите внимание на то, что мы в наших программах конфигурирования обычно ссылаемся на LTPA-куки как на SSO LTPA "маркер" ("token"); говоря о SSO-куки, мы могли бы использовать также термин SSO-маркер). Кроме имени LTPA-куки имеют значение, как и все другие куки браузера. В случае с LTPA-куки при поверхностном взгляде мы не можем узнать много об их значении, поскольку это значение закодировано. Требование к кодированию значения LTPA-куки позволяет критической информации, содержащейся в них, инкогнито перемещаться по интернету.
Как и обычные куки браузеров, LTPA-куки имеют связанную с ними информацию о домене. Когда Блэнд регистрируется в разведывательном центре, сервер центра создает LTPA-куки. Этот сервер находится в DNS-домене spies.com, следовательно, информация о домене куки устанавливается в spies.com. Информация о домене указывает на то, что этот куки должен приниматься только в DNS-домене spies.com. Поскольку реализация LTPA полагается на куки браузеров, хранящих информацию о домене, это, в общем-то, подразумевает, что SSO-среда должна развертываться только в одном DNS-домене. В нашем примере развертывания серверами являются spycentral.spies.com, spymeetings.spies.com и spyVsSpy.spies.com. Все машины находятся в DNS-домене spies.com. Это ограничение на развертывание SSO в одном DNS-домене непосредственно имеет отношение к тому обстоятельству, что куки браузера с информацией о домене являются сердцем LTPA-реализации (однако отметим, что существуют обходные пути решения этой DNS-проблемы - см. данную вкладку).
Теперь, после краткого обсуждения различных частей LTPA-куки, вернемся назад к основам и разберемся, как эти куки играют ведущую роль в нашем SSO-решении. После регистрации Блэнда и получения LTPA-куки его браузером браузер автоматически будет передавать эти куки при HTTP-обмене. Нет необходимости делать специальное конфигурирование; это просто стандартный способ поведения браузеров. Браузер будет постоянно посылать эти куки в каждом HTTP-запросе, передаваемым им по любому адресу URL с корректным DNS-доменом. Например, когда Блэнд вводит URL spycentral.spies.com, браузер видит, что имеет куки, соответствующие домену spies.com и автоматически посылает их. Это же происходит и при обращении Блэнда к spymeetings.spies.com. C каждым подходящим HTTP-запросом браузер посылает куки. Что происходит, когда SSO-сервер получает HTTP-запрос и видит, что в него включены LTPA-куки? Сервер проверяет куки и обнаруживает, что они принадлежат Блэнду, зарегистрированному пользователю. Сервер может затем разрешить доступ Блэнда к соответствующей информации на сервере.
Итак, определением того, когда надо передавать LTPA-куки с HTTP-запросами, занимается браузер (см. рисунок 3).
Предположим, что Джим Блэнд просматривает URL, не принадлежащий DNS-домену spies.com; например, предположим, что URL принадлежит домену cia.gov (возможно, для поиска более пленительных заданий). В этом случае браузер не может передать LTPA-куки, поскольку этот куки не соответствует домену cia.gov, а соответствует только spies.com. Браузер просто не включит куки в запрос к cia.gov, следовательно, принимающий сервер не имеет информации о том, кто этот пользователь. Сервер cia.gov перед предоставлением доступа, вероятно, запросит Блэнда ввести его имя и пароль.
Рисунок 3. Браузер посылает LTPA-куки только на серверы в spies.com
На рисунке 3:
A. Блэнд уже зарегистрировался. Браузер автоматически посылает LTPA-куки, которые разрешают ему обратиться к URL на spycentral.spies.com.
B. Блэнд просматривает URL на другом сервере в DNS-домене spies.com и получает доступ, поскольку браузер передает LTPA-куки.
C. Браузер не может передать LTPA-куки в www.cia.gov, поскольку DNS-домен не соответствует. Следовательно, сервер cia.gov должен запросить у Блэнда его имя и пароль, прежде чем разрешить доступ.
Храните ключи подальше от криминальных рук
SSO является отличной технологией с точки зрения удобства для пользователей, но она имела бы не большую ценность, если бы была незащищенной. Защита - это первостепенное дело, особенно когда на свободе члены заклятого врага TGSA организации BEDLAM (Bureau of Egregiously Dangerous Lawless Assassins and Murderers - Бюро чрезвычайно опасных преступных террористов и убийц). LTPA-куки защищены, поскольку создаются с использованием защитной криптографии. Сервер, создающий LTPA-куки, использует набор криптографических ключей. Криптографические ключи используются для кодирования куки, а закодированные куки, передаваемые в браузер пользователя, не могут быть декодированы тем, у кого нет ключей. Криптографические ключи используются также для проверки куки, так что целостность куки можно проверить и легко обнаружить подделку. Все серверы в SSO-среде должны совместно использовать одни и те же криптографические ключи. Когда SSO-сервер получает HTTP-запрос и обнаруживает, что в него включены LTPA-куки, он проверяет их, используя копию общих криптографических ключей, а информация в корректных куки позволяет серверу распознать зарегистрированного пользователя (например, Джима Блэнда).
Защитная криптография, используемая SSO-серверами, гарантирует, что шанса сфальсифицировать Куки нет. Предположим, что враг Блэнда (и лидер BEDLAM) доктор Нотнау (Dr. Notnow) пытается создать свои собственные SSO-куки в надежде проникновения в SSO-серверы. Доктор Нотнау надеется удалить записи о своих нарушениях правил парковки из интерактивных баз данных. Доктору Нотнау не удастся проникнуть в SSO-серверы, поскольку он не имеет криптографических ключей. Фальшивые куки, приходящие от доктора Нотнау, будут проигнорированы, поскольку они не могут быть подтверждены.
В среде WebSphere Portal криптографические LTPA-ключи обычно создаются программой WebSphere во время конфигурирования SSO. Администратор может затем экспортировать ключи в файл для переноса на другие SSO-серверы (например, Domino) и импортирования их. Понятно, что вы должны обращаться с этим файлом ключей чрезвычайно внимательно и хранить его копии под замком (если не за сканером сетчатки глаза)!
"Позвольте представиться"
Отлично. Теперь вы должны быть убеждены, что SSO-защита встроена в систему (взгляните на этот вкладыш, на котором размещены дополнительные советы по корректному развертыванию защищенной SSO-среды). Поэтому давайте вернемся к обсуждению того, что находится внутри этих закодированных куки. Рассмотрим процесс регистрации Джима Блэнда детальнее. Во-первых, он предоставляет свое имя пользователя jb013 и пароль. Сервер регистрации ищет в каталоге пользователя jb013. Предположим, что в каталоге найдена запись для пользователя с указанным именем uid=jb013,ou=secret,dc=spies,dc=com. После проверки пароля этого пользователя сервер знает его по отличительному имени. Это отличительное имя записывается в LTPA-куки, генерируемые и передаваемые в браузер. Браузер посылает куки в HTTP-запросах. Что происходит потом? Поскольку Блэнд просматривает URL в SSO-среде, SSO-сервер получает куки и использует криптографические ключи для их декодирования и проверки. SSO-сервер увидит, что внутри куки находится следующее имя пользователя uid=jb013,ou=secret,dc=spies,dc=com. SSO-сервер идентифицирует пользователя на основе этого имени, присутствующем в LTPA-куки (см. рисунок 4).
Рисунок 4. Внутри закодированного куки
На рисунке 4:
A. Блэнду отображается запрос для регистрации, следовательно, он вводит свое имя пользователя jb013 и пароль.
B. Сервер ищет пользователя jb013 в каталоге и находит соответствующую запись, с которой сравнивает пароль Блэнда.
C. Теперь Блэнд зарегистрирован. Сервер возвращает в браузер LTPA-куки, содержащие отличительное имя Блэнда.
В среде, в которой имеется только один каталог, использующийся всеми SSO-компонентами, имени в LTPA-куки достаточно для положительной идентификации пользователя. Однако в более сложных средах с несколькими каталогами могут возникать проблемы, если в этих каталогах используется несколько форматов имен для одного пользователя, такого как Блэнд. Предположим, что используются два каталога: Microsoft Active Directory и IBM Lotus Domino Directory. Существует проблема, если отличительное имя Блэнда в Active Directory не совпадает с его отличительным именем, определенным в Domino. Когда пользователь имеет больше одного имени, проблема существует просто из-за того, что LTPA-куки содержат одно и только одно имя для идентификации зарегистрированного пользователя. Имя пользователя, включенное в LTPA-куки, может быть единственной информацией о пользователе, которую получает сервер. Если принимающий сервер не распознает имя в LTPA-куки, SSO умрет ужасной смертью.
 |
Понимание проблемы нескольких каталогов и нескольких сущностей
IT-администраторы TGSA завидуют Джиму Блэнду, занимающемуся нарушителями правил парковки мирового масштаба - если бы и про IT-работу можно было сказать "миссия выполнима!" Для IT-администраторов недостаточно мирового масштаба, когда можно охватить всю вселенную. Корпоративная IT-инфраструктура редко организована в соответствии с каким-либо генеральным планом и чаще всего похожа на совершенный хаос. Хотя конечной целью многих организаций является один каталог, содержащий всех пользователей корпорации, типична ситуация, когда в структуре корпорации имеется как минимум два (а, часто, и больше) каталога. Администраторы оставлены один на один с проблемами верификации паролей, несколькими сущностями и необходимостью реализации работоспособных решений.
Итак, почему больше одного каталога? Как известно, разные приложения требуют разных каталогов. Среды с несколькими приложениями по всей организации приводят к заполнению со временем нескольких репозиториев пользователей. Например, компания, имеющая существующую среду WebSphere Portal Application с пользователями и группами, уже созданными в LDAP-каталоге, и среду IBM Sametime, использующую Domino Directory. ACL-механизмы (access control) Domino-приложений и ECL-механизмы (execution control) часто сложны для изменения. Реорганизация или дублирование списков управления доступом, основанных на длительном использовании определенной службы каталогов, была бы сложным, затратным по времени и стоимости решением. Наконец, в постоянно меняющемся мире, корпоративных слияний и приобретений (или правительственных маневров) администраторы снова и снова вынуждены упражняться во внедрении нового каталога в существующую структуру.
Хорошие секретные агенты, такие как Джим Блэнд, всегда имеют план побега. Имеет его и IT-отдел TSGA. В следующем примере мы рассмотрим, как IBM помогает превосходной VM Блэнда и ее IT-администраторам успешно интегрировать мир нескольких каталогов и многих сущностей. Их инфраструктура требует использования двух каталогов. TSGA-реализация WebSphere Portal Server (WPS) и WebSphere Application Server (WAS) сконфигурирована на использование LDAP IBM Directory Server (ITDS), а разросшаяся взаимодействующая среда, включающая такие приложения, как Портлеты Domino Web Access, Sametime и Quickplace, требует использования Domino Directory. TSGA-агенты расположены в обоих каталогах.
Понимание сценария с несколькими каталогами и сущностями является ключевым для TSGA, поскольку это VM-план использования всего спектра взаимодействующих продуктов IBM (включая Domino, Portal-приложения, а также IBM Workplace Collaboration Services), не нарушая порядок работы. VM требует функциональной SSO при развертывании семейства IBM-продуктов, решений и технологий, которые плавно трансформируют способ работы Агента 013 и его коллег в опасном мире шпионажа и парковочных жуликов.
Что в имени?
Как упоминалось ранее, имена критичны в нашем SSO-мире. Джим Блэнд реально имеет одно имя, но (в мире шпионов и в IT-инфраструктуре TSGA) много сущностей. В штаб-квартире TSGA развернуто несколько приложений с различными инфраструктурами каталогов, так что Блэнд имеет несколько сущностей, каждая из которых отформатирована в зависимости от схемы этого каталога. Например, отличительное имя Блэнда (distinguished name - DN), существующее на сервере IBM Tivoli Directory Server (ITDS), отличается от его отличительного имени Domino как по иерархии, так и по синтаксису:
|
LDAP-сущность (ITDS)
|
Domino-сущность
| | uid=jb013,ou=secret,dc=spies,dc=com | cn=Jim Bland/ou=secret/o=spies |
Сущность в механизме Portal-регистрации по сравнению с сущностью в Portal-приложении
Помните, ключевым положением является распознавание SSO-серверами и приложениями пользователей только один раз при их регистрации в системе. Когда Блэнд вводит в браузер WebSphere URL, он получает запрос на ввод имени и пароля для регистрации. Блэнд, всегда испытывающий нехватку времени, вводит свое уникальное кодовое имя jb013. Сервер приложений WebSphere проверяет личность Блэнда, находя его имя в ITDS-сервере и сверяя пароль. После верификации имени Блэнд может обратиться к содержимому WebSphere Portal Server в своем браузере (см. рисунок 5).
Рисунок 5. Сущность в механизме Portal-регистрации
LTPA-куки содержат теперь LDAP-сущность Блэнда: uid=jb013,ou=secret,dc=spies,dc=com. Это его сущность Portal-регистрации.
Теперь Джим решает проверить свою почту (он ждет ответа на запрос по поиску задания CIA) и переключается в портлет Domino Web Access (см. рисунок 5). LTPA-маркер передается через HTTP в сервер Domino Web Access, который затем просматривает каталог Domino для верификации его сущности (аутентификации), и, на базе его сущности, решит, позволить ли ему использовать ресурсы Domino Web Access (авторизация). Но LTPA-маркер содержит его сущность в Portal-приложении. Получит ли Блэнд доступ?
Блэнд несомненно получает доступ, и его портал-сущность jb013 отображается в его Domino-сущность Jim Bland внутри портлета Domino Web Access. Но, как интегрированная среда приложений TSGA обрабатывает отображение имен?
Передышка...
Этим мы завершим обзор основ SSO и проблем, с которыми вы можете столкнуться при работе в среде с несколькими каталогами и несколькими сущностями. Во второй части данной серии статей мы последуем за нашим героем Джимом Блэндом и его товарищами по нескольким SSO-сценариям, а также взглянем на новые функциональные возможности SSO, предлагаемые в Notes/Domino 7.
Ресурсы
Об авторах | | | Джейн Маркус (Jane Marcus) работает старшим инженером-программистом в IBM. Она уже несколько лет занимается вопросами защиты, а в последнее время проблемами единой регистрации в различных продуктах IBM. Джейн большую часть своего времени проводит за разработкой систем защиты для технологий интернет-приложений и Web-серверов, хотя время от времени создает также новые пользовательские интерфейсы системы защиты. Кроме работы она увлекается музыкой, а также призрачной погоней за совершенной физической формой (еще Джейн просила нас добавить, что тоже не является шпионкой) |
| | |
Терри Уоррен (Terri Warren) работает инженером-программистом в IBM. Занимается Directory Services с середины 1990-х годов, специализируясь на LDAP и Domino. С недавних пор занимается также интеграцией каталогов Domino с различными продуктами IBM, а в далеком прошлом работала над StreetTalk в Vines и Distributed Computing Environment (DCE). Хотя Терри тоже не состоит в разведке, она верит, что Джиму Блэнду намного больше понравилась бы его работа, если бы он выслеживал своих противников на площадках для гольфа по всему миру! |
| | | ми Смит (Amy E. Smith)- главный разработчик в группе Lotus User Experience. Ее основной задачей является документация по администрированию системы защиты Domino and Workplace. Она также является членом группы поддержки сайта Lotus Documentation www.lotus.com. Эмми ни сейчас, ни когда бы то ни было не была членом разведывательной организации, хотя не отказалась бы от телефона в ботинке! |
Выскажите мнение об этой странице
| |
