|
Professor Seleznov
|
Хабр, привет!
В последнее время обсуждать миграцию с продуктов 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
Иллюстративно процесс выглядит так:
Теперь пошагово:
- На стороне 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. Процесс выглядит следующим образом:
- Пользователь открывает SAP NetWeaver Portal
- Происходит редирект на Keycloak (новый пункт)
- Пользователь вводит логин / пароль (новый пункт)
- Проходит второй фактор (OTP / TOTP / WebAuthn) (новый пункт)
- Keycloak возвращает SAML assertion в SAP (новый пункт)
- Пользователь получает доступ
Таким образом мы исключили возможность обхода аутентификации и повысили безопасность систем заказчика. Если вы столкнётесь с подобной настройкой, надеемся, наш текст поможет вам в этом. Но самое главное — внедряйте двухфакторную аутентификацию везде!-Источник
|
|
|
