OpendID Connect и IDP инициировали SSO

Question

У меня есть приложение, которое является поставщиком услуг. Можно ли реализовать SSO, инициированную Idp, с OpenID Connect?
Похоже, что для SSO, инициируемого Idp, может использоваться только SAML, верно? Или есть способ заставить OpenID Connect работать? Я думаю об использовании некоторых инструментов с открытым исходным кодом, таких как Keycloak или OneLogin и т. Д.

Большое спасибо.

Answer 1

Безопасный IDP-SSO невозможен с OpenID Connect в его текущей форме. Тем не менее, существует функция, называемая SSO, инициируемой сторонним разработчиком, которая позволяет запускать процесс аутентификации через стороннего производителя, но все же сначала посещает RP.

Что касается описанных предложений IDP-init: хорошо ведущий себя RP должен предотвращать это - поскольку технически он включает CSRF - с помощью параметра state или (как менее предпочтительное и менее безопасное решение) путем сохранение состояния запроса в файле cookie, что делает RP уязвимым для CSRF только во время запроса / ответа.

Существует незавершенная работа, в которой описывается, среди прочего, как можно добиться истинного IDP-init-SSO с помощью расширения OpenID Connect безопасным способом с помощью подписанного сообщения: https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state#section-4.3

Answer 2

Поскольку OpenIDConnect основан на OAuth2, SSO, инициируемая IdP, технически должна быть возможна, но при одном условии - SP не полагается на состояние, переданное IdP в первоначальном запросе, когда состояние действует как anti маркер фальсификации (т.е. по запросу на возврат состояние возврата сравнивается с состоянием, отправленным SP в первоначальном запросе).

Более длинный ответ будет:

Первый шаг кода авторизации Поток OAuth2 - это SP, перенаправляющий на IdP, и IdP перенаправляет обратно с одним временным кодом. Параметр state часто передается SP, и SP ожидает, что состояние будет возвращено обратно.

Есть два случая.

SP проверяет состояние (например, сравнивает его с состоянием, хранящимся во временном cookie). Единый вход в систему IdP не будет работать, поскольку IdP никак не может знать / подделывать состояние, и поэтому он не может выдать действительный запрос поставщику услуг, который будет действовать как инициированный IdP единый вход.

ИП не проверяет состояние. Затем IdP может выдать ответ на обычный запрос OAuth2, но без фактического запроса, то есть он перенаправляет на

 https://sp.com/oauth2?code=...authcode

и SP выбирает рукопожатие OAuth2 оттуда, как если бы SP первым инициировал рукопожатие.

Другими словами, возможен ли SSO, инициированный IdP, это зависит только от SP. Поскольку spec рекомендует с использованием state для предотвращения такого поведения (классифицируется там как CSRF), я считаю, что вы здесь сами по себе. Также читайте подробнее о возможных проблемах безопасности, связанных с параметром state.

3.1.2.1. Состояние запроса аутентификации […] - РЕКОМЕНДУЕТСЯ. Непрозрачное значение, используемое для поддержания состояния между запросом и обратным вызовом. Обычно смягчение межсайтовых запросов (CSRF, XSRF) выполняется путем криптографического связывания значения этого параметра с файлом cookie браузера.