Подробности реализации сценария

14.2.2 Конфигурирование WebSphere Edge Server (обратный прокси-сервер)

Для добавления сервера IBM WebSphere Edge Server в среду была выполнена базовая установка программного обеспечения Edge Server на сервере Windows 2000 (Service Pack 3). После завершения установки базового программного обеспечения был запущен мастер конфигурирования Edge Server Configuration Wizard для настройки обратного прокси-сервера. В мастере конфигурирования были заданы следующие параметры:

После этого был запущен интерфейс администрирования Edge Server путем ввода в Web-браузере следующего адреса:

http://itsosec-rp.cam.itso.ibm.com/admin-bin/webexec/frameset.html

Через интерфейс администрирования были заданы следующие значения:

После входа в интерфейс администрирования, в разделе Proxy Settings (Параметры прокси-сервера), был выбран только протокол HTTP. Это представлено на рис 14.12(рис 14.12) Параметры прокси-сервера

В разделе Privacy Settings (Параметры конфиденциальности) была разрешена передача дополнительных HTTP-заголовков вместе с запросами. Это было выполнено путем включения параметра Forward client's IP address to destination server (Перенаправление IP-адреса клиента на целевой сервер). Это добавляет дополнительное значение HTTP-заголовка, содержащее действительный IP-адрес запрашивающего клиента. Изменение параметра представлено на рис. 14.13.

(рис 14.13) Параметры конфиденциальности

Параметры SSL были изменены таким образом, чтобы разрешать SSL-подключения. Была создана база данных ключей, и SSL-ключ для этого сервера был импортирован в базу данных ключей. Параметры используемого по умолчанию расположения базы данных и включения SSL представлены на рис 14.14(рис 14.14) Параметры SSL

Раздел Caching Filters (Фильтры кеширования) позволяет прокси-серверу выполнять кеширование содержимого, полученного обратным прокси-сервером. Функции кеширования прокси-сервера ограничиваются информацией о сроке действия, содержащейся в HTTP-заголовке. Это предотвращает кеширование динамического содержимого, которое не следует кэшировать. Для максимизации кеширования был добавлен фильтр (рис 14.15) Параметры фильтра кеширования

Раздел Last Modified Factor (Показатель последнего изменения) позволяет осуществлять более точный контроль времени действия явно заданных элементов дизайна Domino, кешируемых локально на сервере Edge. Двумя основными изначально сконфигурированными элементами являются URL-запросы (рис 14.16) Параметры Last Modified Factor (Показатель последнего изменения)

Раздел Basic Settings (Основные параметры) задает имя хоста сервера и IP-адрес, который он прослушивает. Эти параметры были изменены соответствующим образом. Кроме того, сервер был настроен на привязку ко всем локальным IP-адресам. Эти изменения представлены на рис 14.17(рис 14.17) Основные параметры

Раздел HTTP Methods (HTTP-методы) позволяет определить типы запросов, обслуживаемые сервером Edge. Единственными типами запросов, требующими обработки в Domino, являются запросы (рис 14.18) HTTP-методы

Раздел Request Routing (Маршрутизация запросов) осуществляет управление перенаправлением. Если запрос соответствует правилу, выполняется заданное действие. В табл. 14.1 представлены изменения, которые были внесены в таблицы Request Routing (Маршрутизация запросов). Пожалуйста, обратите внимание на то, что 192.168.0.3 является внутренним IP-адресом сервера itsosecdom.cam.itso.ibm.com.

Значение этих таблиц маршрутизации состоит в том, что, когда сервер Edge получает запрос, содержащий /mail/iNotes и т. д. в URL, он перенаправляет запрос непосредственно на внутренний интерфейс 192.168.0.3 сервера Domino.

Эти изменения представлены на рис. 14.19.

После обновления таблиц маршрутизации запросов файл IBMPROXY.CONF был отредактирован вручную. В файле IBMPROXY.CONF были сделаны следующие добавления:

Параметр fail /* вызывает отказ всех подключений к корневому каталогу обратного прокси-сервера. Если пользователь попытается подключиться к следующему URL:

https://itsosec-dom.cam.itso.ibm.com

он получит сообщение об отказе, представленное на рис. 14.20.

Обратный прокси-сервер будет разрешать подключения к Domino Directory (names.nsf) и к почтовому каталогу ( /mail ). Domino Directory должен быть доступным для аутентификации пользователей. Разрешением обратному прокси-серверу доступа только к определенным файлам и каталогам обеспечивается дополнительный уровень безопасности.

14.2.3 Конфигурация брандмауэра

Обратный прокси-сервер WebSphere Edge Server был размещен в демилитаризованной зоне брандмауэра нашей тестовой среды. Это позволяет осуществлять подключение к Интернету и из Интернета, а также позволяет настроить на обратном прокси-сервере доступ к серверу Domino. Серверы Domino, QuickPlace и Sametime были размещены в области действия брандмауэра. Они доступны для любого пользователя в сети.

Брандмауэр был настроен таким образом, чтобы разрешать подключения только по портам 80 и 443 из Интернета к демилитаризованной зоне и к обратному проксисерверу. Правила брандмауэра представлены на рис. 14.21.

Кроме того, брандмауэр был настроен таким образом, чтобы разрешать подключения к внутренней сети и серверу Domino только от обратного прокси-сервера.

14.3 Введение "промышленного" LDAP-сервера

На начальных этапах этого сценария существующий сервер Domino и Domino Directory были настроены на использование LDAP и обеспечивали возможности аутентификации через LDAP. На данном этапе вводится дополнительный, "промышленный" LDAP-сервер, вследствие чего функции аутентификации этой инфраструктуры передаются независимой LDAP-платформе при подготовке к внедрению технологий, отличных от Lotus. Хотя функциональные возможности LDAP можно было оставить в Domino, и при этом все дальнейшие этапы работали бы, команда Redbook посчитала, что использование LDAP-сервера, отличного от Lotus, более точно имитирует большинство сред предприятий.

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

14.3.1 Конфигурирование LDAP-сервера

Для создания отдельной LDAP-инфраструктуры был установлен IBM Directory Server на компьютере с системой Windows 2000 Service Pack 3. После установки базового программного обеспечения были созданы пользователи в LDAP-каталоге путем импортирования LDIF-файла. Этот LDIF-файл содержал LDAP-подразделения, отличные от использовавшихся в Domino LDAP (East и West). Подразделения, созданные для этого сервера, получили названия Admin, Sales, Production и Editorial. Для каждого подразделения было создано несколько пользователей.

В примере 14.1 представлена запись LDIF-файла для одного созданного пользователя, показывающая, какие поля были созданы для каждого пользователя.

dn: UID=MMilza,OU=Admin,O=Redbooks,C=US
objectclass: eDominoAccount
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: person
objectclass: top
mail: M.Milza@redbooks.com
fullName: CN=Matt Milza,OU=East,O=Redbooks
title: IT Mgr
mailSystem: 1
givenName: Matt
sn: Milza
cn: Matt Milza
uid: MMilza
userid: mmilza
mailDomain: Redbooks
mailServer: CN=itsosec-dom,OU=Servers,O=Redbooks
mailFile: mail\mmilza

Примечание. В этом примере записи LDIF-файла, dn соответствует иерархическому имени пользователя в LDAP, тогда как fullName соответствует иерархическому имени пользователя в Lotus Notes.

14.3.2 Настройка сервера Lotus Domino на новый LDAP-каталог

После этого необходимо изменить конфигурацию сервера Lotus Domino таким образом, чтобы он мог выполнять аутентификацию с применением LDAP-каталога IBM Directory Server. Для аутентификации Domino во внешнем LDAP-каталоге используются возможности Directory Assistance в Domino.

Для настройки Directory Assistance в Domino и соответствующей настройки на использование внешнего LDAP-каталога выполняются следующие действия:

14.3.3 Включение сопоставления имен

На данном этапе, при аутентификации пользователей в Domino, LDAP-каталог возвращает иерархическое имя пользователя в LDAP-каталоге. В данном случае для пользователя Matt Milza из подразделения East в Domino LDAP возвратит имя UID=MMilza,OU=Admin,O=Redbooks,C=US, которое в качестве имени подразделения указывает Admin. Если бы мы применили инфраструктуру Domino R5, нужно было бы ввести это отличительное имя LDAP в ACL всех баз данных, к которым пользователь Matt Milza должен иметь доступ.

Однако, так как у нас применяется инфраструктура Domino 6.01, можно реализовать постановку в соответствие LDAP-полю, содержащему имя пользователя Domino с применением функций постановки в соответствие имен, реализованных в Domino 6.

На рис. 14.25 представлены изменения в поле Attribute to be used as Notes Distinguished Name (Атрибут, применяемый в качестве отличительного имени Notes) в документе Directory Assistance. Это изменение создает постановку в соответствие с полем fullName в LDAP-каталоге, так как в это поле было записано иерархическое имя Lotus Notes при создании наших LDAP-пользователей при импорте LDIF в разделе 14.3.1, "Конфигурирование LDAP-сервера".

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

14.3.4 Настройка сервера Sametime на новый LDAP-каталог

После этого необходимо изменить параметры сервера Sametime таким образом, чтобы он указывал на новый LDAP-каталог.

Откройте инструмент Sametime Administration, используя ссылку administer the server (Администрирование сервера). Эта ссылка доступна в нижней части URL, STCenter.nsf по адресу

http://yourservername.company.com/stcenter.nsf

В интерфейсе средства администрирования выберите LDAP directory (LDAP-каталог) -> Connectivity (Связь).

Добавьте имя хоста и порт нового LDAP-сервера для использования списка LDAPхостов сервера Sametime. В нашей среде это выполнялось путем ввода itsosec-ldap.cam.itso.ibm.com в поле имени хоста и ввода 389 в поле порта.

Удалите сервер Domino или какие-либо прежние LDAP-серверы из списка LDAP-серверов. В нашем случае мы выбрали itsosec-dom.cam.itso.ibm.com и нажали Remove (Удалить), в результате чего все ссылки на сервер были удалены.

Измените параметры на вкладке LDAP directory (LDAP-каталог) > Basics (Основные параметры) должным образом для нового LDAP-сервера. Изменения в нашей новой LDAP-среде представлены на рис. 14.29 и 14.30.

На вкладке Authentication (Аутентификация) измените CN на UID, так как IBM Directory Server в отличие от Domino LDAP использует UID, а не CN.(рис 14.28) Добавление LDAP-сервера(рис 14.27) Удаление LDAP-сервера(рис 14.30) Раздел People (Люди) формы Basics (Основные параметры)(рис 14.29) Раздел Groups (Группы) формы Basics (Основные параметры)

Откройте базу данных Directory Assistance (da.nsf) на сервере Sametime в клиенте Notes и удалите запись Directory Assistance, которая была создана при установке Sametime для указания на LDAP-сервер Domino.

Создайте новый документ Directory Assistance, указывающий на новый LDAP-сервер. Запись Directory Assistance, созданная для нашей среды, представлена на рис. 14.31, 14.32 и 14.33.

Группа администраторов должна содержать LDAP-имена пользователей, являющихся администраторами. Эта группа была отредактирована, и были добавлены LDAP-имена пользователей.

14.3.5 Настройка сервера QuickPlace на новый LDAP-каталог

После этого необходимо изменить сервер QuickPlace таким образом, чтобы он указывал на новый LDAP-каталог, используя такую последовательность действий:

Создайте реплику базы данных Directory Assistance с сервера Sametime на сервер QuickPlace; все параметры DA уже были установлены на сервере Sametime.

Документ Server на серверах QuickPlace в Domino Directory необходимо обновить таким образом, чтобы он указывал на новую базу данных Directory Assistance. Как говорилось выше, это задается через поле Directory Assistance на вкладке Basics документа Server.

Выполните вход на сервер QuickPlace через интерфейс браузера под учетной записью администратора.

http://itsosec-qp.cam.itso.ibm.com/quickplace

Выберите Server Settings (Параметры сервера).

Выберите User Directory (Пользовательский каталог).

Выберите Change Directory (Сменить каталог).

Выберите тип LDAP Server (LDAP-сервер).

Введите полное имя хоста для LDAP-сервера в поле Name (Имя). В нашей среде было задано имя itsosec-ldap.cam.itso.ibm.com

В поле Port Number (Номер порта) было введено 389 (стандартное значение для LDAP).

В качестве базы поиска должен быть установлен уровень LDAP, на котором следует начинать поиск пользователей. В нашей среде было задано значение o=redbooks,c=us.

Эти изменения представлены на рис. 14.35.

(рис 14.35) Изменение пользовательского каталога

Необходимо добавить отличительные имена LDAP для всех пользователей, которые будут администраторами QuickPlace, в ACL баз данных Main.nsf и Admin.nsf с полными административными правами.

Например, пользователю Matt Milza в Domino Directory соответствует полное имя Matt Milza/West/Redbooks, тогда как в LDAP-каталоге его имя имеет вид uid=mmilza/ou=admin/o=redbooks/c=us. Это имя пользователя LDAP необходимо добавить в Domino Directory, чтобы пользователь Matt Milza мог продолжать администрировать QuickPlace после вступления в действие изменений в LDAP.

Это изменение является необходимым, так как QuickPlace все еще работает в базе Domino 5.x; как говорилось выше, Domino 5.x не поддерживает постановку в соответствие имен LDAP. Поэтому необходимо использовать отличительные имена LDAP в ACL баз данных.

На рис. 14.36 представлен пример ACL базы данных main.nsf.

(рис 14.36) Имя пользователя LDAP в ACL

14.4 Установка WebSphere Portal

На данном этапе сценария выполняется настройка портала путем установки и интеграции инфраструктуры IBM WebSphere Portal. Этот этап демонстрирует работу функций единой регистрации между продуктами WebSphere и Lotus.

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

Новая среда представлена на рис. 14.37.

Для создания среды портала была выполнена установка WebSphere Portal Extend на базовом сервере Windows 2000 Service Pack 3 с локальной базой данных DB2 на том же сервере.

Подробные сведения об установке LMS см. в книге WebSphere Portal Handbook Volume 1, SG24-6883.

14.4.1 Обновление конфигураций SSO

На сервере WebSphere Portal была настроена единая регистрация. Для этого нужно выполнить следующие действия:

14.4.2 Настройка обратного прокси-сервера на поддержку портала

Обратный прокси-сервер необходимо настроить таким образом, чтобы он поддерживал WebSphere Portal, а также сервер Domino. Это выполняется путем изменения раздела маршрутизации запросов в файле ibmproxy.conf, чтобы он распознавал URL портала и корректно передавал их на сервер портала.

В нашей среде были изменены следующие явные правила:

После внесения этих изменений в conf-файл необходимо перезапустить службу прокси-сервера.

14.5 Добавление возможностей электронного обучения

На данном этапе выполняется добавление возможностей электронного обучения в инфраструктуру путем добавления системы IBM Lotus Learning Management System (LMS).

Для создания среды электронного обучения Learning Management System 1.01 была установлена на базовом сервере Windows 2000 Service Pack 3. Система LMS была установлена на одном сервере вместе со всеми службами LMS, функциями баз данных DB2 и службами WebSphere 5.

Подробные сведения о настройке LMS см. в руководстве IBM Lotus Learning Management System Handbook, SG24-7028.

Примечание. Необходимо отметить тот факт, что LMS внедряет WebSphere Application Server v5.0 в инфраструктуру. Это демонстрирует, что технологии на основе Lotus Domino могут успешно сосуществовать в единой защищенной системе единой регистрации с технологиями на основе WebSphere 4 и WebSphere 5.

14.5.1 Настройка единой регистрации в LMS

Включение функций единой регистрации на сервере LMS выполняется посредством выполнения следующих действий:

Войдите в административную консоль WebSphere Application Server на LMS-сервере под учетной записью с административными правами. В WebSphere 5 реализована новая административная консоль на основе браузера, в отличие от Web-Sphere 4, где используется Java-консоль.

Выберите Security (Безопасность) -> Authentication Mechanisms (Механизмы аутентификации) -> LTPA в административной консоли WebSphere.(рис 14.41) LMS LTPA

Введите пароль для LTPA-токена WebSphere, созданного при установке портала WebSphere, а также введите расположение файла LTPA-токена, чтобы его можно было импортировать. Вам может потребоваться скопировать этот файл с сервера WebSphere Portal на LMS-сервер.

Нажмите Import Keys (Импортировать ключи); импортирование LTPA-ключа должно пройти успешно.

Нажмите Save (Сохранить), чтобы выполнить сохранение изменений конфигурации (рис 14.42(рис 14.42) Сохранение изменений в LTPA

Нажмите Save (Сохранить), чтобы применить изменения, после чего убедитесь в том, что SSO работает в LMS; для этого сначала войдите в Domino или WebSphere Portal, после чего вызовите интерфейс LMS (рис 14.43(рис 14.43) Применение изменений

14.5.2 Установка портлетов LMS

После того как мы убедились, что LMS функционирует должным образом, и интегрировали его в среду единой регистрации с WebSphere Portal, была выполнена установка LMS-портлетов в WebSphere Portal, чтобы можно было осуществлять доступ к LMS напрямую из портала. Этот этап позволяет провести более полную проверку функций SSO, так как пользователь выполняет аутентификацию в WebSphere Portal, который, в свою очередь, принимает учетные данные пользователя и выполняет аутентификацию на LMS-сервере от имени пользователя.

Установка портлетов

Вместе с LMS поставляются три портлета для доступа к LMS из портала WebSphere (My Courses, Search Catalog и My Calendar). Для установки портлетов в WebSphere Portal, следует выполнить следующие действия:

Конфигурирование портлетов

После установки портлетов в портале WebSphere их необходимо настроить таким образом, чтобы они указывали на LMS-сервер и интерфейс Web-служб LMS-сервера, через который эти портлеты взаимодействуют с LMS. Для этого следует выполнить следующие действия:

14.6 Добавление Tivoli Access Manager

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

К сожалению, время, выделенное для создания этого курса, не позволило нам в полной мере реализовать и протестировать этот этап в нашей тестовой среде. Таким образом, описанные здесь процедуры представляют собой отраслевые рекомендации, которые не были в полной мере протестированы командой Redbook. Это не означает, что они не работают, однако при их использовании в вашей тестовой среде следует быть осторожным.

14.6.1 Установка Tivoli Access Manager

На данный момент наша среда содержит WebSphere Edge Server на основе обратного прокси-сервера, обрабатывающего запросы ко всем службам совместной работы на основе Domino и WebSphere Portal в нашей среде. Необходимо решить, каким образом следует выполнить внедрение Tivoli Access Manager (TAM).

Хотя TAM содержит компонент прокси-сервера безопасности WebSeal, этот компонент как бы то ни было представляет собой полнофункциональный RPSS (обратный прокси-сервер с дополнительными компонентами безопасности). Более подробное описание прокси-серверов и их компонентов см. в лекции 5, "Прокси-серверы". Так как у нас уже есть установленный и запущенный сервер IBM Websphere Edge Server, мы бы предпочли не изменять полностью всю конфигурацию прокси-сервера, чтобы включить в нее Tivoli WebSeal. Поэтому мы решили установить подключаемый модуль безопасности Tivoli для WebSphere Edge Server, который также иногда называют Web-Seal-Lite.

Таким образом, прежде чем мы сможем выполнить интеграцию нашей существующей среды, следует установить новый сервер Tivoli Access Manager, после чего произвести установку подключаемого модуля WebSeal-Lite на нашем обратном проксисервере. Подробные сведения об установке и настройке Tivoli Access Manager см. в Tivoli Information Center по адресу:

http://publib.boulder.ibm.com/tividd/td/IBMAccessManagerfore-business4.1.html

После установки Tivoli Access Manager необходимо интегрировать его в нашу среду, чтобы Tivoli Access Manager обрабатывал всю аутентификацию.

14.6.2 Установка подключаемого модуля WebSeal для Websphere Edge Server

Для установки и конфигурирования подключаемого модуля WebSeal-Lite на нашем обратном прокси-сервере, следует выполнить следующие действия:

Эта утилита конфигурирования выполняет следующие задачи:

Затем утилита конфигурирования запускает подключаемый модуль для утилиты управления пространством объектов Edge Server с использованием команды wesosm. Эта утилита обновляет пространство объектов Tivoli Access Manager в целях создания нового контейнера пространства объектов для подключаемого модуля для Edge Server.

На этом настройка подключаемого модуля Edge Server завершена. Кеширующий прокси-сервер Edge Server должен выполняться с загруженным подключаемым модулем для Edge Server. Учетную запись административного пользователя sec_master можно применить для доступа к домашней странице кеширующего прокси-сервера.

14.6.3 Интеграция серверов на основе Domino с TAM

Для интеграции служб на основе Lotus Domino (Domino, Sametime, QuickPlace и т. д.), чтобы можно было продолжать передавать cookie-файл SSO LTPA в Domino для единой регистрации, необходимо создать соединение между подключаемым модулем IBM Tivoli WebSeal на обратном прокси-сервере и серверами Domino заднего плана. Это осуществляется путем выполнения следующих действий:

commands:
pdadmin>login
Enter User ID:sec_master
Enter Password:
pdadmin>server list
webseald-webseal39
pdadmin>server task webseald-webseal39 create -t tcp -h
itsosec-dom.cam.itso.ibm.com -p 80 -A -F c:\Lotus\Domino\Keys\amdom.key -Z
mercury1 -j /domino
Created junction at /domino
pdadmin>

Этот процесс затем повторяется для всех серверов Domino, Sametime и QuickPlace в среде. В нашем тестовом сценарии эта команда выполняется три раза, для каждого из трех серверов Domino, с изменением имени соединения:

itsosec-dom.cam.itso.ibm.com -p 80 -A -F c:\Lotus\Domino\Keys\amdom.key -Z
mercury1 -j /domino
itsosec-st.cam.itso.ibm.com -p 80 -A -F c:\Lotus\Domino\Keys\amdom.key -Z
mercury1 -j /sametime
itsosec-qp.cam.itso.ibm.com -p 80 -A -F c:\Lotus\Domino\Keys\amdom.key -Z
mercury1 -j /quickplace

14.6.4 Интеграция WebSphere Portal с TAM

После интеграции служб на основе Domino с TAM путем создания WebSeal-соединений нужно выполнить следующие действия, чтобы обеспечить аутентификацию Websphere Portal с использованием Tivoli Access Manager:

c:\progra~1\Tivoli\POLICY~1\sbin\%WAS_HOME%\java\jre\bin\java
com.tivoli.pd.jcfg.SvrSslCfg -action config -admin_id sec_master
-admin_passwd password -appsvr_id itsosec-tam_amwps -mode remote
-port 7201
-policysvr itsosec-tam.cam.itso.ibm.com:7135:1 -authzsvr
itsosec-tam.cam.itso.ibm.com:7136:1 -cfg_file
"c:\websphere\appserver\java\jre\PDPerm.properties" -key_file
"c:\websphere\appserver\java\jre\lib\security\pdperm.ks" -cfg_action
create

WpsNewSubject {
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.GetCORBACredentialLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.CORBACredentialLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.UserDNGroupDNLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.UserIdPasswordLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.UserIdPrincipalLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.PasswordCredentialLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.LTPATokenLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.tivoli.mts.PDLoginModule;
};
WpsSubjectExists {
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.GetCORBACredentialLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.CORBACredentialLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.ibm.wps.sso.LTPATokenLoginModule;
com.ibm.websphere.security.auth.module.proxy.WSLoginModuleProxy
required delegate=com.tivoli.mts.PDLoginModule;
};

После выполнения этих действий вся среда совместной работы, построенная в этой лекции, будет надежно защищена новой службой безопасности Tivoli Access Manager (с использованием подключаемого модуля WebSphere Edge Server) с точки зрения аутентификации.

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

14.7 Заключение

В этой лекции мы представили действительные процедуры, использовавшиеся командой Redbook для реализации сценария "защищенной совместной работы" RedbooksCo в тестовой среде Redbooks. Эти процедуры можно использовать как отправную точку для реализации подобного сценария в вашей среде.