Обзор sap netweaver portal lukoil com

Обновлено: 04.07.2024

В рамках проекта разработки приложений на базе программной платформы SAP Netweaver AS Java, мы столкнулись с необходимостью настройки собственных схем аутентификации для разработанных приложений. Отсюда и родилась идея, во-первых, структурировать полученные знания, во-вторых, поделиться этими знаниями с другими специалистами в области SAP Basis.

В качестве подопытного стенда использовался SAP Portal на базе SAP NW AS Java 7.5 SP04. Не думаю, что с точки зрения подходов к аутентификации что-то сильно менялось во всех SAP NW AS Java, начиная с версии 7.0, но прошу иметь в виду версию, для которой пишется данная серия статей.

По тексту буду использовать англоязычную терминологию, что бы не возникало сложностей перевода в случае необходимости поиска дополнительной информации в Интернет или при настройке аутентификации непосредственно в SAP NW AS Java.

В первой статье – «От общего к частному» будут раскрыты две темы:

  1. Как, с точки зрения механизмов аутентификации, можно классифицировать приложения на базе программной платформы SAP Netweaver AS Java;
  2. Как определить границу между разработчиками/консультантами приложений и специалистами SAP Basis в вопросах настройки аутентификации для приложений.

От общего к частному

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

  • Java web applications;
  • Web Dynpro Java Applications;
  • Portal applications;
  • Portal iVIews (да, это контейнер для приложений, но SAP в своих документациях его также относит к приложениям).


Java Web Applications

Java Web Application – это любые Java-приложения, разработанные для программной платформы SAP Netweaver AS Java (в контексте данной статьи, конечно же). Хочу отметить, что SAP Portal – это тоже большое приложение Java, которое содержит собственную структуру, свои элементы управления и т.д. Аутентификацию для Java Web Applications можно задавать следующими способами:

  • Через дескриптор web.xml (аутентификация на уровне контейнера Java-приложения);
  • Через дескриптор web-j2ee-engine.xml. (аутентификация на уровне самого Java-приложения). Если аутентификация описана в дескрипторе web-j2ee-engine.xml, то описание в этом дескрипторе считается более приоритетным по сравнению с описанием в дескрипторе web.xml. Чаще всего дескриптор web-j2ee-engine.xml дополняет описание в дескрипторе web.xml;
  • Если в дескрипторах web.xml и web-j2ee-engine.xml нет описания аутентификации, то Java-приложение для аутентификации пользователей использует схему аутентификации, определённую параметром UME: ume.login_context, а также пользовательский интерфейс для аутентификации, определённый параметром UME: ume.login.auth_method;
    Параметр ume.login.auth_method может принимать 4 значения: [FORM, BASIC, DIGEST, CLIENT-CERT]. Параметры ume.login.auth_method и ume.login_context должны дополнять друг друга. Например, если в ume.login.auth_method установлено значение BASIC, то параметр ume.login_context должен указывать на схему аутентификации с модулем аутентификации по логину и паролю.
  • При помощи UME API. В этом случае разработчики при разработке приложения Java будут ссылаться на AuthScheme или AuthScheme-ref, описанные в специальном XML-файе, который определяется параметром UME login.authschemes.definition.file. По умолчанию, login.authschemes.definition.file = authschemes.xml. На следующем рисунке приведён пример authschemes.xml.

Подробное описание структуры дескрипторов web.xml, web-j2ee-engine.xml, а также XML-файла authschemes.xml будете приведено во второй части этой серии статей.

Дескрипторы web.xml и web-j2ee-engine.xml редактируются разработчиками через SAP Netweaver Development Studio. Специалисты SAP Basis могут посмотреть содержание данных дескрипторов для конкретного Java-приложения по следующему пути:

Путь до web.xml и web-j2ee-engine.xml на уровне ОС Linux /usr/sap/[SID]/J00/j2ee/cluster/apps/[application]/[app]/[app]/servlet_jsp/[app]/root/WEB-INF/

Изменять данные дескрипторы на уровне ОС не рекомендуется, так как в случае повторного развёртывания приложения (Deploy Application) разработчиками, сделанные на уровне ОС изменения будут перезаписаны.

Web Dynpro Java Applications

dispwda). С точки зрения аутентификации, в настройках WD Runtime Environment, есть параметр:

sap.default.authentication = (true / false)

