Q & A: Вопросы и ответы: ответы на типичные вопросы по безопасности продукта WebSphere Application Server

Проблемы в области безопасности ставят под угрозу целостность всей вашей вычислительной среды, поэтому реагировать на них необходимо с максимальной возможной скоростью. С этой целью в данной статье собраны краткие конкретные ответы на некоторые типичные вопросы по безопасности продукта IBM® WebSphere® Application Server. Из журнала IBM WebSphere Developer Technical Journal.

Кейз Ботзум, ведущий технический специалист, EMC

Кейз Ботзум (Keys Botzum) – ведущий технический специалист подразделения IBM Software Services for WebSphere. Кейз Ботзум более 10 лет работает в области проектирования крупномасштабных распределенных систем и дополнительно специализируется в области безопасности. Он имеет большой опыт работы с различными распределенными технологиями, включая Sun RPC, DCE, CORBA, AFS и DFS. В последнее время К. Ботзум сосредоточил свои усилия на J2EE и сопутствующих технологиях. К. Ботзум является обладателем ученой степени магистра в области вычислительной техники, полученной в Стэнфордском университете, и степени бакалавра по прикладной математике/вычислительной технике, полученной в Университете Карнеги Меллона. К. Ботзум опубликовал множество статей по продуктам WebSphere и по безопасности платформы WebSphere. С другими статьями и презентациями К. Ботзума можно ознакомиться по адресу http://www.keysbotzum.com, а также в разделе Материалы по платформе WebSphere на ресурсе IBM developerWorks. К. Ботзум является одним из авторов книги Развертывание и углубленное конфигурирование продуктов IBM WebSphere.



Билл O'Доннел, ведущий архитектор по безопасности продуктов WebSphere Security, IBM China

Bill O'Donnell– ведущий архитектор по безопасности продуктов WebSphere, сотрудник подразделения по разработке продуктов WebSphere. Он отвечает за архитектуру безопасности продукта WebSphere Application Server. Билл О’Доннел более 25 занимался мэйнфреймами и крупномасштабными распределенными системами, уделяя основное внимание таким областям, как архитектура разработки и архитектурные аспекты инфраструктуры. Он специализируется на всеобъемлющей безопасности инфраструктуры и приложений. О’Доннел опубликовал несколько пособий в серии Redbooks и является автором книги Secrets of SOA (Секреты SOA). Кроме того, он является одним из организаторов Web-сайта WebSphere Application Server security .



04.03.2013 (Впервые опубликовано 13.12.2013)

Ответы на важные вопросы

Столь критически важная предметная область, как безопасность сервера приложений, порождает значительный объем не менее важных вопросов. Чтобы вы смогли лучше понять общие аспекты безопасности продукта IBM® WebSphere® Application Server и оценить, насколько они применимы (или должны быть применимы) к вашей среде, мы предлагаем ответы на несколько наиболее распространенных вопросов, которые относятся к продукту WebSphere Application Server версии V6.1 и выше (если иная версия не указана в явном виде).

Эти вопросы и ответы на них разделены на следующие три обширные категории.

Реестр

  1. В каких случаях WebSphere Application Server обращается к реестру за информацией о пользователе?
  2. Работает ли WebSphere Application Server с сервисом NIS?
  3. Какими возможностями я располагаю, если при нахождении в среде Windows® с неадминистративной учетной записью я хочу активировать безопасность?
  4. Какими возможностями я располагаю, если в среде UNIX® я хочу активировать безопасность с идентификатором сервера, отличным от root?
  5. Будет ли локальная аутентификация операционной системы работать в распределенной среде?
  6. Мои пользователи проходят аутентификацию с одним идентификатором пользователя, а я хочу, чтобы они аутентифицировались по другому идентификатору из LDAP. Возможно ли это?
  7. Можно ли при использовании объединенного репозитория сделать так, чтобы мой реестр на базе файлов продолжал функционировать при отключении LDAP-сервера?

Аутентификация

  1. Зачем мне нужно активировать SSO, когда в своем приложении WebSphere Application Server я использую вход на основе форм?
  2. Я хочу вынудить своих пользователей снова входить в систему после истечения заданного времени бездействия. Как будет работать продукт WebSphere Application Server применительно к тайм-аутам сеанса и тайм-аутам LTPA?
  3. Могу ли я что-либо сделать для того, чтобы не терялась синхронизация LTPA-ключей между ячейками?
  4. Может ли ячейка WebSphere Application Server охватывать несколько DNS-доменов?
  5. Почему не приветствуется применение механизма SWAM?
  6. В каких случаях мне следует использовать специальный модуль входа вместо TAI-модуля для подтверждения идентификационных данных?

