Единая регистрация в современных условиях: "Никогда не говори login снова": Часть 2: Сценарии Single Sign-on

Опции документа Опции документа, требующие включения JavaScript, не отображаются Обсудить Выскажите мнение об этой странице Помогите нам улучшить содержание

Уровень сложности: средний

Джейн Маркус (Jane Marcus), старший инженер-программист, IBM
Эмми Е. Смит (Amy E. Smith), главный разработчик, IBM
Терри Уоррен, инженер-программист, IBM

25.04.2007

В этой заключительной части серии из двух статей мы рассмотрим несколько различных сценариев, с которыми вы можете столкнуться при реализации функциональности единой регистрации (single sign-on - SSO) на вашем сайте.

В первой части данной серии статей отважный секретный агент Джим Блэнд помог нам понять основы единой регистрации и среды с несколькими каталогами и сущностями. Теперь мы последуем за мистером Блэндом и его друзьями по нескольким SSO-сценариям и закончим серию беглым взглядом на улучшения SSO в Notes/Domino 7. Как и в первой части, мы предполагаем, что вы являетесь опытным пользователем и/или администратором Notes и Domino.

Сценарии единой регистрации

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

Возможны частные случаи, когда организации нужен доступ и к LDAP-каталогу, и к Domino Directory по причинам, не связанным с SSO. Например, TSGA имеет специальную систему инвентаризации, которая отслеживает дефектное, взорванное и совершенно секретное оборудование. Эта система инвентаризации нуждается в доступе к ITDS LDAP-каталогу, в котором есть некоторый каталог объектов "Special Equipment", и среда справочного отдела (Directory Assistance) настроена на обращение к этому ITDS LDAP-каталогу. В этом случае управление взаимоотношениями между по-разному настроенными каталогами будет главной причиной развертывания SSO.

Подводя итог вышесказанному, отметим, что некоторые из рассматриваемых ниже SSO-сценариев управляют SSO-информацией в Domino-каталоге, тогда как другие управляют SSO в LDAP-каталоге. У нас также есть сценарий, где вступает в действие Directory Assistance. К счастью, среди различных сценариев вы наверняка обнаружите один, хорошо подходящий к вашей инфраструктуре и потребностям вашей организации. Выбранная вами SSO-конфигурация всегда будет зависеть от текущих потребностей организации.

Хотя SSO-подход в различных сценариях может отличаться, обратите внимание на то, что во всех случаях Блэнд всегда регистрируется сначала в WebSphere Portal Server, и при этом создается LtpaToken, содержащий его ITDS-сущность uid=jb013.

Сценарий 1. Отображение имен с использованием персонального документа Domino

Начнем с описания самого распространенного базового сценария. Этот сценарий описывает, как управлять SSO-информацией в Domino-каталоге.

Когда Блэнд переходит в DWA-портлет, LtpaToken, содержащий jb013, передается по HTTP. Как же Domino-сервер разрешит Блэнду доступ к его почтовому файлу DWA, особенно когда ACL-запись этого файла позволяет доступ для cn=Jim Bland/ou=secret/o=spies? Очень просто - администратор может изменить персональный документ Блэнда, добавив uid=jb013/ou=secret/dc=spies/dc=com ко вторичному значению его поля fullname (см. рисунок 1):

Сервер Domino Web Access ищет в Domino Directory значение, содержащееся в LtpaToken, и находит соответствие, потому что это значение содержится в персональном документе. Domino разрешает имя в отличительное Domino-имя Jim Bland/Secret/Spies, которое содержится в ACL для его почтового файла, поэтому Блэнду предоставляется доступ к его почтовому портлету!

TSGA-администратор должен держать в голове следующие правила для отображения имени:

• При изменении поля FullName персонального документа Domino вводите отличительное LDAP-имя в "Domino-формате".
  LDAP-формат: uid=jb013,ou=secret,dc=spies,dc=com