Если параметр sap.default.authentication = false, то необходимость аутентификации пользователей для каждого WD Java Application задаётся разработчиками. При помощи SAP NWDS, в свойствах WD Java Application разработчики могут либо активировать Authentication flag для принудительной аутентификации пользователей, либо деактивировать его, если аутентификация пользователей в приложении не требуется.

Если параметр sap.default.authentication = true, то WD Runtime Environment будет требовать аутентификацию пользователей для всех WD Java Applications через схему аутентификации, определённую параметром UME — login.authschemes.definition.file.

Следует упомянуть, что во всех стандартных Web Dynpro Java Applications в качестве схемы аутентификации указано значение “default”. В authschemes.xml это значение также должно быть и оно определено в виде ссылки на схему аутентификации (ниже показана часть файла authschemes.xml, в которой определена authscheme-ref name = “default”).


Portal applications – portal components

Когда разработчик через SAP NWDS создаёт портальное приложение, для этого портального приложения он создаёт портальные компоненты. Для каждого портального компонента разработчик может задать собственную схему аутентификации. Это делается через специальный XML-файл – portalapp.xml все в том же SAP NWDS. Разработчик может указать схему аутентификации – это делается при помощи директивы:

<property name=«AuthScheme» value=«Authschemename»>

В качестве Authschemename должна быть указана либо схема аутентификации (authscheme name), либо ссылка на схему аутентификации (authscheme-ref name), предопределённая в XML-файе, который определяется параметром UME login.authschemes.definition.file (т.е. все тем же authschemes.xml по умолчанию).

Portal iView – это портальный контейнер, в который можно поместить различные объекты, в том числе Web Dynpro Java application, Java web application, и многое другое. И для каждой iView, вне зависимости от того, какой объект она в себе содержит, можно настроить собственный подход к аутентификации. Это делается при помощи параметра “Authentication Scheme”, задаваемого в настройках любого iView. В свою очередь, параметр “Authentication Scheme” обращается всё к тому же XML-файлу, определённому параметром UME: login.authschemes.definition.file = authschemes.xml (по умолчанию). Все стандартные iView можно разделить на две части:

  1. iViews, параметр “Authentication Scheme” для которых равен default;
  2. iVIews, параметр “Authentication Scheme” для которых равен UserAdminScheme.

На рисунке ниже приведено описание обоих “authscheme-refs” из XML-файла, определённого параметром UME: login.authschemes.definition.file:


Заключение

Для всех рассмотренных типов приложений, если еще раз взглянуть на рисунок в начале этой статьи, все стрелки сходятся в элементе UME Authentication: Policy Configurations. Это означает, что дальнейшая конфигурация модулей входа в Систему (Login Modules) будет настраиваться здесь для всех типов приложений.

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

  1. дескрипторов web.xml и web-j2ee-engine.xml;
  2. XML-файла Authschemes.xml.
  • Получение доступа к настройкам параметров UME;
  • Получение доступа к настройкам Policy Configurations;
  • Получение доступа к настройке sap.default.authentication компонента Web Dynpro Runtime Environment.

Приложение

Получение доступа к настройкам параметров UME

  • ume.login_context;
  • ume.login.auth_method;
  • login.authschemes.definition.file.

Configuration -> Security -> Identity Management


На экране Identity Management нажмите «Configuration»:


Перейдите в режим эксперта (Open Expert Mode):


Будут отображены все параметры UME, которые можно, при необходимости, изменить.

Получение доступа к настройкам Policy Configurations

Доступ к Policy configurations можно получить через Netweaver Administrator (/nwa).

Configuration -> Security -> Authentication and Single Sign-On


Откроется приложение, где можно создать, изменить или просмотреть существующие Policy Configurations


Получение доступа к настройке sap.default.authentication компонента Web Dynpro Runtime Environment

Доступ к параметрам компонента Web Dynpro Runtime Environment можно получить через Netweaver Administrator (/nwa).