Прочие вопросы из области безопасности

  1. Как я могу изменить свой пароль (к базе данных, LDAP и т.д.) без остановки системы?
  2. Какие существуют проприетарные расширения продукта WebSphere Application Server для обеспечения безопасности J2EE™?
  3. Поддерживает ли WebSphere Application Server продукт CA Siteminder?
  4. WebSphere Application Server хранит пароли, закодированные посредством XOR. Я хотел бы использовать более сильный метод шифрования. Что я могу предпринять в этой ситуации?
  5. Как можно отлаживать исключения безопасности Java™ 2 и исключения типа AccessControlException?
  6. Имеются ли какие-либо документированные рекомендации по конфигурированию Microsoft Active Directory совместно WebSphere Application Server?

Реестр

1. В каких случаях WebSphere Application Server обращается к реестру за информацией о пользователе?

WebSphere Application Server запрашивает реестр для получения информации о пользователе, а также при выполнении административных операций. Таким образом, чтобы ячейка с продуктом WebSphere Application Server функционировала, реестр должен иметь практически 100%-ную готовность.

WebSphere Application Server обращается к реестру по следующим причинам.

  • Когда пользователи осуществляют аутентификацию (с помощью пароля или сертификата; не требуется при наличии прокси-сервера Web SSO). WebSphere Application Server подает запросы, когда выполняет следующие действия:
    • Проверяет пароль пользователя.
    • Сопоставляет информацию сертификата с идентификатором пользователя.
    • Преобразует идентификатор пользователя в уникальный идентификатор реестра (например, LDAP DN).
    • Получает информацию о группе.
  • Когда LTPA-токен (LTPA token) передается на сервер в первый раз. WebSphere Application Server получает информацию о группе, даже когда токен LTPA (Lightweight Third Party Authentication) передается на сервер в первый раз (например, посредством трафика WebSEAL или трафика IIOP), поскольку LTPA-токен содержит только DN-имя пользователя (Distinguished Name). То же самое правило применимо для TAI-модулей (Trust Association Interceptor), поскольку они обычно предоставляют только идентификатор пользователя. Если используется версия WebSphere Application Server V5.1.1 И включен механизм subject propagation, И TAI-модуль или login-модуль распространяет групповую информацию (что способен делать TAI-модуль WebSEAL в версии WebSphere Application Server V5.1.1), то WebSphere Application Server не будет запрашивать у LDAP информацию о группе пользователей, в которую входит данный пользователь.
  • Если попытка subject propagation заканчивается неудачей. Даже при включенном механизме subject propagation, если попытки subject propagation закончились неудачей (например, если сервер был выключен), WebSphere Application Server будет пытаться воссоздать субъект, если не задан специальный ключ кэша.
  • Когда пользователи осуществляют аутентификацию для административных операций (Web, JMX и т.д.).
  • При запуске любого приложения - соответствующие связывания ролей верифицируются по реестру
  • Каждый раз, когда администратор задает информацию связывания в административной консоли.

2. Работает ли WebSphere Application Server с сервисом NIS?

При проведении аутентификации продукт WebSphere Application Server напрямую не поддерживает сервис NIS (Network Information Service). Этот продукт поддерживает аутентификацию на основе LDAP, аутентификацию на основе операционной системы и пользовательскую аутентификацию. При работе в операционной среде UNIX продукт WebSphere Application Server использует стандартные для этой среды API-интерфейсы паролей (getpw* и т.д.) для верификации пароля пользователя (для этого продукт WebSphere Application Server должен исполняться как root). Если эти API-интерфейсы обращаются к NIS, то продукт WebSphere Application Server будет использовать NIS для аутентификации; этот процесс является прозрачным для WebSphere Application Server. Тем не менее, если в среде UNIX используется реестр операционной системы, то многоузловые ячейки не поддерживаются.

Иногда для использования NIS можно написать специальный реестр.

В большинстве случаев ответ на этот вопрос – «нет».

3. Какими возможностями я располагаю, если при нахождении в среде Windows® с неадминистративной учетной записью я хочу активировать безопасность?

Если при исполнении процессов WebSphere Application Server от имени «не администратора» активирована глобальная безопасность, то реестр пользователей должен быть LDAP-реестром или специальным реестром.

Чтобы использовать локальный реестр пользователей операционной системы, пользователь, от имени которого исполняется продукт, должен иметь привилегии Administrative и Act as part of the operating system. Эти привилегии позволяют ему вызвать API-интерфейсы операционной системы Windows, которые осуществляют аутентификацию или собирают информацию о пользователе или о группе. Этому процессу нужны специальные полномочия, которые и предоставляются вышеуказанными привилегиями. В этом примере идентификатор пользователя должен отличаться от идентификатора сервера безопасности (для которого требуется наличие действительного пользователя в реестре). Пользователь входит в машину (если он использует командную строку для запуска процесса описываемого продукта) или использует опцию Log On User на панели сервисов (если процессы продукта были запущены с помощью сервисов). Если данная машина является частью какого-либо домена, то для того, чтобы вызвать API-интерфейсы в этом домене, этот пользователь должен быть членом группы Domain Admin этого домена (в дополнение к наличию привилегии Act as part of operating system на локальной машине).

