Введение

В системах на основе SOA приложения могут охватывать несколько доменов администрирования пользователей. Управление идентификационными данными пользователей, принадлежащих разным доменам, является одной из существенных проблем в обеспечении безопасности архитектуры SOA. В этой статье предлагается решение для распространения идентификационной информации по уровням традиционного J2EE-приложения, в котором подключение к базе данных требует аутентификации. Основные принципы предлагаемого решения могут использоваться и в более сложных комбинированных приложениях.

Приложения J2EE, работающие с реляционными базами данных через интерфейс JDBC, часто используют для соединения с БД единственного пользователя вместо того, чтобы подключаться под учетными записями конкретных пользователей, что позволило бы точнее отслеживать их действия с данными. Разработчики часто объясняют подобный подход соображениями производительности системы.

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

В этой статье предлагается решение на основе Tivoli Federated Identity Manager Security Token Service (TFIM STS) и Tivoli Access Manager Global Sign-On (TAM GSO) для сопоставления учетных записей пользователей уровня сервера приложений с теми, которые используются при соединении с базой данных. Для обеспечения подобной связи приложение J2EE, выполняющееся в сервере приложений WebSphere® (WAS), вызывает модуль аутентификации JAAS для извлечения учетной записи для доступа к БД. Этот модуль создает запрос WS-Trust и отправляет его системе TFIM STS для получения идентификационных данных пользователя. В свою очередь TFIM STS через модуль сопоставления TAM GSO обращается к TAM для получения учетной записи, служащей для подключения к базе данных. Наконец, TFIM отправляет эту информацию обратно WAS и J2EE-приложению.

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

Получение компонентов предлагаемого решения

Компоненты комплексного решения, предлагаемого в статье, могут быть загружены с сайта IBM Support. Ссылки на конкретные ресурсы приведены в разделе "Ресурсы" в конце статьи.

Модуль аутентификации JAAS, входящий в состав TFIM, содержится в интеграционном пакете "TFIM 6.1 CICS Integration Pack".

Обратите внимание, что этот компонент не зависит от CICS®.

Модуль сопоставления TAM GSO входит в состав модуля TFIM 6.1 STS для TAM GSO.

Обзор модуля JAAS-аутентификации FIMPrincipalMapper

