Вступление
Первая часть серии статей «Настройка аутентификации в 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
Если же вы хотите использовать аутентификацию Kerberos или SAML, подход описания метода аутентификации только через дескриптор web.xml не подойдёт!
Далее подробно расскажу про эти 4 метода аутентификации.
BASIC authentication method – это когда система для ввода логина и пароля пользователя выдаёт примерно вот такое окно (вид окна зависит от браузера пользователя и его видом управлять не получится):
Данный метод аутентификации привязан к Policy configuration “basic”, в котором по умолчанию содержится один Login Module: BasicPasswordLoginModule. Этот login module выполняет проверку введённого логина и пароля через стандартные механизмы аутентификации User Management Engine (UME).
Метод аутентификации BASIC задаётся в дескрипторе web.xml при помощи следующих тегов:
<login-config>
<auth-method>BASIC</auth-method>
<realm-name>myRealm</realm-name>
</login-config>
В теге <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:
<login-config>
<auth-method>FORM</auth-method>
</login-config>
Если для нашего Java-приложения мы хотим использовать разработанный интерфейс, то в дескрипторе web.xml мы должны определить следующие теги:
<login-config>
<auth-method>FORM</auth-method>
<form-login-config>
<form-login-page>/mylogin.jsp</form-login-page>
<form-error-page>/myerror.jsp</form-error-page>
</form-login-config>
</login-config>
Тег <form-login-page> задаёт разработанную страницу входа. Тег <form-error-page> задаёт страницу для тех случаев, когда произошла ошибка аутентификации пользователя.
Метод аутентификации FORM привязан к Policy configuration “form”, в котором по умолчанию содержится один Login Module: BasicPasswordLoginModule.
CLIENT_CERT authentication method – это когда приложение запрашивает пользователя предоставить сертификат пользователя для аутентификации. Для пользователя это будет выглядеть примерно следующим образом:
Для использования CLIENT_CERT authentication method, в дескрипторе web.xml должны быть определены следующие теги:
<login-config>
<auth-method>CLIENT_CERT</auth-method>
</login-config>
Данный метод аутентификации привязан к 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.
Структура web-j2ee-engine.xml хорошо описана на портале help.sap.com по следующей ссылке.
Описание схемы аутентификации через 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;
Authentication template. Это предопределённая Policy configuration, создание и наполнение которой я буду описывать в третьей части серии статей про настройку аутентификации в SAP Netweaver AS Java. В качестве шаблона (template) мы должны указывать одну из таких Policy configurations. Учитывая, что в Policy configuration описываются Login modules, то наша схема аутентификации будет знать, какие модули регистрации в Системе ей необходимо использовать.
Priority. Смысл этого параметра попробую объяснить на примере. У нас есть два приложения:
- Application 1, которое использует схему аутентификации AuthUserPass только по логину и паролю;
- Application 2, которое использует схему аутентификации AuthCert только по сертификату пользователя.
Пусть Priority для AuthUserPass = 20, а Priority для AuthCert = 40. Если пользователь аутентифицировался в Application 1 (по идентификатору и паролю) и перешёл в Application 2 (которое просит аутентификацию по сертификату), то пользователю для аутентификации в Application 2 придётся предъявить клиентский сертификат, так как приоритет у AuthCert (40) > AuthUserPass (20). Рассмотрим обратный вариант – пользователь аутентифицировался в Application 2 (по сертификату) и перешёл в Application 1 (которое просит аутентификацию по логину и паролю). Учитывая, что приоритет у AuthCert (40) > AuthUserPass (20), Система пустит пользователя в Application 1 без запроса логина и пароля.
Frontend type. Определяет тип интерфейса, который будет вызываться для взаимодействия Системы с пользователем. Возможны следующие варианты: 0, 1 или 2:
- 0 – TARGET_FORWARD – указывает, что вызов будет произведён в другой servlet (если честно, для меня так и осталось загадкой, какое приложение можно вызывать для этого типа фронтэнда – информации очень мало. Кто знает, где это можно использовать – напишите в комментариях);
- 1 – TARGET_REDIRECT – указывает, что вызываемое приложение будет находиться по другому HTTP-адресу (будет произведён редирект);
- 2 – TARGET_JAVAIVIEW – указывает, что вызываемое приложение для ввода учётных данных является портальным Java iView. Как правило, именно этот вариант необходимо использовать для стандартных методов аутентификации (используется для всех портальных приложений).
Frontend target. Указывает, какое приложение должно быть запущено Системой при взаимодействии с пользователем для предоставления учётных данных. В стандартном authschemes.xml файле в качестве Frontend target для разных схем аутентификации указаны приложения:
Это Portal components, которые принадлежат одному и тому же Portal application: com.sap.portal.runtime.logon. Этот Portal application можно найти на уровне ОС SAP-системы и при помощи разработчиков доработать его:
Также это приложение можно найти в SAP Portal Content Directory:
Заключение
В данной статье была рассмотрена структура дескрипторов web.xml и web-j2ee-engine.xml. Также была рассмотрена структура XML-файла authschemes.xml. Если возникли вопросы, пишите в комментариях, попробую ответить.
В следующей части серии статей про настройку аутентификации в SAP Netweaver AS Java я буду описывать Policy Configurations и возможности, которые можно достичь с их помощью.
Автор: Евгений