4. Какими возможностями я располагаю, если в среде UNIX® я хочу активировать безопасность с идентификатором сервера, отличным от root?

Если при исполнении процессов WebSphere Application Server глобальная безопасность активируется от имени, отличного от root, то реестр пользователей должен быть LDAP-реестром или специальным реестром.

Чтобы использовать локальный реестр пользователей операционной системы, пользователь, от имени которого исполняются процессы продукта, должен иметь привилегию root. Эта привилегия необходима, чтобы вызвать API-интерфейсы операционной системы UNIX, которые осуществляют аутентификацию или собирают информацию о пользователе или о группе. Этот процесс требует специальных полномочий, которые предоставляются привилегией root. Для использования реестра пользователей локальной операционной системы требуется, чтобы Node Agent, Deployment Manager и процесс Application Server исполнялись как root.

5. Будет ли локальная аутентификация операционной системы работать в распределенной среде?

В редакции WebSphere Application Server Network Deployment с узлами сервера приложений, распределенными между двумя и более физическими машинами, вы не сможете использовать локальную аутентификацию операционной системы. В такой среде вы должны использовать или LDAP-реестр или специальный реестр. Однако имеется одно исключение: реестр домена Windows является централизованным, поэтому он может быть использован в этой ситуации. Необходимо понимать следующее обстоятельство. Хотя с технической точки зрения сервис NIS представляет собой централизованный реестр, он не подходит для использования с редакцией WebSphere Application Server Network Deployment.

За дополнительной информацией обратитесь к статье в Информационном центре: Local operating system registries (Реестры локальной операционной системы).

6. Мои пользователи проходят аутентификацию с одним идентификатором пользователя, а я хочу, чтобы они аутентифицировались по другому идентификатору из LDAP. Возможно ли это?

Существует способ, позволяющий сконфигурировать WebSphere Application Server для решения именно этой задачи. Этот способ исходит из допущения, что LDAP-запись для каждого пользователя имеет атрибут, содержащий строку, которая может быть использована в качестве второго идентификатора пользователя. В качестве примера предположим, что этот атрибут имеет имя myname. Предположим также, что идентификатор пользователя, используемый для аутентификации, содержится в LDAP-атрибуте с именем uid.

В LDAP-конфигурации продукта WebSphere Application Server (в административной консоли выберите: Security > User Registries > LDAP > Advanced LDAP Settings), измените значение в поле User ID c *:uid на *:myname . Тем самым вы дадите продукту WebSphere Application Server указание настроить J2EE-принципал, который возвращает в приложение значение LDAP-атрибута myname. В нормальных условиях WebSphere Application Server возвращает тот же идентификатор пользователя, который использовался для входа в систему.

В качестве примера предположим, что пользовательская запись в LDAP имеет следующие пары атрибут/значение: uid=dale.sue.ping, myname=sueping.

После вышеописанного изменения LDAP-конфигурации продукта WebSphere Application Server пользователь будет осуществлять вход с идентификатором пользователя dale.sue.ping, проходить аутентификацию с использованием WebSphere Application Server/LDAP, после чего (в случае положительного исхода аутентификации) WebSphere Application Server присвоит J2EE-принципалу значение sueping.

Если приложение способно извлекать J2EE-принципал, оно будет видеть пользователя как «sueping», а не как «dale.sue.ping».

7. Можно ли при использовании объединенного репозитория сделать так, чтобы мой реестр на базе файлов продолжал функционировать при отключении LDAP-сервера?

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

$AdminTask createIdMgrRealm -name ibmRealm -allowOperationIfReposDown true

Подробнее см. статью в Информационном центре: IdMgrRealmConfig command group for the AdminTask object (Группа команд IdMgrRealmConfig для объекта AdminTask).


Аутентификация

8. Зачем мне нужно активировать SSO, когда в своем приложении WebSphere Application Server я использую вход на основе форм?

Активация SSO позволяет продукту WebSphere Application Server поддерживать состояние пользователя при Web-запросах с помощью LTPA cookie. В случае если опция SSO не активирована, аутентификация требуется для каждого отдельного запроса. Если вы используете вход на базе формы, то после того, как форма завершила аутентификацию, пользователь перенаправляется обратно по URL-адресу исходного запроса. Без SSO результаты аутентификации пользователя утрачиваются, поэтому авторизация заканчивается неудачей. Этого не происходит при использовании базовой аутентификации, поскольку аутентификационная информация присутствует в каждом HTTP-запросе, и WebSphere Application Server может использовать ее в любой момент, когда возникает соответствующая необходимость (это не влияет на безопасность и на производительность).

9. Я хочу вынудить своих пользователей снова входить в систему после истечения заданного времени бездействия. Как будет работать продукт WebSphere Application Server применительно к тайм-аутам сеанса и тайм-аутам LTPA?