Domino-формат: uid=jb013/ou=secret/dc=spies/dc=com
• Добавляйте LDAP DN к полю FullName как вторичное значение. Не добавляйте LDAP DN как первое или второе значение. Domino ожидает, что первичным значением будет Domino DN, а вторым - "общее имя" Domino.
• Некоторые приложения чувствительны к регистру букв, поэтому будьте осторожны! Хотя сервер Domino снисходителен к регистру, другие приложения могут таковыми не быть. Лучше защититься, чем потом сожалеть.
• Для облегчения изменений каталога TSGA может захотеть рассмотреть возможность использования IBM Tivoli Directory Integrator для автоматизации реализации их политик отображения.

Сценарий 2. Отображение имен с использованием Directory Assistance: разрешение нескольких соответствий

Как упоминалось ранее, в некоторых организациях, возможно, потребуется доступ одновременно к обоим каталогам, часто не из-за единой регистрации. Инфраструктура отдела TSGA Research Department требует, чтобы сервер Domino имел доступ к серверу IBM Tivoli Directory Server (ITDS) для системы инвентаризации потерянного оборудования, упомянутой ранее. Для того чтобы специализированное Notes-приложение по инвентаризации имело доступ к некоторому каталогу объектов "Special Equipment", существующему в ITDS, администратор создает LDAP-запись для ITDS-каталога в базе данных Directory Assistance на сервере Domino (на сервере работает также Domino Web Access).

Для реализации SSO в этой среде, также как и в предыдущем сценарии, TSGA добавляет значение LtpaToken uid=jb013,ou=secret,dc=spies,dc=com в персональный документ Domino. Появляется новая дилемма. Имя uid=jb013,ou=secret,dc=spies,dc=com теперь существует в двух местах: в ITDS-записи для пользователя и в персональном документе Domino для Jim Bland/Secret/Spies. Как сервер Domino будет управлять поиском соответствия для Блэнда в обоих местах (в Domino Directory и ITDS-сервере), если DN (отличительные имена) различны? Как Domino определяет, что они на самом деле представляют одну личность?

Последние версии Domino 6.x и 7.0 справляются со сценариями с отображением имен, где пользовательские записи находятся в нескольких местах, при участии Directory Assistance. Domino требует соответствия между персональным документом Domino и LDAP-записью; в результате Domino будет теперь выполнять дополнительные действия для определения того, что существуют совпадающие значения для поля "Internet address", расположенные в обоих каталогах. DA выдает поисковый запрос для сущности uid=jb013 вместе с эквивалентным LDAP-атрибутом для поля Notes InternetAddress. Для LDAP эквивалентным атрибутом является почта.

Последняя строка говорит о том, что если TSGA имеет среду, в которой DA указывает на LDAP-каталог, содержащий SSO-сущности, администратор должен убедиться в том, что значение Domino-атрибута "Internet address" совпадает со значением LDAP-атрибута "mail".

Дополнительная информация о том, как Domino и Directory помогают справиться с отображением имен и несколькими совпадениями, приведена в Notes/Domino 6.0.4 Release Notes "Имена WebSphere и Domino, обрабатываемые сервером Domino HTTP server".

На рисунках 2, 3, 4 и 5 показан процесс выполнения SSO-действий Джимом Блэндом, когда Directory Assistance указывает на LDAP-каталог, содержащий тот же uid, который был добавлен в персональных документ. На рисунке 2:
A. Блэнд просматривает свой DWA-портлет. Portal передает LtpaToken на сервер Domino Web Access, который ищет в Domino-каталоге запись uid=jb013,ou=secret,dc=spies,dc=com.
B. Domino находит соответствие для uid=jb013,ou=secret,dc=spies,dc=com в третьем значении FullName в первичном каталоге в персональном документе, принадлежащем пользователю с отличительным Domino-именем Jim Bland/Secret/Spies.

На рисунке 3:
C. Directory Assistance настроен так, что поисковый запрос выполняется для указанного LDAP-каталога. LDAP-поиск:
BaseDN: ou=secret,dc=spies,dc=com
Filter: uid=jb013
attrs to return: "mail"
D. IBM Directory Server возвращает соответствие и запрошенное значение для атрибута mail: mail=JBland@secret.spies.com.

На рисунке 4:
E. Соответствует ли содержимое "mail" содержимому InternetAddress"? Другими словами, соответствует ли значение атрибута InternetAddress в персональном документе Domino значению атрибута mail в ITDS?