- SAP NetWeaver Application Server; Компоненты SAP NetWeaver Application Server; Разработка приложений для SAP NetWeaver AS ABAP и AS Java
- Business Process Management; Анализ SAP NetWeaver Process Integration
- SAP и SOA: платформа работы с бизнес-процессами; Business Process
- Management в SAP - Инструменты; Повышение продуктивности работы пользователей; SAP NetWeaver Portal – Архитектура и вид от лица пользователя; SAP NetWeaver Portal – Интеграция приложений SAP
- SAP NetWeaver Portal - Knowledge Management и Collaboration
- SAP NetWeaver Mobile; Бизнес-аналитика и управление информацией EDW - Хранение; EDW - Data Provisioning; Business Intelligence и BusinessObjects; Управление основными данными с SAP NetWeaver Master Data Management; Управление жизненным циклом ПО и SAP Solution Manager
- Составление перечня задач управления жизненным циклом ПО
- Позиционирования SAP Solution Manager и его использование в проектах внедрения; Использование SAP Solution Manager в администрировании систем SAP; SAP NetWeaver – Аспекты безопасности; SAP NetWeaver Information Lifecycle Management

- Ознакомление с концепцией SAP NetWeaver
- Оценить преимущества от использования SAP NetWeaver в вашей компании
- Получение обзора различных компонентов SAP NetWeaver

Примечания

- Данный семинар является вводным. Он предлагает основную информацию о SAP NetWeaver
- Подробнее внедрение SAP NetWeaver и соответствующие аспекты SAP NetWeaver PI освещаются в отдельных семинарах, таких как BIT100, BIT400, BIT430, BIT 460, TBIT44, TBIT50, и TBIT51. Для дополнительной информации обращайтесь к описанию линейки семинаров BIT.
- Для дополнительной информации о разработках ABAP и Java обращайтесь к описанию линейки семинаров по разработке.
- Для дополнительной информации о BI обращайтесь к описанию линейки семинаров.
- Для дополнительной информации об Enterprise Portal обращайтесь к семинарам линейки Portal (EP).
- Для дополнительной информации об Application Lifecycle Management обращайтесь к семинарам линейки ALM.
- Для дополнительной информации о Solution Manager обращайтесь к соответствующим семинарам.

Популярность SAP NetWeaver Portal и его доступность из сети Интернет делают его привлекательным объектом для атаки на компании разного масштаба и профиля. В данной статье рассматривается, как потенциальный злоумышленник может взломать этот популярнейший модуль ERP-системы SAP и каким образом можно избежать подобной угрозы.

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

Отличительная особенность SAP Portal состоит в том, что он связан практически со всеми остальными компонентами SAP, развернутыми в сети компании. Таким образом, компрометация SAP Portal приведет не только к компрометации всей обрабатываемой в нем информации, но и к превращению его в своеобразный плацдарм для дальнейших атак злоумышленника.

Многие пользователи пребывают в ложной уверенности, что ERP-система SAP не доступна из Интернет. Между тем, доступ к SAP Portal зачастую можно получить из сети Интернет, используя, например, простой Google Dork inurl:/irj/portal , где можно найти большое количество SAP Portal, доступных для подключения:


Поисковик Shodan также позволяет легко обнаруживать доступные SAP Portal.


Популярность SAP NetWeaver Portal и его доступность из сети Интернет делают его привлекательным объектом для атаки на компании разного масштаба и профиля. Рассмотрим SAP Portal более детально.

АРХИТЕКТУРА SAP NETWEAVER PORTAL

Архитектура SAP Portal представлена на рисунке ниже.


Как видно из схемы, основой системы является Web Application Server (SAP J2EE), в контексте которого работает портал. Сам же Portal представляет собой платформу для работы разного рода модулей, главными из которых являются iViews, приложения и Web-сервисы.

На схеме видно, что SAP Portal связан с базой данных, а также с множеством других компонентов и моделями SAP.

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

АТАКИ НА SAP NETWEAVER J2EE

SAP NetWeaver J2EE является основой SAP Portal, поэтому важно понять, как злоумышленник может скомпрометировать J2EE. Для этого необходимо разбираться в некоторых нюансах работы J2EE.

Доступ к приложениям, работающим в J2EE, определяется разработчиками этих приложений с помощью файла-дескриптора, который называется web.xml. Ниже представлен пример такого файла-дескриптора.

Рассмотрим его подробнее.

Однако аутентификацию можно обойти: если пользователь сделает запрос, отличный от GET , то его роль пользователя проверяться не будет. Разработчики, как правило, ограничивают доступ к приложению для методов GET и POST , однако иногда забывают про метод HEAD . Последний аналогичен GET , за исключением одного отличия – ответ сервера содержит лишь заголовок. Таким образом, если злоумышленник найдет приложение, которому для работы не требуется подтверждения от сервера, он может попробовать воспользоваться данной ошибкой.