LTPA-токен WebSphere Application Server LTPA теряет силу исходя из времени существования сеанса входа, а не из времени бездействия. Таким образом, сеанс входа в WebSphere Application Server не теряет силу, если пользователь не выполняет никаких действий на протяжении некоторого периода времени. Однако HTTPSession теряет силу при бездействии пользователя. Если вам необходимо, чтобы ваше приложение теряло силу при бездействии пользователя, вы должны в явном виде реализовать это в коде своего приложения. Вы можете зафиксировать момент, когда пользователь активизируется в истекшем сеансе (фактически — это уже новый сеанс), а затем вынудить его входить в систему снова. Имейте в виду, что это препятствует функционированию механизма Single Sign On между приложениями.

Второй подход, несколько отличающийся от первого, заключается в использовании HTTPSession.getLastAccessTime() для вычисления момента, когда имел место последний клиентский запрос. Если этот момент находится слишком далеко в прошлом, вы вполне сможете воспрепятствовать доступу пользователя и вынудить его проходить аутентификацию заново.

Любой из этих подходов может быть сделан прозрачным для кода приложения посредством использования фильтров на основе сервлетов. Следует отметить, что инструмент IBM Tivoli® Access Manager предоставляет для сеанса аутентификации тайм-ауты на основе продолжительности существования и на основе бездействия.

Пользователи часто спрашивают, почему продукт WebSphere Application Server работает подобным образом. Почему он не способен прекращать сессии входа по таймауту на основе бездействия? Причина состоит в том, что WebSphere Application Server по существу представляет собой слабосвязанную распределенную систему. Серверы приложений, входящие в SSO-домен, не нуждаются в том, чтобы общаться друг с другом. Они даже не обязаны находиться в одной ячейке. Таким образом, если вы хотите ограничить продолжительность бездействия LTPA-токена (он же SSO-токен), вы должны при каждом запросе обновлять момент последнего использования в самом токене (или, возможно, момент первого запроса, поступившего на протяжении одноминутного интервала). Это означает, что сам токен будет меняться часто (в результате чего браузер будет часто принимать новые cookie-файлы), так что WebSphere Application Server должен будет расшифровывать и проверять входящий токен. Этот подход может оказаться весьма дорогостоящим (в настоящее время WebSphere Application Server проверяет токен только при его первом использовании на каждом сервере приложений). Эти проблемы могут быть решены посредством рационального кэширования и т.д., однако в настоящее время WebSphere Application Server работает иначе.

10. Могу ли я что-либо сделать для того, чтобы не терялась синхронизация LTPA-ключей между ячейками?

Да. В версии WebSphere Application Server V6.1 появилась активируемая по умолчанию функция, которая автоматически регенерирует LTPA-ключи. Эта функция превосходно работает в простой конфигурации с одной ячейкой, однако любому пользователю, имеющему несколько ячеек и нуждающемуся в синхронизации LTPA-ключей между этими ячейками, следует отключить эту функцию автоматической регенерации для LTPA. В версии WebSphere Application Server V7 эта функция по умолчанию деактивирована. Для любого нового профиля, созданного для версии V6.1.0.23, эта функция отключается по умолчанию.

11. Может ли ячейка WebSphere Application Server охватывать несколько DNS-доменов?

До появления версии WebSphere Application Server V6 ответ на этот вопрос был отрицательным. Это объяснялось тем, что при конфигурировании защиты WebSphere Application Server требовалось, помимо прочего, специфицировать SSO-домен LTPA-токена. Если вы оставили соответствующее поле пустым, то домен LTPA-токена/LTPA-cookie не был определен, в результате чего cookie-файлы возвращались обратно только к тому же хосту. Если вы ввели в это поле какое-либо значение, то оно присваивалось домену для cookie, поэтому cookie-файлы возвращались к хостам, находящимся в том же DNS-домене. Такое поведение обуславливается требованиями спецификации HTTP. Проблема состояла в том, что если ваша ячейка (или фактически Web-серверы) обслуживала запросы для нескольких DNS-доменов, то не существовало способа специфицировать более одного домена. В версии WebSphere Application Server V6 значение SSO-домена, специфицированное для продукта WebSphere Application Server, могло содержать несколько DNS-доменов. В настоящее время вы можете специфицировать все необходимые вам домены. Когда WebSphere Application Server создает cookie-файл, он настраивает значение домена для этого cookie-файла (спецификация HTTP разрешает задать не более одного такого значения) посредством присвоения ему значения из входного запроса, которое соответствует одному из сконфигурированных доменов.

Примеры верных доменных имен: ibm.com и tx.gov. Примеры неверных доменных имен: ibmus и state_tx.gov. Некоторые пользователи столкнулись с определенной проблемой при работе с браузером Internet Explorer (IE) — версии IE 5 и IE 6 не принимают LTPA-токен, если домен, заданный в поле «SSO domain» имеет длину менее пяти символов (без учета точки), например. «cn.ca». Microsoft выпустила исправление для этой проблемы.

12. Почему не приветствуется применение механизма SWAM?