И, наконец, на рисунке 5:
F. Та же личность (Джим Блэнд) проверяется, будучи представленной ITDS-записью и персональным документом Domino, на основе соответствия почтового адреса в каждой из этих записей. Отображение имен с LDAP-имени в Domino-имя проходит успешно, и Блэнд получает доступ к своему почтовому файлу Domino Web Access.

Сценарий 3. Отображение имен путем изменения внешней LDAP-схемы и DA

В различных организациях TSGA LDAP выбран как корпоративный каталог. Имеются политики и процедуры для управления добавлениями, удалениями и изменениями схемы каталогов в LDAP и только LDAP. В данном примере изменения и обновления управляются в основном через IBM Tivoli Directory Server, а изменения не разрешены в Domino Directory. C гибкостью новой функциональной возможности, добавленной в Directory Assistance Domino 6.0, это не проблема. Администратор TSGA может выбрать изменение корпоративного LDAP-каталога, добавляя отличительное Notes-имя (DN) как атрибут LDAP-сущности пользователя. В случае с Блэндом отличительное Notes-имя добавляется как атрибут его записи uid=jb013,ou=secret,dc=spies,dc=com в IBM Tivoli Directory Server. LDAP-домен добавляется в Directory Assistance, указывая на корпоративный сервер LDAP-каталога. Если TSGA принимает эту стратегию для добавления информации в LDAP, не нужно вносить изменения в персональные документы Domino (то есть, не меняются вторичные значения поля FullName).

Администратор должен затем выбрать, какой LDAP-атрибут заполнять отличительным Notes-именем в IBM Tivoli Directory Server. Атрибутом может быть один из уже существующих в LDAP-схеме, либо администратор может расширить LDAP-схему, создавая новый атрибут. В любом случае тип синтаксиса атрибута должен быть DN. Дополнительная информация по типам синтаксиса атрибутов приведена в RFC 2252.

После выбора атрибута TSGA-администратор может добавить Notes DN для каждой сущности, требующей SSO, в LDAP-синтаксис. Предположим, что администратор выбирает создание нового атрибута с именем NotesDN, который является частью персональной схемы в каталоге IBM Tivoli Directory Server LDAP. Затем он добавляет отличительное Notes-имя cn=Jim Bland, ou=secret, o=spies в качестве значения атрибута NotesDN. Для настройки SSO администратор выбирает закладку LDAP (см. рисунок 6) для записи DA Domain, в поле "Attribute to be used as Notes Distinguished Name" добавляет имя LDAP-атрибута NotesDN и устанавливает "Trusted for credentials" в закладке Naming Contexts (Rules). Также TSGA-администратор проверяет, что любые контекстные правила именования для LDAP-иерархий корректны. Другими словами, иерархия каталогов в IBM Tivoli Directory Server (ou=secret,dc=spies,dc=com) отличается от иерархии каталогов в Domino (ou=secret/o=spies). Убедитесь, что правила корректно определены в DA. Дополнительная информация по Directory Assistance Naming Contexts приведена в разделе "Правила обслуживания и именования каталогов" в "Руководстве администратора Domino".

На рисунках 7, 8, 9 и 10 показан процесс прохода запроса Джима Блэнда по SSO-среде с использованием этой новой функциональной возможности. На рисунке 7:
A. Джим открывает свой портлет Domino Web Access, и Portal передает LtpaToken на DWA-сервер, который ищет в Domino-каталоге uid=jb013,ou=secret,dc=spies,dc=com. Опять же, в отличие от рассмотренного в предыдущем разделе сценария, uid=jb013,ou=secret,dc=spies,dc=com не существует где-либо в Domino-каталоге.
B. Domino-каталог настроен с Directory Assistance. Directory Assistance настроен с функциональной возможностью "Attribute to be used as Notes Distinguished Name".

На рисунке 8:
C. Поисковый запрос LDAP выполняется для uid=jb013 с запросом возврата атрибута NotesDn. LDAP-поиск:
BaseDN: ou=secret,dc=spies,dc=com
Filter: uid=jb013
attrs to return: "NotesDN"
D. IBM Directory Server возвращает соответствие с атрибутом NotesDN, содержащим значение cn=Jim Bland,ou=secret,o=spies.

