SAML-аутентификация с использованием angular, node.js и поставщика удостоверений
Я хочу реализовать систему единого входа с использованием SAML2. Но я не знаю, как заставить его работать с распределенной системой, где каждый экземпляр работает независимо на своем собственном сервере. Среда состоит из трех экземпляров:
- Пример №1: угловой интерфейс
- Экземпляр №2: серверная часть node.js (с использованием express.js + паспорт)
- Экземпляр № 3: экземпляр SAML (поставщик удостоверений)
Вопрос в том, что было бы лучшим подходом, если внешний интерфейс вызывает защищенный внутренний маршрут? Какую последовательность действий можно считать хорошей практикой?
На данный момент у меня в голове такое поведение:
- Внешний интерфейс отправляет запрос на защищенный внутренний маршрут
- Поскольку пользователь не прошел проверку подлинности, сервер инициирует перенаправление на SSO-страницу, предоставленную поставщиком удостоверений.
- Там учетные данные вводятся
- Пользователь аутентифицируется экземпляром saml и отправляет запрос обратно на сервер.
- Теперь пользователь аутентифицирован, сервер отправляет клиенту ответ с запрошенным ресурсом.
Но пока я думаю об этой последовательности, я понимаю, что это не сработает. Это потому, что внешний интерфейс является собственным экземпляром и не зависит от внутреннего. Перенаправление на SSO-страницу, инициированное паспортом, не работает, если у вас есть отдельный экземпляр внешнего интерфейса. Это работает, если вы вызываете защищенный маршрут напрямую из браузера, потому что тогда у вас есть только два партнера по связи (поставщик услуг и поставщик удостоверений) вместо трех. Но это не тот случай.
Спасибо и привет
Филипп
Ответы 1
Я сделал что-то подобное в предыдущей работе с этой логикой:
- Реализуйте страницу входа в Angular (простая форма для получения учетных данных), затем вызовите службу входа в систему в бэкэнде.
- Эта внутренняя служба входа в систему должна проверять учетные данные, предоставленные внешним интерфейсом, против поставщика удостоверений (я уверен, что они предоставят вам URL-адрес, по которому вы можете ввести эти параметры).
- После проверки личности вызовите службу аутентификации в бэкенде, чтобы сгенерировать токен для этого пользователя (работу должен выполнить Passport JS), а затем отправьте этот токен обратно во внешний интерфейс.
- Во внешнем интерфейсе внедрите защиту, которая должна обрабатывать токены/устанавливать учетные данные пользователя в локальное хранилище...
- Во внешнем интерфейсе также реализуйте перехватчик, который внедряет этот токен в каждый заголовок XHR или перенаправляет пользователя на форму входа в случае, если токен отсутствует или просрочен.
- В бэкэнде логика будет классической (проверьте действительность токена из заголовка XHR перед отправкой обратно данных/укажите интерфейсу войти в систему, если проверка не удалась).
С помощью этой логики вы будете отделять внешний интерфейс от поставщика удостоверений и согласовывать его с внутренним.
@mayerph Ваше решение сработало? Или вы выбрали другой путь.
Пункт 1 и 2 однозначно нет. Пользователь должен быть перенаправлен на страницу входа в систему поставщика удостоверений для ввода учетных данных.
Основная концепция SSO-аутентификации заключается в том, что учетные данные не передаются из внешнего интерфейса по соображениям безопасности.
Большое спасибо. Это звучит здорово. Я дам ему попробовать. Я подумал о другом возможном решении: если пользователь не аутентифицирован, серверная часть отправляет ошибку во внешний интерфейс. Инициируется перенаправление на страницу SSO-Login (window.location.href). Для этого требуется, чтобы интерфейс знал IDP. После того, как пользователь ввел учетные данные и прошел проверку подлинности IDP, он отправляет запрос на маршрут обратного вызова... Я опубликую это решение, если оно сработает.