Технология SWAM (Simple WebSphere Authentication Mechanism) предназначена для использования в простых нераспределенных средах исполнения с одним сервером приложений. Это ограничение на количество серверов приложений (один сервер) вызвано тем, что SWAM не поддерживает учетные данные, допускающие перенаправление. Другими словами, если сервлет или компонент enterprise bean в одном из процессов сервера приложений вызовет дистанционный метод компонента enterprise bean, находящегося в другом процессе сервера приложений, то идентификационные данные вызывающей стороны не будут переданы во второй процесс сервера приложений. Передается только неаутентифицированные учетные данные. В зависимости от разрешений безопасности, сконфигурированных в EJB-методах, это может приводить к неудачам авторизации.

Технология SWAM может быть использована в качестве аутентификационного механизма в редакции WebSphere Application Server Base. SWAM не входит в число опций, поддерживаемых редакцией WebSphere Application Server Network Deployment V5.0. Использование механизма SWAM в редакции Base также не рекомендуется — для поддержания сведений о состоянии пользователя он использует объект HTTP Session, а это порождает проблемы, поскольку уровень HTTP Session не входит в состав инфраструктуры безопасности.

13. В каких случаях мне следует использовать специальный модуль входа вместо TAI-модуля для подтверждения идентификационных данных?

Примечание. Если пользователь уже был аутентифицирован другой аутентификационной системой, отличной от WebSphere Application Server, то можно сообщить продукту WebSphere Application Server идентификационные данные этого пользователя, а не требовать от пользователя повторного прохождения аутентификации. Соответствующий способ известен как identity assertion (подтверждение идентификационных данных). Для получения дополнительных сведений о механизме identity assertion применительно к TAI обратитесь к статье: (Расширенная аутентификация в среде WebSphere Application Server).

Таблица 1. Сравнение модуля входа и TAI-модуля
ХарактеристикаМодуль входаTAI
Составляет собственность IBMНет, но в любом случае он нуждается в соответствующем программном коде WebSphere Application ServerДа
Простота использованияСложнее в использованииПроще в использовании
Многофазная аутентификацияНетДа
Подавление Web-запроса входа НетДа
Возможность использования для Web-вызововДаДа
Возможность использования для RMI-вызовов ДаНет
Вызов (повторный вызов) для распространения входа на другие системыДаНет

Другие вопросы из области безопасности

14. Как я могу изменить свой пароль (к базе данных, LDAP и т.д.) без остановки системы?

  1. Попеременно используйте пару идентификаторов пользователя, например useridA и useridB. Предположим, что в данный момент вы используете идентификатор useridA.
  2. Задайте новый пароль для идентификатора useridB.
  3. В каждом случае использования/появления идентификатора useridA измените useridA на useridB с вашим новым паролем. Эта процедура позволяет поддерживать хороший уровень документирования.
  4. По очереди перезапустите все серверы в кластере таким образом, чтобы у вас всегда имелся работающий узел.
  5. Задайте новый пароль для идентификатора useridA. Если вы упустили что-либо на шаге c, то в соответствующем месте результат не будет достигнут, однако это не повлияет на остальные корректно измененные случаи использования/появления.
  6. При следующем изменении пароля используйте обратное переключение — с useridB на useridA.

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

15. Какие существуют проприетарные расширения продукта WebSphere Application Server для обеспечения безопасности J2EE™?

  • LTPA-токен (LTPA token)— это расширение не стандартизировано, однако оно представляет собой всего лишь сочетание «учетные данные/токен» и поэтому не влияет на разработчиков приложений. Когда пользователь выходит из системы, то для удаления LTPA-токена осуществляется перенаправление по URL-адресу ibm_security_logout.
  • Классы WSSubject, WSCredential и WSPrincipal — расширения IBM для стандартных J2EE-классов Subject, Credential и Principal. Необходимы в некоторых случаях по причине ограниченности стандартных классов.
  • TAI-модуль (Trust Association Interceptor) — часто используются в качестве интерфейса для сопряжения продукта WebSphere Application Server с прокси-серверами SSO (WebSEAL, ClearTrust, Siteminder и т.д.). Эти модули также работают на уровне аутентификации, поэтому не оказывают влияния на переносимость приложений, за одним исключением: при переходе на другой J2EE-контейнер вы должны гарантировать предоставление аналогичного интерфейса между прокси-сервером SSO и продуктом WebSphere Application Server. Вы должны знать, используют ли ваши разработчики API-интерфейсы, зависящие от прокси-сервера SSO.
  • Реестр типа CUR (Custom User Registry) — средство интеграционного уровня для пользователей, которые не применяют ни один из стандартных реестров WebSphere Application Server (реестр операционной системы, LDAP-реестр) или применяют их нестандартными способами.
  • Файлы типа Java 2 Security Policy — содержат несколько минимальных расширений относительно стандарта. Они относятся к инфраструктуре и не являются частью программного кода вашего приложения, однако файл was.policy включается в состав EAR-файла.
  • Административные API-интерфейсы продукта WebSphere Application Server—административные средства WebSphere Application Server, доступные в форме API-интерфейса, что позволяет осуществлять их вызов из приложений. Некоторые из этих API-интерфейсов могут базироваться на стандарте JMX, однако остальные API-интерфейсы являются специфичными для продукта WebSphere Application Server. Маловероятно, чтобы эти интерфейсы применялись в бизнес-приложениях (и это должно быть запрещено), однако не стоит забывать о них при написании административных приложений.
  • Скрипты wsadmin — с технической точки зрения не являются частью ваших бизнес-приложений, однако вам не следует забывать, что скрипты, написанные для выполнения административных функций, должны быть переписаны при портировании на другой продукт. Для таких задач, как развертывание, предпочтительнее использовать инструменты, основанные на открытых стандартах, например, Ant. Нужно понимать, что некоторые команды инструмента Ant, поставляемого вместе с продуктами WebSphere Application Server, IBM WebSphere Studio Application Developer IBM Rational® Application Developer, являются «IBM-специфическими».