На рисунке 9:
E. Поскольку возвращается NotesDN, имя uid=jb013/ou=secret/dc=spies/dc=com отображается в отличительное Notes-имя, присутствующее в ACL почтового файла.

И на рисунке 10:
F. Джим Блэнд получает доступ к своему почтовому файлу Domino Web Access.

Сценарий 4: Взаимодействующие компоненты IBM, использующие LDAP-протокол для отображения имен

До сих пор наши сценарии были достаточно легкими для понимания и развертывания. Пристегнитесь, так как ситуация усложняется. В данном сценарии мы рассмотрим SSO-требования для семейства улучшенных продуктов Domino.

Будучи образцом спонтанности, Джим решает, что хочет передать мгновенное сообщение Агенту 009 об особо опасной ситуации, складывающейся в Дубьюке. Затем он планирует обратиться к TSGA Agent Team Workspace со страницы портала WebSphere Portal Server. Он сейчас использует два взаимодействующих компонента в интегрированной среде IBM для SSO: Sametime и Quickplace. Sametime и Quickplace настроены на SSO (они оба принимают один и тот же LtpaToken, содержащий имя зарегистрировавшегося пользователя "uid=jb013..."). В отличие от DWA в нашем предыдущем примере, как Sametime, так и Quickplace сконфигурированы на поиск пользователей в Domino Directory по LDAP-протоколу вместо использования интерфейса Domino Directory, основанного на родном для Domino NRPC-протоколе. Когда сервер Sametime или Quickplace запрашивает Domino для сущности, находящейся в LtpaToken, запрос выполняется с использованием LDAP-протокола; следовательно, сервер Domino LDAP получит запрос и начнет свой поиск.

Если Domino Server находит соответствие в своем каталоге, он возвратит Domino DN в синтаксисе LDAP-формата - "cn=Jim Блэнд,ou=secret,o=spies". Дальнейшая забота Sametime или Quickplace - определить, что "cn=Jim Блэнд,ou=secret,o=spies" на самом деле та же сущность, что и значение LtpaToken "uid=jb013,ou=secret,dc=spies,dc=com". По существу, серверы Sametime и Quickplace теперь отвечают за отображение имен. В этом состоит отличие от предыдущих сценариев. В ситуации, когда приложения обращаются к Domino через HTTP (для TSGA это был DWA-портлет), Domino Web Server будет получать запрос, и LDAP-запросы создаются в Directory Assistance - как результат, Domino Directory будет обрабатывать все потребности отображения имен. Однако в рассматриваемой сейчас ситуации Domino и Directory Assistance не берут ответственности за обработку отображения имен; вместо этого отображение имен должно обрабатываться серверами Sametime и Quickplace. Как упоминалось ранее, просмотр каталога по LDAP-протоколу является средством, которым Sametime и Quickplace завершают отображение имен.

Для завершения всего этого всезнающий и всесильный администратор TSGA должен будет выполнить несколько дополнительных упражнений.

Администратор TSGA должен реализовать отображение имен, добавляя LDAP DN как вторичное значение поля FullName в персональный документ Domino. Администратор TSGA должен также включить разыменование (dereferencing) LDAP-псевдонима для соответствующих LDAP-клиентов - в данном частном случае, клиент Sametime Links и клиент Quickplace. Для того чтобы LDAP-сервер искал LDAP-имя, перечисленное как вторичное значение поля FullName в персональном документе Domino, LDAP-клиент должен запросить LDAP-сервер разыменовывать псевдонимы при выполнении поиска имени. LDAP-псевдонимы и Notes-псевдонимы являются двумя различными концепциями. По существу, LDAP-псевдоним является записью в LDAP или X.500 каталоге, указывающей на другую запись в иерархии каталогов. Для Notes псевдонимом является любое вторичное значение поля FullName или поля ShortName. Для того чтобы сервер Domino разрешал псевдоним (например, LDAP-имя "uid=jb013...") в отличительное Domino-имя, LDAP-сервер должен принять запрос от LDAP-клиента с включенным параметром Dereferencing of Aliases:

Разыменование LDAP-псевдонима должно также быть разрешено на LDAP-сервере - по умолчанию Domino LDAP Server не разыменовывает псевдонимы. Администратор TSGA разрешит эту функциональную возможность, открыв глобальную конфигурационную запись *-[ALL Servers] из Configurations options в первичном каталоге Domino, выбрав закладку LDAP и установив "Allow dereferencing of aliases on search requests?" в значение Yes (см. рисунок 11):

Обновите серверы Sametime и Quickplace до последней текущей версии (для конфигураций с несколькими каталогами могут также понадобиться свежие исправления ошибок (hotfixes)).

Нужно знать даже еще больше. Администраторы Sametime могут просмотреть этот вкладыш для получения дополнительных советов по администрированию Sametime, а администраторы Quickplace могут просмотреть этот вкладыш для получения информации по Quickplace.

В начало

Сценарии мгновенной смерти

Джим Блэнд мечтает о захватывающих заданиях, наполненных интригой и опасностью. Однако его текущие мучения с парковкой, вероятно, не являются сценариями выбора между жизнью и смертью. Это же можно сказать и о SSO. Мы знаем, что ваша оборона уже может быть разрушена нашими техническими подробностями. Однако мы должны быть упорными и обратить свое внимание на некоторые критические проблемы, связанные с именами, содержащими специальные символы. Такие имена могут причинить мгновенную смерть в SSO-сценариях.

Отличительные Domino-имена отличаются по формату от отличительных LDAP-имен. Как упоминалось ранее, Domino использует в качестве символов-разделителей косую черту (slash), тогда как LDAP использует запятые. В различных продуктах IBM реализована логика преобразования имени из одного формата в другой. Однако кроме символов-разделителей существует много других синтаксических различий между Domino-форматом и LDAP-форматом имен, которые должны обрабатываться корректно. В частности, специальной обработки требуют следующие символы, если они присутствуют в LDAP-имени:

• меньше чем <
• больше чем >
• точка с запятой ;
• запятая , (внутри имени, не как разделитель)
• знак плюс +
• двойные кавычки "
• обратная косая черта \
• Пробел или символ #, встречающиеся в начале строки
• Пробел, встречающийся в конце строки

Имена со специальными символами могут вызвать проблемы в SSO-сценариях во время преобразования имени в LTPA-куки из LDAP-формата в Domino-формат и наоборот. Поскольку имена критичны для SSO, понятно, что SSO споткнется при наличии какой либо неполадки в преобразовании, поскольку имя не будет распознано. Использующееся программное обеспечение должно выполнять корректные преобразования. Вы можете избежать мертвых сценариев в вашей среде, только получая самые свежие и хорошие версии. Для гарантии правильной обработки в SSO-сценариях имен со специальными символами вы должны обновить сервер Domino до версии 6.5.4 или выше.

Имена со специальными символами могут вызвать проблемы в Collaborative Portlets, а также в семействе улучшенных продуктов Domino. Если вы развернули версию WebSphere Portal, меньшую, чем 5.1, возможно понадобится установить пакеты исправления ошибок для обработки таких имен. Также существуют пакеты исправления ошибок для поддержки специальных символов серверами Quickplace и Sametime.

В начало

Грядущие улучшения

В настоящее время в сценарии с несколькими сущностями пользователь всегда должен сначала регистрироваться в WebSphere (или WebSphere-компоненте, например, в портале). WebSphere должен создать LTPA-куки, помещая в них LDAP-имя пользователя, которое может распознать WebSphere. SSO работает хорошо, поскольку сервер Domino является гибкой системой и может быть настроен на прием LTPA-куки, созданных с известным WebSphere LDAP-именем. Однако обратная ситуация проблематична: в сценарии с несколькими сущностями WebSphere имеет проблемы при приеме имени в Domino-формате. Почему имя должно быть в Domino-формате? Если пользователь регистрируется сначала в Domino, Domino создает LTPA-куки и помещает в них имя в Domino-формате. Когда WebSphere получает куки и ищет в них имя, SSO нарушается, поскольку Domino-имя не найдено в пользовательском каталоге WebSphere. Для того чтобы WebSphere была достаточно гибкой для приема Domino-имени, вы должны были бы написать некоторый пользовательский код для WebSphere. Поскольку такое решение требует выполнения работ по развертыванию и поддержке, это, обычно, не желательная стратегия; вместо этого вы просто советуете вашим пользователям сначала регистрироваться в WebSphere. Помощь уже идет. Для удобства пользователей в Domino 7 удалено ограничение необходимости регистрации пользователей сначала в WebSphere. В Domino 7 мы предоставили параметры конфигурации, позволяющие пользователям сначала регистрироваться в Domino. Идея заключается в том, чтобы администратор выбрал формат имени пользователя, которое должно помещаться во все LTPA-куки, создаваемые Domino для этого пользователя. Вместо помещения в LTPA-куки имени в Domino-формате, Domino 7 может быть сконфигурирован на помещение в них LDAP-имени. Для обеспечения максимальной возможности взаимодействия SSO администратор должен выбрать формат, который будет приемлем для Domino, WebSphere и всех остальных улучшенных продуктов Domino.

