У нас есть Веб-приложение , использующее REST API .REST API основан на Loopback и использует встроенную аутентификацию на основе токенов.Для веб-приложения мы используем аутентификацию на основе форм через HTTPS, поэтому пользователь должен ввести свое имя пользователя и пароль, которые мы затем используем для получения токена доступа из API REST через POST /users/login конечную точку.
Один из наших клиентовпопросили нас поддержать единый вход (SSO) аутентификацию через SAML 2.0 и AD FS .
Мы настроили наше веб-приложение какПоставщик услуг (проверяющая сторона в AD FS) и сумел поддержать SSO для него.Переменная часть - это аутентификация между Web App и REST API.Идея заключается в том, чтобы настроить как веб-приложение, так и REST API в качестве одной и той же проверяющей стороны и добавить новую конечную точку POST /users/saml-login в REST API, чтобы веб-приложение могло отправлять ответ SAML этой конечной точке и получать на основе токена доступапо претензиям, указанным в ответе SAML.Все остальное должно работать так, как раньше.Вот поток, который я представляю:
- Веб-приложение генерирует запрос SAML и перенаправляет пользователя на страницу входа в IdP
- После успешного входа пользователь перенаправляется обратно в веб-приложение сОтвет SAML
- Web App действует как прокси и перенаправляет ответ SAML на конечную точку API REST (
POST /users/saml-login), где он проверяется - Если ответ SAML действителен, API возвращаеттокен доступа на основе утверждений
- Веб-приложение использует токен доступа для дальнейшего взаимодействия с REST API, как и раньше
Вот вопрос: Это нормально?реализовать SSO на основе SAML таким образом?Видите ли вы какие-либо проблемы или соображения безопасности с этим подходом?Есть ли какие-нибудь альтернативы?
Я прочитал много статей в Интернете и вопросы здесь, на StackOverflow о том, как использовать SAML & REST API вместе:
Ни один из них действительно не помог мне подтвердить или отклонить идею, описанную выше.