Кроме того, существуют и другие проприетарные API-интерфейсы, не входящие в систему безопасности, такие как API-интерфейсы dynacache для команд, а также API-интерфейсы для кэширования Java-объектов и для вызовов WebSphereMQ, осуществляемых за границами JMS.

16. Поддерживает ли WebSphere Application Server продукт CA Siteminder?

WebSphere Application Server предоставляет точку для подключения внешних продуктов для аутентификации через т.н. «TAI-модуль» (Trust Association Interceptor), что позволяет делегировать функции аутентификации внешнему поставщику сервисов безопасности (отличному от WebSphere Application Server). Примеры широко применяющихся продуктов этой категории: IBM Tivoli Access Manager, CA Siteminder, RSA Clear Trust. Каждый из поставщиков этих продуктов сам отвечает за реализацию взаимодействия с TAI-модулем для подключения к продукту WebSphere Application Server, а также за обеспечение функционирования этого TAI-модуля со своим решением.

Например, компания CA разрабатывает и продает TAI-модуль для продукта WebSphere Application Server. Компания CA отвечает за поддержку не только своего продукта Siteminder, но и TAI-модуля, который она проектирует и создает для интеграции Siteminder с WebSphere Application Server. С точки зрения WebSphere Application Server вы можете использовать любой из вышеперечисленных продуктов по собственному желанию, однако со всеми возникающими у вас вопросами и проблемами вам следует обращаться к соответствующему поставщику, например, в компанию CA в случае продукта Siteminder. Как и в случае продукции IBM, пользователи платят компании CA за лицензию на использование продукта Siteminder и за получение поддержки этого продукта. IBM не располагает средствами для исправления ошибок продукта Siteminder, TAI-модуля для Siteminder или любых аксессуаров Siteminder и не несет за это никакой ответственности.

Помимо точки подключения на базе технологии Trust Association Interceptor, продукт WebSphere Application Server предлагает для использования дополнительные точки подключения, такие как CUR (Custom User Registry), JAAS и JACC. Необходимо понимать, что границей поддержки является точка подключения. Для продукта WebSphere Application Server предусматривается поддержка вплоть до точки подключения, а «компания-реализатор» (например, Siteminder) несет ответственность за реализацию точки подключения, предназначенной для работы с ее решением.

17. WebSphere Application Server хранит пароли, закодированные посредством XOR. Я хотел бы использовать более сильный метод шифрования. Что я могу предпринять в этой ситуации?

До появления версии WebSphere Application Server V6.0.2 в этом отношении мало что можно было сделать. Если пользователь был недоволен тем, как WebSphere Application Server хранит пароли к J2C-ресурсам, он мог написать собственный J2C-модуль входа для получения паролей из источника за пределами WebSphere Application Server, однако это не решало проблем с остальными паролями WebSphere Application Server: LDAP bind, WebSphere Application Server admin и т.д.

С появлением версии WebSphere Application Server V6.0.2 вы можете сконфигурировать свой собственный шифратор паролей, реализующий любую защиту, которую вы считаете необходимой. Для этого реализуйте интерфейс для подключаемых модулей (com.ibm.wsspi.security.crypto.CustomPasswordEncryption), а затем укажите в файле security.xml два пользовательских свойства безопасности. Вы также можете задать эти свойства в файле PropFilePasswordEncoder.bat/sh. Речь идет о следующих двух свойствах:

  • com.ibm.wsspi.security.crypto.customPasswordEncryptionClass
  • com.ibm.wsspi.security.crypto.customPasswordEncryptionEnabled.

Более подробная информация содержится в документе Центра информации под названием: (Точка подключения для пользовательского шифрования паролей). .

18. Как можно отлаживать исключения безопасности Java 2 и исключения типа AccessControlException?

Для этого имеются два основных средства: файл WebSphere SystemOut.log и свойство com.ibm.websphere.java2secman.norethrow. Исключение AccessControlException, зарегистрированное в файле SystemOut.log, содержит сведения о нарушении определенного разрешения, вызвавшего это исключение; о стеке вызовов исключений; а также о разрешениях, предоставленных каждому стековому фрейму. Обычно этой информации достаточно для выявления отсутствующих разрешений и программного кода, которому эти разрешения требуются.