Пользователи Domino 7 могут попробовать эти новые возможности уже сегодня. Первый шаг - включить переключатель, указывающий на то, что вы хотите настроить LTPA-имена пользователей. Этот переключатель находится в документе конфигурации SSO в новом поле (см. рисунок 12). Если переключатель не включен, Domino будет продолжать помещать в LTPA-куки создаваемое им Domino-имя пользователя. Если переключатель включен, Domino будет искать LDAP-имя для помещения его в LTPA-куки.

В персональных документах Domino 7 для указания LTPA-имени пользователей было добавлено новое поле. Значение этого поля будет приниматься во внимание, если в SSO-конфигурации разрешено отображение имен в LTPA-маркеры. В поле персонального документа "LTPA user name" администратор может настроить LDAP-имя Джима Блэнда, к которому могут обращаться как WebSphere, так и Domino. Это имя, которое Domino 7 будет помещать во все LTPA-куки, создаваемые им для Блэнда. Обратите внимание на то, что сконфигурированное LTPA-имя пользователя должно всегда вводиться в персональный документ в Domino-формате, в котором в качестве разделителей применяется косая черта, а не запятая. Но не бойтесь - когда Domino создает LTPA-куки, он преобразует Notes-формат в LDAP-формат должным образом перед помещением имени в куки, корректно обрабатывая специальные символы в имени.

Естественно, некоторые пользователи не имеют персонального документа Domino. Вместо этого такие пользователи имеют пользовательские записи во внешнем LDAP-каталоге. В этом случае для поиска пользователей в этом LDAP-каталоге используется Domino Directory Assistance. Поскольку данные пользователи не имеют персонального документа Domino, очевидно, что новое поле LTPA-имени пользователя в персональном документе не может быть использовано, когда в SSO-конфигурации разрешено отображение имен в LTPA-маркеры. Вместо этого для Domino-пользователей в LDAP-каталоге администратор может сконфигурировать LTPA-имя пользователя в документе Directory Assistance. В конфигурации Directory Assistance Domino 7 имеется новое поле "Attribute to be used as name in an SSO token" (Атрибут, используемый в качестве имени в SSO-маркере). Обычно, администратор заполняет это поле специальным ключевым словом $DN. Ключевое слово $DN - это краткий способ указания того, что отличительное LDAP-имя пользователя должно помещаться в LTPA-куки. Когда бы Domino ни создавал LTPA-куки для любого пользователя в этом внешнем LDAP-каталоге, Domino будет помещать отличительное LDAP-имя пользователя в куки, если $DN был настроен как атрибут, используемый в качестве имени в SSO-маркере.

В начало

(Менее) загадочный мир SSO: завершающие соображения

И вот мы здесь, в конце рассказа, и настало время вам выйти из тени и стать героем SSO. Ваша миссия, если вы ее примете, будет заключаться в помощи всем подобным Джиму Блэнду личностям в вашем офисе выполнять свою работу эффективно. Ничто не может быть большей наградой.

