Вступление

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

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

На общей схеме, введённой еще в первой части, обозначил элементы, которые буду рассматривать сейчас – это Policy Configurations.

Policy Configurations. Общая структура

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

В дескрипторе web.xml мы описываем метод аутентификации, который неразрывно связан с policy configuration (например, метод аутентификации “FORM” связан с policy configuration “form”);
В дескрипторе web-j2ee-engine.xml для Java web applications мы даже описываем саму policy configuration со всеми Login modules. Кстати, Policy configurations для таких приложений отображаются с типом Web (см. рисунок ниже). Web Policy configurations в списке большинство, так как каждое Java-приложение, для которого разработчик создал дескриптор web-j2ee-engine.xml или web.xml будет отображено отдельным Policy configuration.

Для Portal applications, Web Dynpro Java Applications и iViews мы используем Схемы аутентификации (Authschemes) и ссылки на них (Authschemes-refs), которые также отображаются в виде Policy configurations, но уже с типом Other.

Также мы можем создавать свои собственные Policy configurations через редактор в SAP Netweaver Administrator (NWA) и привязывать их к приложениям в виде шаблонов (Templates) или задавать в параметрах UME, описанных в первых двух статьях. Созданные через редактор Policy configurations будут иметь тип Custom.

Итак, Policy Configuration – это сущность, которая имеет набор свойств (Properties) и включает в себя Authentication Stack.

В Properties отображаются такие характеристики, как: realm_name, policy_domain, priority, template, frontendtarget, auth_method и т.д. Если Policy configuration создаётся через редактор вручную, то, при необходимости, properties мы также можем добавить вручную. Если это делается через дескрипторы web.xml или web-j2ee-engine.xml, то мы увидим в properties то, что задал разработчик в этих дескрипторах.

Authentication Stack – это сущность, которая состоит из элементов, изображенных на следующей картинке:

Template. В качестве шаблона для вновь создаваемых Authentication Stacks можно использовать уже готовый Authentication Stack с типом “Template” или “Custom”. В этом случае новый Authentication Stack унаследует настройки Login Modules и Session Fixation Protection из шаблона. Настройки Logon policy при этом не наследуются.

Session Fixation Protection. Может так сложиться, что клиентское ПО вызывает два приложения с разными Authentication stacks практически одновременно (с разницей не более 2 секунд). Это редкий случай и в стандарте вряд ли такое может случиться. Но если такое происходит, сервер может выдать ошибку 403 — " Possible session fixation attack detected! Contact your system administrator with a reference to SAP Note 1417679!".

Если мы уверены, что у нас нет таких приложений, то Session Fixation Protection необходимо установить в значение Strict (оно используется по умолчанию). В случае, если два разных приложения с разными Authentication stacks должны вызываться параллельно, и это единственное решение в вашем конкретном случае (чего лучше не допускать), параметр Session Fixation Protection необходимо установить в значение Grace Period для приложения, которое выдаёт ошибку 403 – “Possible session fixation attack detected!...».

Policy domain – про него уже подробно было написано во второй части, поэтому повторяться не буду.

Login Modules и Logon Policy – оба этих элемента являются наиболее интересными для нас с точки зрения настройки стека аутентификации. Login Modules напрямую связан с аутентификацией (т.е. с проверкой подлинности клиента). А Logon Policy – это набор правил, разрешающих или запрещающих пользователю по каким-либо критериям использовать Authentication Stack при обращении к приложению (например, если пользователь не состоит в группе Administrators, то аутентификация запрещена).

Login Modules

Login module – это программный модуль, который позволяет SAP-системе проверить данные аутентификации, предоставленные пользователем. В стандартной поставке SAP Netweaver AS Java 7.40 я насчитал 21 Login Module и каждый из них имеет свои особенные параметры для тонкой настройки. Описание каждого такого модуля по отдельности заслуживает отдельной статьи, поэтому я лишь приведу несколько наиболее часто используемых модулей и дам краткое описание для них:

BasicPasswordLoginModule – выполняет аутентификацию пользователя по предоставленным через методы аутентификации FORM или BASIC учётным данным (логин и пароль);
CreateTicketLoginModule – создаёт SAP Logon Ticket (т.е. по сути дела создаёт сессионный cookie для веб-браузера клиента), который при определённых условиях и на определённый срок будет вашим «паспортом» для входа в приложения;
EvaluateTicketLoginModule – выполняет аутентификацию по SAP Logon Ticket, полученный при помощи модуля CreateTicketLoginModule;
ClientCertLoginModule – выполняет аутентификацию пользователя с использованием клиентского сертификата.

Инструмент Login Modules даёт возможность компоновать отдельные модули в последовательность выполняемых модулей для обеспечения гибкого процесса аутентификации в системе.