Если в WebSphere Application Server активирована безопасность Java 2, то при нарушении какого-либо разрешения компонент Security Manager выдает исключение java.security.AccessControl. Без обработки это исключение часто вызывает сбой времени исполнения. Кроме того, это исключение регистрируется в журнальном файле SystemOut.log.

Однако если свойство JVM com.ibm.websphere.java2secman.norethrow задано и имеет значение true, компонент Security Manager не выдает исключение AccessControl. Эта информация регистрируется в журнале.

Чтобы задать для сервера свойство com.ibm.websphere.java2secman.norethrow, перейдите в административную консоль WebSphere Application Server и выберите Servers > Application Servers. Под заголовком Additional Properties выберите Process Definition > Java Virtual Machine > Custom Properties > New. В поле Name введите с клавиатуры com.ibm.websphere.java2secman.norethrow. В поле Value введите с клавиатуры true.

19. Имеются ли какие-либо документированные рекомендации по конфигурированию Microsoft Active Directory совместно с WebSphere Application Server?

Да, недавно мы добавили набор полезных рекомендаций, основанных на опыте работы нашей группы IBM Software Services for WebSphere с другими заказчиками. Обратитесь к техническому обзору Using Microsoft Active Directory with IBM WebSphere Application Server (Использование Microsoft Active Directory совместно с IBM WebSphere Application Server).

20. Как программным способом получить пароль из конфигурации J2C-псевдонима?

Показанный ниже образец программного кода можно использовать для получения пароля из J2C-псевдонима в конфигурации WebSphere Application Server. Контекст DefaultPrincipalMapping LoginContext нуждается в двух аргументах.

  • Аргумент WSMappingCallbackHandler, содержащий (в неявном виде) псевдоним, для которого нам нужно получить пароль.
  • Аргумент Subject, который будет изменен посредством метода (методов) LoginModules login() в конфигурации Login.

WSMappingCallbackHandler получает пароль псевдонима из конфигурации безопасности WebSphere Application Server, а Login-модули копируют его в PasswordCredential в аргументе Subject.

Листинг 1. Получение пароля из J2C-псевдонима в конфигурации WebSphere Application Server
//* Imports needed for this sample
import javax.security.auth.callback.CallbackHandler;
import java.util.Map;
import java.util.HashMap;
import java.util.Set;
import com.ibm.wsspi.security.auth.callback.WSCallbackHandlerFactory;
import javax.security.auth.Subject;
javax.security.auth.login.LoginContext;

//* Coding example 
Map map = new HashMap();
map.put(Constants.MAPPING_ALIAS, alias);
//create a callback handler with the specified property (to find the alias)
//and null for the managed connection factory (MCF) since we don't need it
CallbackHandler handler = WSMappingCallbackHandlerFactory
				.getInstance().getCallbackHandler(map, null);
Subject subject = new Subject();
LoginContext lc = new LoginContext("DefaultPrincipalMapping", subject, handler);
lc.login();
subject = lc.getSubject();

Set pwdCredentialSet = subject.getPrivateCredentials(PasswordCredential.class);

Object obj = pwdCredentialSet.iterator().next();
if (obj != null) {
		byte[] passphrase = new String(((PasswordCredential) obj)
					.getPassword()).getBytes();
		out.println("password is " + new String(passphrase));
} else {
		out.println("No password credential");
}

21. Поддерживает ли WebSphere Application Server протокол Microsoft NTLM?

Продукт WebSphere Application Server (как и другие продукты IBM, которые исполняются на WebSphere Application Server, такие как WebSphere Portal) в настоящее время не поддерживает протокол NTLM (NT LAN Manager). И IBM, и Microsoft поддерживают Basic Authentication и Mutual Authentication, а также использование SAML или Kerberos в той или иной форме (в зависимости от применяемого протокола приложения).

Более того, планы развития продукта WebSphere Application Server не предусматривают поддержки NTLM, поскольку при разработке полного решения с использованием NTLM имеют место технические проблемы и ограничения. Коротко говоря, NTLM – это закрытый протокол Microsoft для защиты HTTP-транспорта, который обеспечивает аутентификацию, целостность и конфиденциальность для веб-приложений, исполняющихся на платформе Microsoft. Это протокол создан в расчете на работу в рамках только сетевой среды Microsoft. Кроме того, сама компания Microsoft опубликовала заявление о том, что она больше не рекомендует использовать протокол NTLM

В качестве альтернативы для NTLM компания Microsoft предлагает другие, основанные на стандартах, опции для защиты HTTP-транспорта, такие как Basic Authentication, Mutual Authentication, Kerberos и SAML. Все эти опции способны взаимодействовать с несколькими платформами и поддерживаются продуктом WebSphere Application Server.

