#reactjs #single-sign-on #saml
#reactjs #единый вход #saml
Вопрос:
У меня есть веб-приложение, разработанное с использованием Create-react-app
Я размещаю его в IIS, только IIS отвечает на загрузку приложения, на нем нет логики на стороне сервера (нет Express или любого другого веб-сервера)
Приложение использует RESTful API в том же IIS, это вне моего контроля (я не могу внести изменения).
Теперь один из моих клиентских запросов на добавление единого входа SAML в наше приложение.
Я хотел бы знать:
- в обычной ситуации, какой из них является поставщиком услуг? Мой веб-сервер IIS? или служба API?
- В моем случае я не могу реализовать SAML для службы API, мой веб-сервис использовался только для загрузки моего приложения без серверной логики, как я могу реализовать SAML?
- Может ли кто-нибудь дать мне какое-нибудь руководство или статью по реализации единого входа SAML для справки?
Спасибо за любую помощь, любую информацию или предложения приветствуются!
Комментарии:
1. SAML не часто используется / предназначен для SPA (одностраничных приложений). как вы аутентифицируете и авторизуете вызов API в настоящее время?
2. У меня есть страница входа для ввода id / pw, отправки их в конечную точку входа на сервер API для аутентификации и возврата токена JWT. После этого мы используем этот токен в вызовах API для аутентификации.
3. Я бы посоветовал вам перейти на OAuth или, что лучше, OIDC.
Ответ №1:
в обычной ситуации, какой из них является поставщиком услуг? Мой веб-сервер IIS? или служба API?
Я предполагаю, что клиент хочет аутентифицировать пользователей, используя их внутренний IdP. Итак, ваше приложение является SP. Но вам нужно будет определить другую службу токенов (подробности ниже).
С SPA (одностраничным приложением) Я вижу проблему, в SAML пользователь перенаправляется или отправляется в сторону от запроса SAML и ответа SAML.
У меня есть страница входа в систему для ввода id / pw, отправки их в конечную точку входа на сервер API для аутентификации и возврата токена JWT. После этого мы используем этот токен в вызовах API для аутентификации
Службы API используют токен JWT, выданный на основе предоставленного имени пользователя / пароля. Я бы рекомендовал расширить службу токенов (или использовать другую службу) для выдачи токена JWT на основе предоставленного ответа SAML — службы обмена токенами. Во многих реализациях OAuth это называется типом предоставления SAML.
Я не могу реализовать SAML для службы API, мой веб-сервис используется только для загрузки моего приложения без серверной логики, как я могу реализовать SAML?
Обычно после аутентификации пользователь перенаправляется или отправляется на URL конечной точки SAML ACS, где сервер может создать своего рода сеанс (cookie, параметры, токен, ..), И пользователь перенаправляется на URL, возвращающий веб-страницу с информацией о сеансе.
Если вы используете SPA, вы можете использовать всплывающее окно или SAML с перенаправлением (не с post), где страница может считывать параметры ответа SAML (утверждение, подпись, ..) и использовать их в службе обмена токенами, упомянутой выше.
При обработке ответа SAML попробуйте использовать некоторые зрелые, известные, готовые библиотеки, это служба безопасности, и ее неправильное выполнение может привести к недостаткам безопасности. Но вам нужно сделать это на стороне сервера, так как в конце вам понадобится токен JWT, используемый API.
Комментарии:
1. С точки зрения безопасности, разрешение SPA, запущенному на клиенте, проверять утверждение SAML является опасным выбором. (Редактировать: теперь, когда я прочитал ваш последний абзац, возможно, вы намекаете на это… Но вы должны четко указать, что утверждение должно быть проверено на стороне сервера.)
2. @AndrewK. да, есть некоторые ограничения и последствия, не указанные явно. Ответ SAML недолговечен и велик, на самом деле он не предназначен для использования в качестве токена доступа (я тоже это уже видел). Кроме того, даже технически возможно проверить токен SAML на стороне веб-клиента (я бы посоветовал против этого), действительно, нет способа безопасно создать токен доступа только на стороне клиента.
3. Спасибо за всю информацию. Я думаю, сработает ли это: 1. Я настрою новый веб-сервер с использованием ExpressJS 2. Экспресс-сервер обрабатывает SSO SAML 3. Я изменю логин, вызову новый экспресс-сервер для входа в систему, он сделает единый вход для меня 4. в случае успешного входа в систему экспресс-сервер вызывает исходный сервер API, чтобы получить токен 5. Приложение SPA продолжит использовать токен как обычно, только если срок действия токена истечет, вызовите SSO снова, будет ли это работать? или какое-нибудь лучшее предложение? спасибо за любую помощь.
4. @EricCheng
The Express server handle SAML SSO
хорошо. Пожалуйста, используйте какую-нибудь зрелую библиотеку (passport-saml, ..).if token expire, call SSO
если у вас нет токена обновления, вам необходимо выполнить повторную проверку подлинности.call original API server to get the token
получить токен на основе чего? Обычно серверу аутентификации необходимо напрямую возвращать токен доступа (в утверждении saml нет пароля), это может сработать, но вам придется решать детали. Удачи с этим 🙂