И хотя сервлет CTC предусматривает аутентификацию при использовании методов GET и POST, злоумышленник может получить административный доступ к ERP-системе, используя всего два запроса HEAD к SAP Portal:
• создаем нового пользователя blabla с паролем blabla

• добавляем созданного пользователя в группу Administrators

Данный тип атаки называется Verb Tampering. Для защиты системы необходимо:
• установить SAP-ноты: 1503579,1616259
• проверить все файлы web.xml. Это можно сделать с помощью утилиты ERPScan WEB.XML checker.

Invoker Servlet. Взглянем на web.xml еще раз.

Обратим внимание еще на один важный тег – url-pattern , описывающий URI, по которому будет предоставлен доступ к сервлету. Таким образом, отправив запрос GET по URI /admin/critical/CriticalAction , пользователь получит доступ к сервлету CriticalAction, если будет иметь роль администратора.

Однако и в данном случае злоумышленник может обойти аутентификацию и получить доступ к сервлету. Дело в том, что по умолчанию в SAP включен механизм InvokerServlet, который позволяет обращаться к сервлетам по специально сформированным ссылкам. Иначе говоря, злоумышленник может обратиться к сервлету CriticalAction по URI /servlet/com.sap.admin.Critical.Action и получить доступ, не имя никакой роли, так как данный URI не соответствует указанному в url-pattern.

Для атаки на реальные ERP-системы злоумышленник может использовать все тот же сервлет CTC. Помимо управления пользователями он позволяет выполнять команды ОС, на которой работает SAP Portal, например «создать пользователя».


На рисунке показано выполнение команды ipconfig на сервере SAP Portal.

Для защиты системы необходимо:
• установить SAP-ноты: 1467771, 1445998;
• проверить все файлы web.xml (это можно сделать с помощью утилиты ERPScan WEB.XML checker).

Теперь перейдем к рассмотрению возможных атак непосредственно на портал.

ПРЯМЫЕ АТАКИ НА ПОРТАЛ

Security Zone. В Portal есть модуль, которая называется Security Zone. Он служит дополнительным инструментом для конфигурирования доступа к программам портала (iViews). Зоны определяются для каждого приложения в файле-дескрипторе portalapps.xml и имеют такой критичный параметр, как Safety Level. Он отвечает за уровень доступа к приложению. Safety Level предусматривает четыре уровня безопасности:

• No Safety
o Анонимным пользователям разрешается доступ к компонентам портала, определенным в зоне безопасности.
• Low Safety
o Пользователь должен быть по меньшей мере пользователем портала, чтобы получить доступ к компонентам портала, определенным в зоне безопасности.
• Medium Safety
o Пользователь должен иметь на портале конкретную роль, которой предоставлено право доступа к компонентам портала, определенным в зоне безопасности.
• High Safety
o Пользователь должен иметь на портале роль с высокими административными правами, которой предоставлено право доступа к компонентам портала, определенным в зоне безопасности.

Разработчики должны внимательно подходить к заданию Safety Levels, так как, если пользователь обращается, например, к iView по прямому URL: /irj/servlet/prt/portal/prtroot/<iView_ID> , то доступ к приложению будет проверяться только по результатам проверки Safety Level.

В SAP Portal был обнаружен ряд критичных приложений с Safety Level= No Safety . Для защиты системы необходимо проверить настройки приложений Safety Level.

XSS. SAP Portal является Web-приложением, поэтому ему свойственны все характерные для web-приложений уязвимости. Одной из таких является межсайтовый скриптинг (XSS). Однако, в отличие от классических векторов для подобного рода атак, при атаке на портал злоумышленник может использовать особенности Portal – например, технологию EPCF, позволяющую получить доступ к данным пользователя через специальный JavaScript API.

Пример такой «зловредной» нагрузки:


Для защиты системы необходимо:
• установить SAP-ноту: 1656549.

Directory traversal. Речь идет еще об одной классической атаке на Web-приложения. Однако и здесь имеется своя специфика – например, выход за пределы каталога осуществляется не традиционными символами /../ , а !252f. 252f , как в данной уязвимости:


Для защиты системы необходимо:
• установить SAP-ноту: 1630293.

XML External Entity. Это классическая атака на XML-транспорт Web-приложений. XML является одним из основных транспортов в SAP NetWeaver Portal, поэтому потенциальный злоумышленник может пытаться скомпрометировать систему через него – в частности, получить административный доступ в SAP Portal.

В SAP есть специальное хранилище паролей SAP Security Storage, расположенное в файле SecStore.properties. Пароли зашифрованы, однако ключ для расшифровки расположен в том же каталоге, что и пароли (в файле SecStore.key). Таким образом, если злоумышленник сможет прочитать данные файлы, то он сможет расшифровать пароли и получить административный доступ к порталу.

Эта атака осуществляется в несколько этапов:
• нахождение уязвимости, позволяющей читать файлы сервера SAP-Portal;
• чтение файл SecStore.properties с зашифрованными паролями;
• чтение файла SecStore.key с ключами для расшифровки паролей;
• расшифровка административного пароля и получение доступа в SAP Portal.

В качестве уязвимости, позволяющей читать файлы с сервера SAP Portal, можно использовать описанные ранее. Это может быть Directory Traversal, Command Execution.

Отдельно хотелось бы продемонстрировать внедрение внешних XML-модулей (XXE). Вот так выглядит типичный запрос к порталу в сниффере.


Как можно видеть, запрос POST содержит огромное количество параметров. Если присмотреться, в одном из них указан XML.


Именно в него и попытаемся внедрять запрос, который вернет содержимое файлов SecStore.properties и SecStore.key .


На рисунке показано, как можно читать файлы с сервера SAP Portal, используя для этого уязвимость XXE.

После успешного прочтения файлов их можно расшифровать с помощью утилиты ERPScan SecStore descriptor.

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


Раскрытие информации. Вместе с SAP Portal поставляется множество сервисов, которые могут быть использованы злоумышленниками для получения информации при планировании атак на систему. Однако возможны и иные векторы развития событий – например, использование портала в качестве плацдарма для дальнейших действий. Здесь хранится множество документов, и при помощи простого механизма внутреннего поиска и запросов наподобие secret или password , злоумышленник может узнать большое количество конфиденциальной информации.

Первая часть серии статей «Настройка аутентификации в SAP Netweaver AS Java» рассказывала о различных подходах к настройке аутентификации в приложениях, запускаемых на программной платформе SAP NW AS Java. Также в ней были обозначены области ответственности различных проектных групп (разработчики, функциональные консультанты, специалисты SAP Basis) за выполнение настроек аутентификации.

На общей схеме, введённой еще в первой части, обозначил элементы, которые буду сейчас рассматривать – это дескрипторы web.xml, web-j2ee-engine.xml, а также XML-файл схем аутентификации authschemes.xml.


Описание аутентификации в дескрипторе web.xml

Еще раз хочу напомнить, что дескриптор web.xml должен редактироваться разработчиками через SAP NWDS. Не стоит изменять его на уровне ОС.

Данный дескриптор описывает Java-контейнер, который содержит приложение Java. На уровне этого контейнера можно настроить схему аутентификации.

Для описания настроек аутентификации на уровне Java-контейнера, в дескрипторе web.xml необходимо использовать тег <login-config> … </login-config>. В нём задаются все необходимые параметры для описания аутентификации.

Для Java-контейнера мы можем использовать всего 4 стандартных метода аутентификации:

  • BASIC
  • FORM
  • CLIENT_CERT
  • DIGEST

BASIC authentication method – это когда система для ввода логина и пароля пользователя выдаёт примерно вот такое окно (вид окна зависит от браузера пользователя и его видом управлять не получится):

Данный метод аутентификации привязан к Policy configuration “basic”, в котором по умолчанию содержится один Login Module: BasicPasswordLoginModule. Этот login module выполняет проверку введённого логина и пароля через стандартные механизмы аутентификации User Management Engine (UME).


Метод аутентификации BASIC задаётся в дескрипторе web.xml при помощи следующих тегов:


В теге <realm-name> указывается область безопасности. Смысл этой области безопасности попробую объяснить на примере:

Рассмотрим два приложения: Application 1 и Application 2. Для обоих приложений в дескрипторе web.xml указаны: auth-method = BASIC и realm-name = MySecurityRealm.