Приложения на основе веб-сервисов, использующие стандарты WS-Security (в том числе приложения для платформы Microsoft.NET и WebSphere Application Server) способны задействовать вышеупомянутые средства аутентификации HTTP-транспорта. Кроме того, они способны поддерживать аутентификацию SOAP-сообщений на основе стандартов WS-Security, таких как UsernameToken, Kerberos tokens, SAML token, а также аутентификацию на основе стандарта X509. И, наконец, Kerberos и SAML поддерживают передачу идентификационных данных сервера или клиента поставщику веб-сервиса на основе SOAP. Кроме того, следует отметить, что Комитет по стандарту WS-Security OASIS (и Microsoft, и IBM являются членами этого комитета с правом голоса), санкционирует использование профиля SAML Web Services Token Profile для приложений на базе WS-Security.

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

  • NTLM — это проприетарный протокол, который работает автоматически для пользователя домена Windows и для системных учетных записей в рамках среды Microsoft Active Directory.
  • Имеется несколько библиотек с открытым исходным кодом, которые, с учетом пользователя, доменного имени или NetBIOS-имени и пароля для этого пользователя, способны генерировать маркер NTLM. Среда исполнения Java 6, в которой работает продукт WebSphere Application Server, способна генерировать маркер NTLM (при условии, что ей предоставлены эти три параметра). Эти библиотеки также имеет смысл применять в тех средах, в которых процесс имеет доступ к паролю учетной записи, или в которых процесс исполняется на Windows-машине с идентификационными данными домена Windows AD.
  • В сервере приложений потоки исполняются от имени нескольких пользователей, а пароли для этих пользователей недоступны или не сохраняются. По определению, в случае отсутствия пароля конечного пользователя не существует никакого механизма, который позволял бы генерировать маркер NTLM для этого конечного пользователя. Существует возможность для предоставления библиотеке идентификатора/пароля отдельного пользователя, однако это позволит осуществить NTLM-аутентификацию лишь для идентификационных данных сервера. Протокол NTLM не способен поддерживать на серверах приложений сценарии применения, которые требуют передачи идентификационных данных клиента в рамках вызова сервиса.

Следует осознавать, что рекомендуемая компанией Microsoft заменяющая технология аутентификации (Kerberos) поддерживает делегирование учетных записей, что позволяет распространять идентификационные данных пользователя между приложениями без необходимости пароля этого пользователя. Точно так же аутентификация на базе SAML поддерживает распространение идентификационных данных пользователя без пароля или без исходных идентификационных данных Kerberos.

22. Какие меры предосторожности предлагает WebSphere Application Server для предотвращения DOS-атак?

Предотвращение и нейтрализация атак типа DOS (denial of service – отказ от обслуживания) лучше всего осуществляется с помощью брандмауэров и надлежащих сетевых конфигураций, а не с помощью WebSphere Application Server (или любого другого программного продукта связующего уровня). Это объясняется тем, что сам факт использования продукта WebSphere Application Server для защиты от DOS-атак означает, что трафик DOS-атаки уже оказал воздействие на вашу сеть, поэтому любое содействие, которое мог бы обеспечить WebSphere Application Server в этой ситуации, будет иметь ограниченную эффективность.

Тем не менее, имеются некоторые конфигурационные опции, которые могут быть задействованы с целью ослабления воздействия DOS-атаки на обработку запросов WebSphere Application Server. Начнем с плагина HTTP-сервера для WebSphere Application Server. Соответствующие свойства могут быть настроены в конфигурационном файле плагина HTTP-сервера (plugin-cfg.xml) с целью ограничение воздействия большого количества запросов или долго исполняющихся запросов и с целью предотвращения повторных попыток этих запросов, которые могут быть ассоциированы с DOS-атакой.

  • MaxConnections
  • ServerIOTimeOut
  • PostSizeLimit
  • PostBufferSize
  • ServerIOTimeoutRetry

Количество запросов на поддерживаемое (персистентное) соединение и количество клиентских соединений на транспорт веб-контейнера можно ограничить посредством задания следующих параметров:

  • Persistent Connections/Request
  • Maximum Open Connections

, а также следующих атрибутов веб-контейнера для HTTP-запроса, которые позволяют лимитировать размер запроса:

  • Maximum header field size
  • Maximum headers
  • Limit request body buffer size
  • Maximum request body buffer size

Относительно ограничения размера HTTP-данных также следует отметить, что наилучшим образом эта задача решается с помощью брандмауэра или веб-сервера, а не с помощью WebSphere Application Server.


Заключение

Если в этом документе вы не нашли ответов на свои вопросы из области безопасности, обязательно обратитесь к разделу Ресурсы, в частности, к новой странице WebSphere Application Server security на Web-сайте developerWorks, на которой непрерывно анонсируются наиболее примечательные материалы по безопасности продукта WebSphere Application Server.

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=WebSphere
ArticleID=863648
ArticleTitle=Q & A: Вопросы и ответы: ответы на типичные вопросы по безопасности продукта WebSphere Application Server
publish-date=03042013