Руководство по WebSphere Application Server

ОнЛ@йн руководство с примерами по WAS

  • Главная
  • Авторское право
  • Команда
  • Контакты
  • Оглавнение

26

Ноя

6.7. Аутентификация ресурсов

Опубликовал admin  Рубрика Часть 6. Конфигурирование ресурсов

Ресурсы часто требуют пройти аутентификацию и авторизацию, прежде чем приложением сможет получить к ним доступ. Вы можете различными способами настроить параметры, определяющие то, как это происходит. В данном разделе описываются конфигурационные параметры и их использование. Однако прежде чем реализовывать систему безопасности, вам следует изучить информацию, приведенную в книге «WebSphere Application Server V6.1 Security Handbook», SG24-6316.

Сторона, ответственная за выполнение аутентификации и авторизации, определяется параметром res-auth в дескрипторах размещения Web-модуля и EJB. Существует два возможных значения:

• res-auth=Application: Отвечает приложение или компонент.

• res-auth=Container: Отвечает WebSphere.

Данные параметры можно настраивать в ходе сборки приложения с помощью Rational Application Developer, или с помощью Application Server Toolkit в дескрипторе размещения Web-модуля или EJB. Эти параметры также можно задавать или заменять в ходе инсталляции приложения.

В случае аутентификации, управляемой компонентом, тот компонент приложения, который обращается к ресурсу или адаптеру, и отвечает за программное предоставление верительных данных. WebSphere также может предоставить заданный по умолчанию псевдоним компонентно-управляемой аутентификации, если он доступен. После получения фабрики соединений для ресурса из JNDI, компонент приложения создает соединение с ресурсом с помощью метода create фабрики соединений, указывая верительные данные. Если при создании соединения верительные данные не указаны, но для фабрики соединений J2C был указан аутентификационный псевдоним компонентно-управляемой аутентификации, то будут использованы верительные данные из аутентификационного псевдонима. При условии, что верительные данные указаны верно, следующие запросы, которые используют это соединение, будут использовать и те же верительные данные.

Приложение выполняет следующие основные шаги.

1. Получает исходный JNDI-контекст.

2. Находит фабрику соединений для адаптера ресурса.

3. Создает объект ConnectionSpec, хранящий верительные данные.

4. Получает объект-соединение от фабрики соединений, предоставляя объект ConnectionSpec.

Аутентификация, управляемая WebSphere

Аутентификация, управляемая контейнером, устраняет необходимость в том, чтобы компонент программно предоставлял верительные данные для получения доступа к ресурсу. Вместо вызова метода getConnection() с передачей ему объекта ConnectionSpec, метод getConnection() вызывается без аргументов. Верительные данные для аутентификации предоставляются Web-контейнером, контейнером приложения или EJB-контейнером, в зависимости от того, откуда осуществляется доступ к ресурсу. WebSphere Application Server V6 поддерживает спецификацию JAAS, так что верительные данные можно сопоставить с любым из сконфигурированных аутентификационных модулей JAAS, включая любой пользовательский аутентификационный JAAS-модуль.

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

• Выберите None (Нет), если вы используете административную консоль WebSphere или Container Managed Authentication (deprecated) (выводимая из употреб ления аутентификация, управляемая контейнером) в Application Server Toolkit. При выборе данной опции используются параметры аутентификации, управляе мой контейнером , заданные в фабрике соединений ресурса. Верительные данные поступают из аутентификационного псевдонима JAAS с использованием значения DefaultPrincipalMapping параметра псевдонима Mapping-configuration или соотносятся с другим аутентификационным модулем JAAS. Любое приложение, которое может получить фабрику соединений ресурса из JNDI, сможет получить доступ к EIS. Это создает риск для безопасности, связанный с тем, что неуполномоченное приложение может получить доступ к ресурсу.

Выбор данной опции с указанием DefaultPrincipalMapping и выбором аутентификационного псевдонима JAAS при определении фабрики соединений ресурса обеспечивает ту же функциональность, которая была в WebSphere Application Server V5. Этот метод более не является рекомендуемым.

• Выберите Use default method (Использовать метод, заданный по умолчанию).

При выборе параметра Use default method поведение весьма сходно аутентификацией, управляемой контейнером с использованием опции DefaultPrincipalMapping. Аутентификационный псевдоним JAAS связывается с фабрикой соединений и все контейнерно-управляемые запросы на аутентификацию, использующие ссылки на ресурсы, применяют верительные данные из псевдонима. Разница в том, что связь от аутентификационного псевдонима JAAS к фабрике соединений устанавливается на уровне ссылки на ресурс внутри приложения. Этим уменьшается риск для безопасности, поскольку область действия верительных данных ограничивается приложением, определившим ссылку на ресурсы. Все прочие приложения должны будут предоставить свои собственные верительные данные при прямом доступе к фабрике соединений через JNDI. Данный метод связывания аутентификационных псевдонимов JAAS с фабриками соединений является рекомендуемым.

• Выберите Use custom login configuration (Использовать настраиваемую кон фигурацию входа).

Вы также можете использовать любую конфигурацию JAAS-аутентификации, предоставляемую WebSphere или пользователем.

  • Twitter
  • Одноклассники
  • ВКонтакте
  • FaceBook
  • ой Мир
« 6.6.2. Конфигурирование провайдера среды ресурсов
6.8. Дополнительная информация »

Рубрики

  • Часть 1. Основы
  • Часть 2. Технический обзор
  • Часть 3. Профили
  • Часть 4. Основы администрирования
  • Часть 5. Использование скриптов
  • Часть 6. Конфигурирование ресурсов
  • Часть 7. Управление Web-серверами
  • Часть 8. Асинхронный обмен сообщениями

Свежие записи

  • 8.4.8. Наилучшие подходы к работе с MDB-компонентами
  • 8.4.7. Связывание компонента, управляемого сообщением, с пунктом назначения
  • 8.4.6. Конфигурационные свойства активации MDB-компонентов
  • 8.4.5. Компоненты, управляемые сообщениями, и транзакции
  • 8.4.4. Жизненный цикл компонента, управляемого сообщениями

Страницы

  • Авторское право
  • Команда
  • Главная
    • Дополнения
    • Примечание
  • Контакты
  • Оглавнение

Последние записи

  • 8.4.8. Наилучшие подходы к работе с MDB-компонентами
  • 8.4.7. Связывание компонента, управляемого сообщением, с пунктом назначения
  • 8.4.6. Конфигурационные свойства активации MDB-компонентов
  • 8.4.5. Компоненты, управляемые сообщениями, и транзакции
  • 8.4.4. Жизненный цикл компонента, управляемого сообщениями
  • 8.4.3. Реализация компонента, управляемого сообщениями
  • 8.4.2. Взгляд на компонент, управляемый сообщениями, со стороны клиента
  • 8.4.1. Типы компонентов, управляемых сообщениями
  • 8.4. Компоненты, управляемые сообщениями
  • 8.3.5.-8.3.8 Размещение конечной точки для сообщений

Свежие комментарии

  • Комментариев нет
  • Случайные записи

    • 4.9.3. Экспортирование и импортирование профилей
    • 6.5.3. Пример URL-провайдера
    • 1.4. Поддерживаемые платформы и программное обеспечение
    • 4.1.11. Сохранение работы
    • 4.5. Работа с узлами
    • 8.2.2. JMS-провайдеры
    • 5.2.6.8. Общий обзор команд AdminTask
© 2012 Руководство по WebSphere Application Server
Дизайн : Roam2Rome | Локализация темы для wordpress goodwin
Копирование материалов с данного сайта возможно только при наличии индексируемой ссылки на данный ресурс.