Предлагаю рассмотреть следующую последовательность модулей:

На рисунке видно, что для каждого Login Module из этой последовательности указывается флаг, который определяет поведение выполняемого модуля. В приведённой последовательности будет происходить следующее:

Выполнится логин модуль EvaluateTicketLoginModule. В случае, если веб-браузер пользователя имеет действительный для системы SAP Logon Ticket, последующие модули выполняться не будут, так как стоит флаг SUFFICIENT (т.е. данного модуля достаточно для аутентификации пользователя и никаких последующих модулей выполнять не требуется). Если же аутентификация не успешная, то выполнение передаётся следующему модулю — ClientCertLoginModule;
Модуль ClientCertLoginModule, получая данные, как правило, из метода аутентификации CLIENT-CERT, проверяет эти данные. На рисунке видно, что для этого модуля установлен флаг OPTIONAL. Это означает, что вне зависимости от успешности или не успешности проверки аутентификации этим модулем, мы перейдём к следующему модулю (в нашем примере это CreateTicketLoginModule), но результат проверки модулем ClientCertLoginModule будет доступен следующему по списку модулю, т.е. модулю CreateTicketLoginModule;
Модуль CreateTicketLoginModule получит результат проверки предыдущим модулем. В случае успешной аутентификации на предыдущем модуле, для веб-браузера пользователя будет сгенерирован и передан SAP Logon Ticket. Также CreateTicketLoginModule выполнит проверку аутентификации по выданному SAP Logon Ticket (она конечно же будет успешной) и, учитывая, что для этого модуля стоит флаг SUFFICIENT, управление будет передано обратно программе (последующие модули выполняться не будут). В случае не успешной аутентификации предыдущим модулем, модуль CreateTicketLoginModule не выдаст пользователю SAP Logon Ticket и, конечно же, даже не будет его проверять и, как результат, просто передаст управление следующему модулю (BasicPasswordLoginModule);
В нашем примере, модуль BasicPasswordLoginModule имеет флаг REQUISITE. Это означает, что в случае не успешной аутентификации этим модулем, последующие модули выполняться не будут и управление сразу же будет передано обратно программе с результатом — «не успешная аутентификация». В случае успешной аутентификации, будет выполняться следующий модуль. Т.е. в случае успешной аутентификации по логину и паролю, управление будет передано модулю CreateTicketLoginModule, работу которого мы уже описали.

В нашем примере для модуля BasicPasswordLoginModule мы могли бы поставить флаг OPTIONAL – ровным счётом ничего бы не поменялось. А для пятого модуля (CreateTicketLoginModule) – флаг SUFFICIENT или оставить тот же OPTIONAL – результат работы всего стека был бы тем же…

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

Logon Policy

Как уже упоминалось ранее, Logon Policy – это набор правил, разрешающих или запрещающих пользователю по каким-либо критериям использовать Authentication Stack при обращении к приложению.

По умолчанию, данный функционал не активен в SAP-системе. Поэтому, если вы решили его использовать, то необходимо параметр UME: ume.logon.apply_logon_policies установить в значение true.

Создание и редактирование Logon policies доступно в SAP Netweaver Administrator (NWA): Configuration -> Authentication and Single Sign-On. Закладка Authentication -> Logon Policies).

Структура Logon policy выглядит следующим образом (см. рисунок ниже):

Logon policy может содержать множество правил (Rules), а каждое правило должно содержать условия выполнения этого правила — Conditions.

Возможности Logon Policies лучше всего рассмотреть на следующем примере. Пусть в вымышленном проекте стоит следующая задача: к определённым приложениям необходимо разрешать доступ только группе Administrators с IP-адресов 10.1.4.0/32. И вообще, пусть Администраторы работают только в рабочее время – с понедельника по пятницу, с 8:00 до 18:00. Для этих целей создадим Logon Policy (например, MyOwnLogonPolicy) с одним правилом (например, MyOwnRule1) и четырьмя условиями (см. рисунок ниже), которые и будут определять наши требования по нашему вымышленному проекту.

Помимо тех категорий, которые мы обозначили в нашем примере (Group, Days Of Week, IP Address, Time), есть и другие, не менее интересные категории, которые можно использовать:

User – разрешает или запрещает аутентифицироваться конкретным пользователям системы;
Role – разрешает или запрещает аутентифицироваться пользователям с конкретными ролями;
HTTP Header – разрешает или запрещает аутентифицироваться пользователям, в заголовке HTTP-запроса которых есть определённые значения. В том числе, для значений HTTP-заголовка можно использовать регулярные выражения. (см. рисунок ниже).

Таким образом, при помощи категории HTTP Header можно значительно расширить возможности Logon Policies.

Заключение

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

Настройка аутентификации в SAP Netweaver AS Java (Часть 3 из 3)