Интеграция SAP NetWeaver AS Java с Keycloak: SAML, 2FA и неожиданные проблемы

Хабр, привет!

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

Типичная защита периметра: «свои» внутри, «чужие» снаружи. Но бывает инверсия. Заказчик открывает SAP NetWeaver AS Java в большой мир. SAML в этой системе активируется быстрее, чем вы моргнете — буквально в два клика. Но если на том конце провода не дремлет злоумышленник, а у вас нет 2FA… считайте, что ключи от дома вы спрятали под ковриком.

Мы столкнулись с этой болью на проекте у одного из заказчиков. Нужно было настроить двухфакторную аутентификацию. И вот тут начались нюансы.

В этом материале мы опишем настройку интеграции портала SAP NetWeaver AS Java с внешним Identity Provider (IdP) — Keycloak — с реализацией двухфакторной аутентификации (2FA). До нашего вмешательства аутентификация происходила напрямую в SAP-системе.

Сама настройка и реализация несложные, однако есть несколько моментов, с которыми мы столкнулись на практике, и при этом не нашли достаточно подробного описания в документации.

Далее кратко рассмотрим процесс настройки и разберем возникшие проблемы.

Скрытый текст

Понятийный аппарат:

SAP NetWeaver — SAP-платформа, на которой установлен AS Java.

Keycloak — приложение для управления аутентификацией и авторизацией. Оно ведёт регистрацию пользователей, управляет правами доступа и выдаёт токены.

Security Assertion Markup Language (SAML) — открытый стандарт аутентификации, предназначенный для организации единого входа (SSO). Позволяет пользователю пройти аутентификацию один раз и получать доступ к нескольким системам без повторного ввода учетных данных.

Переходим к настройке интеграции со стороны SAP

Иллюстративно процесс выглядит так:

Теперь пошагово:

1. На стороне SAP NetWeaver Portal активируем настройку SAML, по умолчанию она неактивна:

NWA → Configuration → Authentication and Single Sign-On → SAML 2.0

2. Указываем имя конфигурации:

3.Создаем signing key pair — пара ключей: закрытый и открытый (здесь начинается криптографическая магия):

4.Завершаем настройку, следуя шагам мастера (wizard):

5.Выгружаем метаданные и загружаем в Keycloak:

Теперь работаем непосредственно с Keycloak.

Создаем Realm в Keycloak и добавляем нового client через загрузку метаданных из SAP-системы:

Выгружаем метаданные из Keycloak и загружаем их в SAP-систему:

Завершаем настройку, следуя шагам мастера (wizard). Таким образом, мы активируем доверенный (trust) provider для аутентификации:

Теперь нужно активировать Identify Provider, иначе ничего не будет работать. Для этого добавляем Federation type — протокол, по которому SAP будет общаться с Keycloak для входа пользователей. В нашем случае — по email:

Добавляем Login module в Authentication:

Настройка окончена. Теперь окно авторизации выглядит так:

У нас есть два варианта авторизации:

• использовать Identity Provider (Keycloak), нажав Continue;

• нажать Cancel и выполнить авторизацию через SAP-систему, как и ранее.

С точки зрения безопасности на этом этапе необходимо исключить второй вариант, то есть авторизацию через SAP-систему.

Проблемы при реализации

1) Ограничение авторизации без Keycloak С точки зрения безопасности необходимо отключить возможность авторизации в обход Keycloak, поскольку система доступна извне. При этом возникает вопрос: как обеспечить доступ к системе в случае недоступности Keycloak?

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

Теперь авторизация осуществляется исключительно через Keycloak — кнопка Cancel отсутствует, обходной вход через SAP-систему невозможен.

Давайте теперь подумаем, как подключиться к системе и выполнить стандартную авторизацию через SAP, если Keycloak недоступен. В этом случае стоит вспомнить про старую добрую утилиту configtool.sh. Для этого потребуется перезапустить приложение:

2) Авторизация пользователей по email Вторая проблема связана с выбранным типом федерации — Federation type: Email. В этом случае идентификация пользователей осуществляется по уникальности их email-адресов.

На практике у некоторых пользователей есть две учётные записи: одна по табельному номеру, другая — фамильная, но с одинаковым email-адресом. В результате аутентификация через Keycloak для них не работает, и это можно обнаружить по трейсам в SAP-системе.

Для устранения конфликта нужно изменить тип федерации в SAP-системе с Email на Logon ID, чтобы идентификация пользователей происходила по уникальности имени пользователя (логина). На стороне Keycloak следует скорректировать настройки, чтобы они соответствовали новому типу федерации и исключали ошибки, связанные с дублированием email-адресов. Делаем это вот так:

Результат:

Теперь аутентификация происходит из SAP в Keycloak. Процесс выглядит следующим образом:

1. Пользователь открывает SAP NetWeaver Portal

2. Происходит редирект на Keycloak (новый пункт) 

3. Пользователь вводит логин / пароль (новый пункт)

4. Проходит второй фактор (OTP / TOTP / WebAuthn) (новый пункт)

5. Keycloak возвращает SAML assertion в SAP (новый пункт)

6. Пользователь получает доступ

Таким образом мы исключили возможность обхода аутентификации и повысили безопасность систем заказчика. Если вы столкнётесь с подобной настройкой, надеемся, наш текст поможет вам в этом. Но самое главное — внедряйте двухфакторную аутентификацию везде!