Мы надеемся, что в данной серии статей мы снабдили вас информацией, необходимой для развертывания SSO, особенно если ваша среда содержит несколько каталогов и сущностей. Возможно, теперь вы знаете больше о том, как работает SSO, и о том, какие архитектурные решения возможны для работы с пользователями, имеющими несколько имен. Ваш выбор будет зависеть от стратегии администрирования. IBM предоставляет решения для отображения SSO-информации в Domino-каталог и во внешний LDAP-каталог. Как только вы начнете развертывание SSO-каталога, возможно, придется настраивать Sametime и Quickplace, сверяясь с нашими специальными советами, для получения успешных результатов в среде с несколькими сущностями. Вы, как администратор, должны вооружиться правильным оружием, так чтобы ваши пользователи могли успешно и безопасно пройти через коварный мир SSO.

Мы увидели, что наш герой Джим Блэнд может маневрировать по своему использующему SSO Web-порталу так же легко, как делает это в привычном мире шпионажа. Тем временем, босс Блэнда VM счастлива видеть, что SSO дает Блэнду такое необходимое ускорение в работе. Блэнд больше не будет сталкиваться с проблемами нескольких сущностей. Единственным минусом полностью интегрированной SSO-среды Блэнда является то, что он будет скучать без голоса, произносящего его имя на каждом повороте. С функциональной SSO-средой Джим Блэнд может расслабиться, будучи уверенным, что когда бы ни открылась дверь лифта, его будет поджидать пол. Троекратное ура SSO!

Ресурсы

• Примите участие в обсуждении материала на форуме.
  
  
• Оригинал статьи "Single Sign-on in a Multi-directory World: "Never say login again" Part 2".
  
  
• В первой части данной серии статей рассматриваются основы единой регистрации и сред с несколькими каталогами и сущностями.
  
  
• Статья по Lotus на developerWorks: "Security API в Notes/Domino 7.0" - информация о новых API кодирования/декодирования, предлагаемых в Lotus Notes и Domino 7.0.
  
  
• Дополнительная информация о новых функциональных возможностях, связанных с системой защиты, в Lotus Domino 7.0 приведена в статье "Новые функциональные возможности в Lotus Domino 7.0".
  
  
• На странице продукта Lotus Notes/Domino приведена дополнительная информация о продуктах Lotus Notes и Domino.
  
  
• Примите участие в блогах developerWorks и подключайтесь к сообществу developerWorks.
  
  
• Посетите Форумы Lotus на developerWorks Россия.
  

Об авторах

		Джейн Маркус (Jane Marcus) работает старшим инженером-программистом в IBM. Она уже несколько лет занимается вопросами защиты, а в последнее время проблемами единой регистрации в различных продуктах IBM. Джейн большую часть своего времени проводит за разработкой систем защиты для технологий интернет-приложений и Web-серверов, хотя время от времени создает также новые пользовательские интерфейсы системы защиты. Кроме работы она увлекается музыкой, а также призрачной погоней за совершенной физической формой (еще Джейн просила нас добавить, что тоже не является шпионкой)

		ми Смит (Amy E. Smith)- главный разработчик в группе Lotus User Experience. Ее основной задачей является документация по администрированию системы защиты Domino and Workplace. Она также является членом группы поддержки сайта Lotus Documentation www.lotus.com. Эмми ни сейчас, ни когда бы то ни было не была членом разведывательной организации, хотя не отказалась бы от телефона в ботинке!

		Терри Уоррен (Terri Warren) работает инженером-программистом в IBM. Занимается Directory Services с середины 1990-х годов, специализируясь на LDAP и Domino. С недавних пор занимается также интеграцией каталогов Domino с различными продуктами IBM, а в далеком прошлом работала над StreetTalk в Vines и Distributed Computing Environment (DCE). Хотя Терри тоже не состоит в разведке, она верит, что Джиму Блэнду намного больше понравилась бы его работа, если бы он выслеживал своих противников на площадках для гольфа по всему миру!

Выскажите мнение об этой странице

Пожалуйста, найдите минутку и заполните форму, чтобы повысить уровень сервиса. Помогла ли данная информация достичь Вашей цели? Да Нет Не знаю   Пожалуйста, напишите комментарий, чтобы мы могли улучшить данную страницу:   Насколько полезна эта информация? (1 = Бесполезна, 5 = Очень полезна) 1 2 3 4 5

В начало