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

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

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

• при запросе Select Proxy Behavior (Выберите режим прокси-сервера) было выбрано значение Reverse Proxy (Обратный прокси-сервер);
• при запросе Select Proxy Port (Выберите порт прокси-сервера) было введено значение 80;
• при запросе Target Web Server (Целевой Web-сервер) в качестве основного входящего URL был установлен itsosec-dom.cam.itso.ibm.com.

После этого был запущен интерфейс администрирования 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-заголовке. Это предотвращает кеширование динамического содержимого, которое не следует кэшировать. Для максимизации кеширования был добавлен фильтр *//itsosec-dom.cam.itso.ibm.com/* в WebSphere Edge Server, что показано на рис. 14.15.
  

  
  Рис. 14.15. Параметры фильтра кеширования
• Раздел Last Modified Factor (Показатель последнего изменения) позволяет осуществлять более точный контроль времени действия явно заданных элементов дизайна Domino, кешируемых локально на сервере Edge. Двумя основными изначально сконфигурированными элементами являются URL-запросы ?OpenImageResource и ?OpenElement&FieldElemFormat=gif. Они представляют изображения в Domino, однако прокси-сервер по умолчанию не воспринимает их как изображения (которые должны кешироваться на больший срок, чем просто стандартный HTML). Эти изменения представлены на рис. 14.16.
  

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

  
  Рис. 14.17. Основные параметры
• Раздел HTTP Methods (HTTP-методы) позволяет определить типы запросов, обслуживаемые сервером Edge. Единственными типами запросов, требующими обработки в Domino, являются запросы GET, HEAD и POST. Обработка других запросов не нужна и может создать риск для безопасности, поэтому они отключены. Параметры представлены на рис. 14.18.
  

  
  увеличить изображение
  Рис. 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.

увеличить изображение
Рис. 14.19. Маршрутизация запросов

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

• SignificantUrlTerminator ?OpenImageResource;
• SignificantUrlTerminator ?OpenElement;
• SignificantUrlTerminator /?OpenImageResource;
• SignificantUrlTerminator /?OpenElement;
• fail /*;
• Reversepass http://192.168.0.3/* http://itsosec-dom.cam.itso.ibm.com/*.

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

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

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

Рис. 14.20. Неавторизованный пользователь

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

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

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

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

увеличить изображение
Рис. 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.22. 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.