Пользователь обращается к Application 1 и приложение запрашивает у него логин и пароль через BASIC-форму. Пользователь вводит свои учётные данные и успешно аутентифицируется в Application 1. Далее пользователь переходит в приложение Application 2. Система не будет запрашивать у пользователя повторного ввода учётных данных, так как realm-names обоих приложений совпадают –их имя MySecurityRealm. Если бы для Application 2 был указан другой realm-name, то при переходе в Application 2 Система попросила бы пользователя ввести учётные данные пользователя повторно.

FORM authentication method — это когда пользователю для ввода логина и пароля система выдаёт некий дружественный интерфейс.

SAP предоставляет собственный интерфейс для ввода учётных данных пользователя и обычно он выглядит следующим образом:


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

Если же мы планируем использовать стандартный интерфейс, то достаточно определить следующие теги в дескрипторе web.xml приложения Java:


Если для нашего Java-приложения мы хотим использовать разработанный интерфейс, то в дескрипторе web.xml мы должны определить следующие теги:


Тег <form-login-page> задаёт разработанную страницу входа. Тег <form-error-page> задаёт страницу для тех случаев, когда произошла ошибка аутентификации пользователя.

Метод аутентификации FORM привязан к Policy configuration “form”, в котором по умолчанию содержится один Login Module: BasicPasswordLoginModule.


CLIENT_CERT authentication method – это когда приложение запрашивает пользователя предоставить сертификат пользователя для аутентификации. Для пользователя это будет выглядеть примерно следующим образом:


Для использования CLIENT_CERT authentication method, в дескрипторе web.xml должны быть определены следующие теги:


Данный метод аутентификации привязан к Policy configuration “client_cert”, в котором по умолчанию содержится один Login Module: ClientCertLoginModule.


DIGEST authentication method. Данный метод аутентификации аналогичен методам BASIC и FORM, т.е. также запрашивает ввод логина и пароля. Только в случае DIGEST, передаётся хэш пароля, а не сам пароль, как в случае методов аутентификации BASIC или FORM. Однако данный метод аутентификации не получил широкого распространения. Видимо потому, что проще и логичнее будет настроить SSL-шифрование канала связи, нежели использовать метод аутентификации DIGEST.

Данный метод аутентификации привязан к Policy configuration “digest”, в котором по умолчанию содержится один Login Module: DigestLoginModule.


Описание схемы аутентификации в дескрипторе web-j2ee-engine.xml

Дескриптор web-j2ee-engine.xml, по аналогии с web.xml, должен редактироваться только разработчиками через SAP NWDS. Не стоит изменять его на уровне ОС.

В данном дескрипторе, в отличие от дескриптора web.xml, можно детально описать целый Authentication stack (т.е. набор модулей регистрации в системе (Login Modules)).

Помимо описания Authentication stack, в дескрипторе web-j2ee-engine.xml должен быть указан Policy domain (тег <security-policy-domain>). Policy domain – это область безопасности (по аналогии с Realm name). Разница между Realm name и Policy domain в следующем:

  • Realm name: Используется только в рамках BASIC аутентификации. В случае одинаковых Realm name для двух разных приложений, система в любом случае вызовет Login Module для проверки аутентификации при обращении ко Application 2 после успешной аутентификации в Application 1. Этот модуль увидит, что Application 2 находится в том же Realm name, что и Application 1 и не будет повторно запрашивать учётные данные пользователя.
  • Policy Domain: Используется для Authentication stack (т.е. для группы различных Login Modules). Если для двух разных приложений указан один и тот же Policy Domain и аутентификация в Application 1 – успешная, то при вызове Application 2 система не будет инициировать аутентификацию пользователя через указанный во Application 2 Authentication stack. Если же Policy Domains для двух приложений различны, то проверка аутентификации будет инициирована системой через Authentication stack, указанный в Application 2.

Описание схемы аутентификации через XML-файл authschemes.xml

Если создание и редактирование файлов web.xml и web-j2ee-engine.xml – это задача разработчиков, то XML-файл authschemes.xml, который определяется параметром UME: login.authschemes.definition.file находится в ответственности специалистов SAP Basis.

Данный файл лежит в базе данных Системы и доступ к нему можно получить через стандартный графический инструмент – ConfigTool.