В описании источника данных JDBC в ресурсах приложения следует указать, что нужно использовать JAAS для получения параметров учетной записи для подключения к базе данных. Именно эта возможность используется классом FIMPrincipalMapper. Перед попыткой подключения к источнику данных приложение вызывает цепочку аутентификации JAAS, включающую модуль FIMPrincipalMapper. Этот модуль создает запрос WS-Trust с использованием существующего пользователя (принципала) JAAS. Принципал указывается в поле UsernameToken вместе с информацией о назначении и точке возникновения запроса (атрибуты AppliesTo и Issuer.

Затем этот запрос отправляется сервису TFIM STS, который задается в специальном свойстве stsendpoint. После получения ответа от сервиса модуль аутентификации JAAS сохраняет параметры учетной записи (возвращенные в поле UsernameToken) в виде субъекта JAAS. Затем эти параметры используются приложением при подключении к базе данных через JDBC.

Обзор сервиса TFIM STS

TFIM STS представляет собой сервис, удовлетворяющий спецификации WS-Trust, который проверяет, обменивает и выдает токены безопасности. Сервис содержит набор сконфигурированных цепочек модулей, известных как "цепочки доверенности" (Trust Chain). В состав сервиса может входить множество цепочек. Сервис определяет, какая из цепочек должна быть вызвана, на основе атрибутов AppliesTo и Issuer в запросе.

Каждая цепочка доверенности включает в себя один или несколько модулей, которые проверяют, связывают, выдают или обменивают токены. Стандартная цепочка имеет следующий вид:

Модули Validate (проверка) и Issue (выдача), как правило, зависят от типа токена, например, UsernameToken, X509 или SAML. В свою очередь, модуль Map выполняет преобразование на основе страницы XSL.

FIMPrincipalMapper, использующийся в этой статье, отправляет и получает токены Username (имя пользователя), поэтому Validate и Issue должны быть модулями UsernameToken. Что касается модуля Map, то его роль будет выполнять модуль сопоставления системы TAM GSO.

Обзор модуля сопоставления системы TAM GSO

Этот модуль представляет собой специализированный модуль TFIM STS, настроенный таким образом, чтобы выполнять функцию сопоставления. Настройка модуля выполняется при помощи консоли управления TFIM. Конфигурационные параметры перечислены в таблице 1.

Этот модуль работает следующим образом: вначале он извлекает значение элемента name из полученного документа STS Universal User. Затем, используя API администрирования TAM, он получает параметры учетной записи пользователя из базы данных TAM. Имя пользователя и пароль сохраняются в атрибутах  Username, name и Password документа STS Universal User.

Подготовка к работе

Перед началом работы необходимо убедиться, что у вас установлены и настроены компоненты, перечисленные в таблице 2.

В образовательных целях рекомендуется установить tcpmon или аналогичный TCP-прокси, позволяющий анализировать запросы WS-Trust, поступающие от JAAS-модуля FIMPrincipalMapper к сервису TFIM STS.

Демонстрационная среда

Структура демонстрационной среды, используемой в этой статье, показана на рисунке 3.

Настройка статической учетной записи для доступа к базе данных

Перед тем как приступить к реализации сложной схемы с использованием сопоставления учетных записей для доступа к базе данных, необходимо наладить работу базы данных с одним статическим пользователем. Эти действия описываются  в данном разделе. Если у вас уже есть готовая к работе база данных, настроенное JDBC-соединение и механизм выполнения запросов (аналогичный JSP-приложению к этой статье), то вы можете сразу переходить к разделу Динамическое сопоставление учетных записей для доступа к базе данных.

Создание базы данных

В нашей демонстрационной системе серверным источником данных будет служить база данных DB2. Вы можете использовать любой источник данных, поддерживающий JDBC-соединения, с которым может работать WAS. При этом важно убедиться, что права на доступ к данным имеет только определенный круг пользователей.

В этом примере создается база данных, принадлежащая серверу db2admin, а затем права на доступ предоставляются пользователю webappsvr. Этот пользователь должен быть предварительно создан в системе (в данном примере его паролем является passw0rd).  Весь процесс состоит из следующих шагов:

1. запуск менеджера баз данных;
2. создание базы данных;
3. подключение к базе данных;
4. создание таблицы;
5. добавление записей в таблицу;
6. предоставление прав на доступ к таблице.

Последовательность команд, выполняющих эти действия, приведена в листинге 1.

        
# su - db2admin
$ db2start
$ db2
db2 => create database sampledb
DB20000I  The CREATE DATABASE command completed successfully. db2 => connect to sampledb

   Database Connection Information

 Database server        = DB2/LINUX 8.2.1
 SQL authorization ID   = DB2ADMIN
 Local database alias   = SAMPLEDB

db2 => create table employees ( id smallint, name varchar(50) )
DB20000I  The SQL command completed successfully.
db2 => insert into employees values ( 1, 'paul' )
DB20000I  The SQL command completed successfully.
db2 => insert into employees values ( 2, 'alison' )
DB20000I  The SQL command completed successfully.
db2 => insert into employees values ( 3, 'emily' )
DB20000I  The SQL command completed successfully.
db2 => select * from employees

ID     NAME
------ --------------------------------------------------
     1 paul
     2 alison
     3 emily

  3 record(s) selected.

db2 => grant select on employees to user webappsvr
DB20000I  The SQL command completed successfully.
      

Настройка источника данных JDBC

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

• Псевдоним J2C, представляющий собой статически заданные имя пользователя и пароль для доступа к базе данных. Эти параметры будут изменены позже.
• Провайдер JDBC для конкретного типа базы данных.
• Источник данных, использующий вышеуказанный провайдер.

Использование J2C-псевдонимов - это классический способ аутентификации для доступа к источникам данных J2EE. В них статически указываются имя пользователя и пароль. В данном примере таковыми являются webappsvr/passw0rd. Для создания псевдонима в WAS 6.1 выполните следующие действия:

1. Войдите в консоль администрирования WebSphere по адресу https://WAS_HOST:9043/ibm/console
2. Выберите пункт меню Security (безопасность) -> Secure administration, applications, and infrastructure (безопасное администрирование, приложения и инфраструктура) -> Java Authentication and Authorization  Service (сервис аутентификации и авторизации Java) -> J2C authentication data (параметры аутентификации Java).
3. Нажмите на кнопку New.
4. Введите параметры учетной записи пользователя webappsvr (пример приведен в таблице ниже).
5. Нажмите OK и сохраните настройки.

После определения псевдонима J2C необходимо настроить JDBC-провайдер для вашей СУБД в WAS (если это не было сделано ранее). Вначале выполните следующие подготовительные действия:

• Убедитесь, что СУБД и провайдер JDBC поддерживаются WAS (более подробная информация приведена в информационном центре IBM).
• Создайте и настройте базу данных и таблицы, чтобы убедиться, что вы можете подключаться к БД при помощи средств, предоставляемых поставщиком СУБД.
• Установите клиентские драйверы к СУБД на компьютере, где работает WAS, который будет подключаться к базе данных. Как правило, для этого следует скопировать JAR-файлы с узла, на котором размещена база данных. Для DB2 все файлы находятся в директории DB2_HOME/java.

Для создания JDBC-провайдера в WAS 6.1 выполните следующие шаги:

1. Войдите в консоль администрирования WAS по адресу https://WAS_HOST:9043/ibm/console
2. Выберите пункт Resources (Ресурсы) -> JDBC -> JDBC Providers (провайдеры JDBC).
3. Измените область действия (scope) на Node=node-name, Server=server1
4. Нажмите New.
5. Выберите опции, указанные в таблице ниже.
   
   

   Параметр	Значение
   Database type (тип базы данных)	DB2
   Provider type (тип провайдера)	DB2 Universal JDBC Driver Provider
   Implementation type (тип реализации)	Connection pool datasource
   Name (имя провайдера)	DB2 Universal JDBC Driver Provider
   Description (описание)	Оставьте в этом поле значение по умолчанию, если вам не требуется специальное описание провайдера

   
   
   
6. Нажмите Next.
7. Выберите в поле Class path (путь к классам) директорию узла WAS, в которую вы скопировали клиентские драйверы. В WAS этот путь должен быть значением переменной подстановки ${DB2UNIVERSAL_JDBC_DRIVER_PATH}. Например, драйверы могут храниться в /opt/IBM/db2/V8.1/java. Значение переменной ${DB2UNIVERSAL_JDBC_DRIVER_NATIVEPATH}, которая хранит путь к платформенно-зависимым библиотекам, можно оставить пустым.
8. Нажмите Next.
9. Проверьте правильность настроек и нажмите Finish.
10. Сохраните настройки и перезапустите сервер приложений.

Далее следует создать источник данных для JDBC-провайдера. Выполните следующие действия:

1. Войдите в консоль администрирования WAS и выберите только что созданный провайдер (пункт Resources -> JDBC -> JDBC Providers).
2. В разделе Additional Properties (дополнительные свойства) нажмите на ссылку Data sources (источники данных).
3. Нажмите New.
4. Введите JNDI-имя, например, jdbc/sampledb. Несмотря на то, что псевдоним для аутентификации будет переопределен в ресурсах приложения, имеет смысл выбрать ранее созданный J2C-псевдоним в целях отладки. Выберите имя пользователя webappsvr в поле Component-managed authentication alias and XA recovery authentication alias (псевдоним аутентификации, управляемый компонентом, и псевдоним аутентификации ХА).
5. Нажмите Next.
6. Укажите конфигурационные параметры вашей базы данных. Примеры приведены в таблице ниже.
   
   

   Параметр	Значение
   Database name (имя базы данных)	sampledb
   Driver type (тип драйвера)	4
   Server name (имя сервера)	rhel-ldap.dp.gc.au.ibm.com
   Port number (номер порта)	3700 Замечание: по умолчанию DB2 использует 50000
   Use this datasource in container managed persistence (использовать этот источник данных для долговременного хранения объектов, управляемого контейнерами)	установлен

   
   
   
7. Нажмите Next.
8. Проверьте настройки на сводной странице и нажмите Finish.
9. Сохраните настройки.
10. Перейдите на страницу с источниками данных (Resources -> JDBC -> Data sources), выберите только что созданный источник данных JDBC и нажмите на кнопку Test Connection (проверка соединения). Проверка должна завершиться успешно, не выдав никаких сообщений об ошибках. Если выдано сообщение об ошибках, их необходимо исправить до перехода к следующему шагу.

Установка демонстрационного приложения

Для установки демонстрационного приложения, которое работает с источником данных JDBC, выполните следующие действия:

1. Войдите в консоль администрирования WAS.
2. Выберите пункт Applications (приложения) -> Install New Application (установка нового приложения).
3. Укажите путь к каталогу, в котором находится файл JDBCWebApp.war.
4. Укажите корневой каталог приложения (Context root), например, JDBCWebApp.
5. Нажмите Next.
6. Подтвердите параметры установки, нажав Next.
7. Укажите серверы, на которых должно быть развернуто приложение и подтвердите сопоставление модулей и серверов, нажав Next.
8. На странице Resource reference нажмите на кнопку Browseпод текстовым полем, указывающим на модуль JDBCWebApp в столбце Target Resource JNDI Name (JNDI-имя целевого ресурса). Выберите ранее созданный источник данных и нажмите Apply. Имя источника данных должно появиться в текстовом поле.
9. Не уходя с этой страницы, выделите галочкой модуль JDBCWebApp. В поле Specify authentication method (метод аутентификации) укажите Use default method (many-to-one mapping) (метод по умолчанию, связь типа "многие-к-одному"), а затем выберите псевдоним J2C, соответствующий ранее созданному пользователю базы данных (webappsvr). Нажмите на кнопку Apply в секции Specify authentication method.
   
   Рисунок 6. Указание псевдонима для статической аутентификации
   
   
   
10. Нажмите Next.
11. Проверьте правильность настроек и нажмите Finish.
12. Подождите завершения установки и сохраните настройки.
13. Теперь приложение должно появиться в списке установленных приложений (Applications -> Enterprise Applications).
14. Далее следует описать роли (security roles). Для этого нажмите на JDBCWebApp_war в списке установленных приложений, затем — на Security role to user/group mapping (связи между ролями и пользователями/группами), после чего выставите флаг All authenticated? (все аутентифицированные пользователи). Теперь данную роль имеют все аутентифицированные пользователи. Ниже мы изменим этот параметр, чтобы только определенные пользователи могли обращаться к JSP-странице.
    
    Рисунок 7. Первоначальное присвоение ролей пользователям и группам
    
    
    
15. Нажмите OK для сохранения настроек.
16. Запустите приложение, выбрав его из списка установленных приложений и нажав на кнопку Start. Вы должны увидеть сообщение об успешном запуске, а приложение должно быть отмечено зеленой стрелкой (признак удачного запуска).

Если вдруг вы получили ошибку с кодом 500 (внутренняя ошибка сервера) при обращении к DB2 со стороны JSP, это может быть следствием проблемы APAR LI70602. Проблема заключается в том, что некоторые драйверы JDBC JCC для DB2 выдают исключения при попытке получения сообщений об ошибках от сервера БД. Страница JSP не может перехватить подобные исключения, поэтому выполнение завершается аварийно. Для устранения этой проблемы следует установить последний набор исправлений или установить значение параметра retrieveMessagesFromServerOnGetMessage в false. Более подробная информация приведена по ссылке http://www-1.ibm.com/support/docview.wss?uid=swg1LI70602.

Динамическое сопоставление учетных записей для доступа к базе данных

Далее мы рассмотрим динамическое определение учетной записи, под которой следует выполнить подключение к базе данных, при помощи модуля аутентификации JAAS, обращающегося к сервису TFIM STS. Этот сервис отвечает за сопоставление учетных записей с использованием ресурсов TAM GSO. В результате работы этой схемы учетные записи передаются серверу приложений и используются для соединения с базой данных.

Конфигурирование ресурсов GSO в TAM

Если это не было сделано ранее, вам следует установить и настроить сервер политик и авторизации TAM (TAM Policy Server and Authorization Server). Инструкции по выполнению этих действий содержатся в документации TAM. Завершив установку и конфигурирование сервера, выполните следующие действия:

1. Создайте учетную запись в TAM, соответствующую Web-пользователю, имеющему право на доступ к JSP. Не забудьте установить опцию -gsouser.
   
   Листинг 2. Создание Web-пользователя в TAM
   

   # pdadmin -a sec_master pdadmin sec_master> user create -gsouser webuser1 cn=webuser1,o=ibm,c=au "Web User" User passw0rd pdadmin sec_master> user modify webuser1 account-valid yes

   
   
2. Создайте ресурс GSO и учетную запись Web-пользователя для доступа к этому ресурсу.
   
   Листинг 3. Создание ресурса GSO и учетной записи пользователя
   

   pdadmin sec_master> rsrc create backend_database pdadmin sec_master> rsrccred create backend_database rsrcuser dbuser1 rsrcpwd passw0rd rsrctype web user webuser1

   
   

Настройка цепочки доверенности TFIM STS

Сервис TFIM STS обращается к TAM и выполняет сопоставление учетных записей пользователей. Он получает запрос WS-Trust от модуля аутентификации JAAS сервера приложений, в котором развернуто приложение JDBC. Этот запрос включает токен, содержащий имя аутентифицированного пользователя в WAS. Далее вызывается модуль TAM GSO STS для сопоставления этой учетной записи и пользователя базы данных. В итоге учетная запись пользователя базы данных передается серверу приложений в виде токена Username, содержащего имя пользователя и пароль.

К этому моменту домен и среда выполнения TFIM должны быть настроены и готовы к работе.

1. Вначале следует установить модуль TAM GSO STS.
   • Поместите файл tamgso_sts_module.jar во временную директорию, а затем распакуйте его в директорию подключаемых модулей (плагинов) TFIM.
     
     Листинг 4. Помещение модуля TAM GSO STS в директорию плагинов TFIM
     

     # cd /opt/IBM/FIM/plugins # /opt/IBM/WebSphere/AppServer/java/bin/jar -xvf /wdir/tamgso_sts_module.jar created: META-INF/ extracted: META-INF/MANIFEST.MF created: com.tivoli.am.fim.tamgsoplugin_1.0/ extracted: com.tivoli.am.fim.tamgsoplugin_1.0/module.xml extracted: com.tivoli.am.fim.tamgsoplugin_1.0/tam_gso_classes.jar # ls -al com.tivoli.am.fim.tamgsoplugin_1.0/ total 25 drwxr-xr-x 2 root root 120 Oct 24 07:30 . drwxr-xr-x 17 root root 808 Oct 24 07:30 .. -rw-r--r-- 1 root root 2648 Oct 24 07:30 module.xml -rw-r--r-- 1 root root 17703 Oct 24 07:30 tam_gso_classes.jar

     
     
   • Чтобы консоль могла отображать названия модулей, соответствующие классы меток должны находиться в ее classpath. Скопируйте файл tam_gso_classes.jar  в следующую директорию на компьютере, на котором развернута ISC: ISC_HOME/PortalServer/installedApps/FIMConsole_*.ear/*.war/WEB-INF/lib/tam_gso_classes.jar . Перезапустите ISC, чтобы консоль загрузила классы.
   • TFIM необходимо указать, что произошли изменения в списке подключаемых модулей. Отредактируйте файл software.properties в директории FIM_HOME/pkg, увеличив значение свойства com.tivoli.am.fim.rte.software.serialId на единицу.
   • Развертывание новой среды выполнения производится при помощи ISC. Войдите в консоль и перейдите в раздел управления доменами (Tivoli Federated Identity Manager -> Domain Management (управление доменами) -> Runtime Node Management (управление средами выполнения узлов)). Вы должны увидеть сообщение о доступности новой среды выполнения. Нажмите на кнопку Deploy Runtime (развертывание среды выполнения) и перезапустите сервер.
2. Далее необходимо настроить TFIM таким образом, чтобы новый модуль был доступен для сервиса TFIM STS.
   • Войдите в ISC и перейдите в раздел Tivoli Federated Identity Manager -> Configure Trust Service (настройка сервиса доверенности) -> Module Types (типы модулей).
   • Нажмите на кнопку Create, введите параметры, приведенные в таблице ниже, и нажмите OK.
     
     

     Параметр	Значение
     Module Name (имя модуля)	com.tivoli.am.fim.sts.tamgso
     Module Version Number (версия модуля)	1.0
     Exposed Class ID (идентификатор класса для обращения извне)	TAMGSOSTSModule

     
     
     
     
     Рисунок 9. Определение типа модуля сопоставления TAM GSO
     
     
     
   • Перезапустите сервер (среду выполнения TFIM).
3. Создайте экземпляр модуля TAM GSO, чтобы он мог вызываться компонентами цепочки доверенности, выполнив следующие шаги:
   • Войдите в раздел Tivoli Federated Identity Manager -> Configure Trust Service -> Module Instances (экземпляры модулей) консоли ISC и нажмите Create.
   • Выберите тип TAMGSOSTSModule и нажмите Next.
     
     Рисунок 10. Создание экземпляра модуля TAM GSO для сопоставления учетных записей
     
     
     
   • Введите имя и описание экземпляра по вашему усмотрению и нажмите Finish.
   Те же действия должны быть выполнены для экземпляра модуля Username Token. В данном случае типом модуля должен быть указан UsernameTokenSTSModule.
4. Далее следует создать цепочку доверенности (Trust Service Chain), которая будет принимать запросы на сопоставление учетных записей. Это делается следующим образом.
   • Войдите в ISC, перейдите в раздел Tivoli Federated Identity Manager -> Configure Trust Service -> Trust Service Chains и нажмите Create.
   • Прочитайте вводную информацию и нажмите Next.
   • Задайте имя цепочки, например UT-TAMGSO-UT, и нажмите Next.
   • Оставьте в качестве типа запроса значение Validate и укажите значения остальных параметров, как показано в таблице ниже. Запомните адреса Applies To и Issuer, поскольку они понадобятся при конфигурировании JAAS-модуля FIMPrincipalMapper (см. рисунок 15).
     
     

     Параметр	Значение
     Applies To Address	http://appliesto/tamgso
     Issuer Address	http://issuer/websphere

     
     
     
     
     Рисунок 11. Указание параметров "Issuer" и "AppliesTo" для цепочки доверенности
     
     
     
   • Нажмите Next.
   • Добавьте модули, перечисленные в таблице ниже, указав соответствующие режимы работы (mode).
     
     

     Порядковый номер	Экземпляр	Тип	Режим
     1	UTModuleInstance	UsernameTokenSTSModule	validate
     2	TAMGSOInstance	TAMGSOSTSModule	map
     3	UTModuleInstance	UsernameTokenSTSModule	issue

     
     
     
     
     Рисунок 12. Задание токенов цепочки доверенности
     
     
     
   • Нажмите Next.
   • Для модуля Username Tokern, работающего в режиме validate, установите флаг Skip password validation (пропускать проверку пароля) и нажмите Next.
   • Для модуля TAM GSO STS, отвечающего за сопоставление (mapping), следует указать данные среды выполнения. Вы можете использовать автоматически сгенерированные параметры, находящиеся в файле WAS_HOME/profiles/PROFILE_NAME/config/itfim/TFIM_DOMAIN_NAME/nodes/CELL_NAME/NODE_NAME/server1/amconfig.conf . В демонстрационном приложении используются значения, перечисленные в таблице ниже.
     
     

     Параметр	Значение
     The TAM Administrative user, default: sec_master (администратор TAM, по умолчанию: sec_master)	sec_master
     The TAM Administrative user password (пароль администратора TAM)	passw0rd
     The URL that points to the TAM configuration file amconfig.conf, example: file:///var/amwas/amconfig.conf (URL, указывающий на конфигурационный файл ТАМ, например file:///var/amwas/amconfig.conf).	file:///opt/IBM/WebSphere/AppServer/profiles/AppSrv01/config/itfim/sles9-fim61-server1/nodes/sles9-fim61Node01Cell/sles9-fim61Node01/server1/amconfig.conf
     The TAM GSO resource name (имя ресурса TAM GSO)	backend_database

     
     
     
     
     Рисунок 13. Настройки цепочки доверенности модуля TAM GSO
     
     
     
   • Нажмите Next.
   • Убедитесь, что модуль Username Token, занимающийся выдачей токенов (режим issue), отправляет пароли в виде простого текста. При необходимости измените значение параметра Options for including password in the token (опции включения пароля в токен) на 3  и нажмите Next.
   • Проверьте правильность параметров на итоговой странице и нажмите Finish.
   • Перезапустите среду выполнения TFIM.

Настройка WAS для использования TFIM STS

Сервер приложений, в котором развернута JSP, должен быть настроен таким образом, чтобы он получал учетные записи пользователей для доступа к базе данных через TFIM STS. Для этого следует создать цепочку аутентификации JAAS. В данном случае она будет состоять из единственного модуля FIMPrincipalMapper. Эта цепочка затем указывается в качестве механизма аутентификации в ресурсах JDBC-приложения.

Выполните следующие шаги:

1. Поместите все jar-файлы, содержащие FIMPrincipalMapper и вспомогательные классы, в classpath WAS. Скопируйте файлы soa-common.jar, soa-wstrust-client-impl.jar, soa-jaas-login.jar и soa-wstrust-client-intf.jar  в директорию  WAS_HOME/lib/ext/   того сервера, в котором развернуто приложение с JSP.
2. Перезапустите сервер приложений.
3. Войдите в консоль администрирования WAS и перейдите в раздел Security -> Secure administration, applications, and infrastructure -> Java Authentication and Authorization Service -> Application logins.
4. Нажмите New.
5. Задайте подходящее имя для цепочки, например FIMforDB2.
6. Нажмите Apply.
7. Нажмите на кнопку JAAS login modules (модули аутентификации JAAS).
8. Нажмите New.
9. В поле Module class name (имя класса модуля) укажите com.tivoli.am.fim.jaas.login.loginmodules.FIMPrincipalMapper. Установите флаг Use login module proxy (использовать прокси модуля аутентификации), выберите пункт REQUIRED в списке Authentication strategy (стратегия аутентификации) и нажмите Apply.
   
   Рисунок 14. Конфигурирование цепочки аутентификации, состоящей из модуля JAAS
   
   
   
10. Нажмите на кнопку Custom properties (нестандартные свойства).
11. Оставьте значение по умолчанию для свойства delegate (должно быть com.tivoli.am.fim.jaas.login.loginmodules.FIMPrincipalMapper). Создайте свойства, показанные в таблице ниже.
    
    

    Параметр	Значение
    cache_cleanup_interval	10
    cache_expiration_interval	30
    appliesto	http://appliesto/tamgso
    issuer	http://issuer/websphere
    stsendpoint	http://TCPMON_HOST:TCPMON_PORT/TrustServer/SecurityTokenService

    
    
    Учтите, что tcpmon должен быть настроен таким образом, чтобы перенаправлять запросы сервису TFIM STS. Если tcpmon у вас не установлен, параметр stsendpoint  должен указывать непосредственно на TFIM STS.
    
    Рисунок 15. Настройки модуля FIMPrincipalMapper
    
    
    
12. Сохраните настройки.
13. Далее необходимо указать в ресурсах приложения, что механизм аутентификации должен использовать цепочку JAAS. Для этого выполните следующие шаги:
    • Перейдите в раздел Applications -> Enterprise Applications -> JDBCWebApp_war -> Resource references в консоли администрирования WAS.
    • Выделите ресурс JDBCWebAPP QueryReference, выберите опцию Use custom login configuration  (использовать специальные настройки аутентификации), а затем — цепочку FIMforDB2.
    • Нажмите Apply.
    • Сохраните настройки.
    
    
    Рисунок 16. Выбор цепочки аутентификации JAAS в ресурсах приложения
    
    
    
14. Теперь следует изменить роли пользователей приложения JDBCWebApp так, чтобы права на доступ к JSP-странице остались только у Web-пользователя. Для этого выполните следующие действия:
    • Перейдите в раздел Applications -> Enterprise Applications -> JDBCWebApp_war -> Security role to user/group mapping в консоли администрирования WAS.
    • Выберите роль inboundUser  и нажмите на кнопку Look up users (выбор пользователей).
    • Нажмите на кнопку Search для вывода списка пользователей в колонке Available.
    • Выберите пользователя webuser и нажмите на кнопку >>, чтобы он появился в колонке Selected.
    • Нажмите OK и убедитесь, что webuser показан в колонке Mapped users.
    • Снимите флаг All authenticated?  для роли inboundUser и нажмите OK.
      
      Рисунок 17. Новые настройки ролей для демонстрационного приложения
      
      
      
    • Сохраните настройки.
15. Перезапустите приложение JDBCWebApp.

Теперь приложение должно быть готово к работе.

Логика сопоставления учетных записей

В процессе работы приложения можно отметить пять событий, представляющих интерес при мониторинге использования учетных записей пользователей.

1. Аутентификация для входа приложение JSP.
2. Указание пользователя в токене UsernameToken и запрос к TFIM STS.
3. Сопоставление учетной записи пользователя GSO, выполняемое сервером авторизации ТАМ.
4. Указание пользователя в токене UsernameToken и ответ TFIM STS.
5. Аутентификация для доступа к базе данных.

В зависимости от конфигурации вашей системы некоторые из этих событий могут представлять интерес, в особенности события 1, 3 и 5. Подробное описание конкретных методов аудита событий выходит за рамки этой статьи, однако ниже приведено несколько советов.

Первое событие возникает в результате работы механизма обеспечения безопасности сервера приложений WebSphere. Доступ к приложению JDBCWebApp получают те пользователи, для которых заданы соответствующие роли. Вы можете узнать, какие пользователи аутентифицированы и имеют доступ к JSP (в данном случае таковым должен быть пользователь webuser1). Для этого следует включить режим трассировки сервера и добавить строчку com.tivoli.am.fim.jaas.login.loginmodules.FIMPrincipalMapper=all  в файл настроек уровней журналирования. После этого трассировочные сообщения должны записываться в файл trace.log в директории log профиля server1.

Для аудита второго события есть два варианта. Во-первых, вы можете анализировать запросы WS-Trust, передаваемые по сети, пропуская их через tcpmon, работающий между WAS и TFIM. Во-вторых, можно включить трассировку среды выполнения TFIM. Для этого добавьте строчку com.tivoli.am.fim.*=all в настройки уровней журналирования сервера, в котором развернут TFIM, после чего можно анализировать содержимое файла trace.log в директории server1 log профиля. Вы должны увидеть, как сервису STS передается запрос, содержащий имя пользователя webuser1. Третье и четвертое события также можно отслеживать при помощи трассировки TFIM. Пятое событие можно отследить в журнале аудита DB2 или включив трассировку сервера приложений, в котором развернуто приложение JDBC. Подробности настройки аудита событий DB2 приведены в листинге 5.
Листинг 5. Настройка аудита событий в DB2

db2admin$ # запустите перед подключением:
db2admin$ db2audit configure scope all status both
db2admin$ db2audit start
db2admin$ # запустите после подключения к БД:
db2admin$ db2audit flush
db2admin$ db2audit extract file TMP_DIR/db2audit_sampledb.log database sampledb
      

Управление учетными записями GSO

В рамках демонстрационной системы к этой статье идентификационные данные пользователя необходимо конфигурировать в различных компонентах, в том числе:

• в каталоге сервера приложений WepSphere;
• в каталоге менеджера доступа Tivoli (TAM), который в данном случае совпадал с каталогом WAS;
• в хранилище TAM GSO (внутри директории ТАМ);
• в базе данных DB2 (или локальной операционной системе);

Менеджер идентификационной информации Tivoli (Tivoli Identity Manager - TIM) представляет собой решение для управления учетными записями в сложных системах, которое поддерживает бизнес-процессы и обеспечивает высокий уровень автоматизации. TIM может использоваться для управления учетными записями в системах, подобных описанной выше. Это решение также позволяет синхронизировать пароли, благодаря чему репозиторий TAM GSO легко синхронизируется с учетными записями в хранилище, используемом DB2 (база данных или локальная операционная система).

Заключение

В этой статье представлен пример того, как идентификационная информация пользователя может проходить через различные слои программного комплекса вплоть до момента аутентификации в базе данных. Представленная схема реализована с использованием двух модулей, интегрированных с TFIM (Tivoli Federated Identity Manager).

• модуль аутентификации JAAS, вызывающий сервис доверенности TFIM;
• модуль сопоставления учетных записей TAM GSO для сервиса доверенности TFIM.

Эта схема дает пример решения сложной задачи управления идентификационной информацией пользователей в комбинированных приложениях в архитектуре SOA.

В начало

Загрузка

Информация о методах загрузки

Ресурсы

Научиться

• Оригинал статьи: End-to-end identity management for Web-based access to relational databases (Пол Уинтерс и Нил Ридшоу, developerWorks, март 2007 г.). (EN)
  
  
• Прочитайте статью Реализация и развертывание специализированных модулей доверенности (developerWorks, ноябрь 2005 г.), в которой объясняются основы создания собственных модулей для TFIM. (EN)
  
  
• Обратитесь к информационному центру TFIM за справочной информацией и документацией по интегрированному менеджеру учетных записей Tivoli. (EN)
  
  
• Если вас интересует справочная информация и документация по серверу приложений WebSphere, обратитесь к информационному центру WebSphere 6.1, WebSphere 6.0 или библиотеке WAS. (EN)
  
  
• Обратитесь к магазину технической литературы, в котором предлагаются книги на эту и другие темы. (EN)
  
  

Получить продукты и технологии

• Загрузите пакет интеграции TFIM 6.1 CICS. (EN)
  
  
• Загрузите модуль TFIM 6.1 STS для TAM GSO. (EN)
  
  

Обсудить

• Читайте блоги developerWorks и присоединяйтесь к нашему сообществу. (EN)
  
  

Об авторах

Пол Уинтерс (Paul Winters) - консультант по управлению идентификационной информацией в компании Loop Technology, являющейся бизнес-партнером IBM. Его работа в основном связана с обеспечением корпоративной безопасности, в частности, при использовании технологий SOA. Его обязанности включают проектирование и развертывание интегрированных решений на основе продуктов Tivoli Security и WebSphere. Ранее он был разработчиком программного обеспечения в отделе Tivoli Security в лаборатории IBM в Австралии.

Нил Ридшоу (Neil Readshaw) - старший архитектор решений в области безопасности в группе Tivoli Security Team, расположенной в Голд-Косте, Австралия. Нил работает с клиентами, проектируя решения на основе продуктов Tivoli Security, а также занимается поддержкой внедрения решений в структуре IBM Business Partners и команде менеджеров IBM по техническим продажам в Азиатско-Тихоокеанском регионе.

Оценить эту статью

Комментарии

В начало

Содержание

• Введение
• Подготовка к работе
• Настройка статической учетной записи для доступа к базе данных
• Динамическое сопоставление учетных записей для доступа к базе данных
• Логика сопоставления учетных записей
• Управление учетными записями GSO
• Заключение
• Загрузка
• Ресурсы
• Об авторах
• Комментарии