Что бы добраться до места расположения файла authschemes.xml, необходимо в ConfigTool перейти в Configuration editor mode:


В древовидном меню добираемся до директории:
Configurations:: cluster_config -> system -> custom_global -> cfg -> services -> com.sap.security.core.ume.service -> persistent.

В данной директории лежит файл authschemes.xml, который можно выгрузить, отредактировать, загрузить обратно. Только обратите внимание на кодировку. Если вы его выгрузите на уровень ОС, отредактируете и сохраните в другой кодировке, то есть шанс, что система его не сможет прочитать, поэтому будьте бдительны!

Вы также можете создать свой XML-файл со схемами аутентификации по шаблону или с нуля – как вам угодно. Только не забудьте потом в параметре UME login.authschemes.definition.file указать ваш новый XML-файл. А также не забудьте, что все стандартные Web Dynpro Java Applications будут искать в этом XML-файле “authscheme-ref name” = default, а Portal iViews будут искать в нём “authscheme-ref name” = [default или UserAdminScheme].

Если с этими нюансами все понятно, то можно приступить и к изучению структуры стандартного XML-файла authschemes.xml

Структура файла authschemes.xml

Authentication Schemes (authschemes.xml) – это перечень схем аутентификации, которые могут использоваться портальными приложениями, приложениями Web Dynpro Java и портальными iView в рамках Системы. Java web applications также могут использовать Authentication Schemes, если при написании кода разработчики используют UME APIs.

В случае, если приложение ссылается на неописанную в authschemes.xml схему аутентификации или в приложении в принципе не описана ни одна схема аутентификации, то для аутентификации пользователя в таком приложении будете применена схема аутентификации, указанная в параметре UME: login.authschemes.default.

На следующей картинке я изобразил структуру XML-файла authschemes.xml.


Как видно из рисунка, файл authschemes.xml состоит из схем аутентификации (Authscheme 1, Authscheme 2, …, Authscheme N) и перечня ссылок на схемы аутентификации (Authscheme-ref 1, Authscheme-ref 2, и т.д.). Схем аутентификации и ссылок на них может быть сколько угодно, в зависимости от ваших проектных требований.

Начну, я, пожалуй, со ссылок (References или Refs). Здесь все просто. Пишется имя ссылки в теге <authscheme-ref name> и указывается имя схемы аутентификации, на которую мы хотим сослаться во вложенном теге . Как я уже неоднократно говорил – все стандартные Portal iViews и Web Dynpro Java Applications используют предопределённые Refs: “default” и “UserAdminScheme”. Причём, если присмотреться к стандартному XML-файлу authschemes.xml, то можно увидеть, что “default” и “UserAdminScheme” ведут на одну и ту же схему аутентификации: uidpwdlogon.


Если, например, мы захотим для пользовательских iVIew и для iView администраторов пользователей сделать разные схемы аутентификации, мы можем это сделать, изменив схему аутентификации с uipwdlogon на любую другую, например на MyOwnAuthScheme для ссылки <authscheme-ref name=”UserAdminScheme”>.

Впрочем, использование ссылок в authschemes.xml – это, скорее, фича, которой в общем-то можно и не пользоваться. В приложениях, которые используют Authentication Schemes, можно сразу ссылаться на любую из определённых в authschemes.xml схем аутентификации.

Каждая AuthScheme из файла authschemes.xml имеет свой набор параметров:

  • Authentication template;
  • Priority;
  • Frontend type;
  • Frontend target;

Priority. Смысл этого параметра попробую объяснить на примере. У нас есть два приложения:

  • Application 1, которое использует схему аутентификации AuthUserPass только по логину и паролю;
  • Application 2, которое использует схему аутентификации AuthCert только по сертификату пользователя.

Frontend type. Определяет тип интерфейса, который будет вызываться для взаимодействия Системы с пользователем. Возможны следующие варианты: 0, 1 или 2:


Также это приложение можно найти в SAP Portal Content Directory:



Заключение

В данной статье была рассмотрена структура дескрипторов web.xml и web-j2ee-engine.xml. Также была рассмотрена структура XML-файла authschemes.xml. Если возникли вопросы, пишите в комментариях, попробую ответить.

В следующей части серии статей про настройку аутентификации в SAP Netweaver AS Java я буду описывать Policy Configurations и возможности, которые можно достичь с их помощью.

Читайте также: