Инициация SSO IdP vs Инициация SSO SP#

Терминология#

• Identity Provider (IdP): Служба, которая хранит и аутентифицирует идентичности пользователей.
• Service Provider (SP): Веб-сервис или услуга, которая предоставляет услуги пользователям.
• Single Sign-On (SSO): Служба сеансов и аутентификации пользователей, которая позволяет пользователю использовать один набор учетных данных для входа (например, имя и пароль) для доступа к нескольким приложениям.
• SAML: Security Assertion Markup Language — это открытый стандарт для обмена данными аутентификации и авторизации между сторонами, в частности, между провайдером идентичности и провайдером услуг. Это часто используемый протокол для SSO. После успешной аутентификации пользователя IdP отправляет утверждение SAML на SP, которое SP подтверждает и предоставляет пользователю доступ.
• OIDC: OpenID Connect — это более современный и безопасный протокол для SSO. Он построен на основе OAuth 2.0 и предоставляет способ проверки идентичности пользователя на основе аутентификации, выполненной IdP. После успешной аутентификации пользователя IdP отправляет токен, отформатированный в JWT, на SP, который SP подтверждает и предоставляет доступ пользователю.

SP-инициированное SSO#

Как следует из названия, SP-инициированное SSO инициируется провайдером услуг. Пользователь начинает процесс аутентификации, получая доступ к ресурсу на веб-сайте SP. SP затем перенаправляет пользователя к IdP для аутентификации. Как только пользователь аутентифицирован, IdP генерирует токен (OIDC) или утверждение SAML (SAML) и отправляет его обратно на SP. SP подтверждает токен или утверждение и предоставляет доступ пользователю.

1. Пользователь посещает веб-сайт SP и пытается получить доступ к ресурсу.
2. Пользователь нажимает на кнопку входа провайдера SSO (например, Google, Azure AD, Okta и т.д.).
3. SP перенаправляет пользователя к IdP для аутентификации.
4. Пользователь входит в IdP.
5. IdP отправляет токен или утверждение обратно на SP.
6. SP подтверждает токен или утверждение и предоставляет доступ пользователю.

IdP-инициированное SSO#

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

1. Пользователь входит в IdP.
2. Пользователь посещает портал IdP и выбирает приложение SP.
3. IdP подтверждает текущую сессию пользователя и перенаправляет его на SP с заранее аутентифицированной идентичностью SSO.
4. SP подтверждает идентичность SSO и предоставляет доступ пользователю.

IdP-инициированное SSO vs SP-инициированное SSO#

Преимущества IdP-инициированного SSO по сравнению с SP-инициированным SSO#

IdP-инициированное SSO более популярно среди крупных предприятий и организаций, которые полагаются на различные сторонние приложения или сервисы, такие как Workday, Salesforce и т.д. Оно предоставляет централизованный способ управления доступом пользователей к множеству приложений и обеспечения аутентификации SSO. Позволяя IdP-инициированное SSO, сотрудники могут напрямую получить доступ к подключённым приложениям с портала IdP без необходимости посещать веб-сайт каждого приложения, сокращая время на онбординг и улучшая пользовательский опыт.

Риски IdP-инициированного SSO по сравнению с SP-инициированным SSO#

IdP-инициированное SSO несёт в себе больше рисков по сравнению с SP-инициированным SSO.

1. Отсутствие контекста аутентификации: Все запросы аутентификации, инициированные IdP, являются незапрашиваемыми. Таким образом, SP инициирует процесс аутентификации, потенциально открывая дверь для несанкционированного доступа. Есть риск, что пользовательская сессия может быть похищена. Злоумышленник может инициировать процесс входа для легитимного пользователя без его ведома или согласия.

2. Фиксация сессии: Поскольку SP не инициирует процесс аутентификации, пользовательская сессия может быть прикреплена к сессии IdP. Это может привести к атакам фиксации сессии, когда атакующий может привязать пользовательскую сессию к сессии IdP и получить несанкционированный доступ к учётной записи пользователя.

3. Фишинговые атаки: IdP-инициированное SSO может быть уязвимым для фишинговых атак. Злоумышленник может обмануть пользователя и заставить его посетить поддельный портал IdP и украсть учётные данные пользователя. Как только пользователь входит в систему, атакующий может перенаправить его на SP с предварительно аутентифицированной идентичностью.

4. Отсутствие уверенности в валидации запроса: В случае SP-инициированного SSO SP обычно включает необходимую информацию безопасности в запрос к IdP для поддержания целостности запроса. Как только SP получает ответ аутентификации, он проверяет эту информацию, чтобы предотвратить любые атаки CSRF. Например, параметр state в OIDC и RelayState в SAML. Однако в случае IdP-инициированного SSO SP не инициирует процесс аутентификации, и поэтому у него нет уверенности в проверке запроса.

Ограничения IdP-инициированного SSO по сравнению с SP-инициированным SSO#

IdP-инициированное SSO не поддерживается OIDC из-за вышеуказанных уязвимостей. OIDC требует, чтобы SP инициировал процесс аутентификации для обеспечения целостности запроса. Даже в случаях, когда пользователи начинают процесс аутентификации с третьих сторон, которые не являются SP, пользователь должен быть сначала направлен к SP для инициации процесса аутентификации.

Но в SAML IdP-инициированное SSO возможно. IdP может сгенерировать утверждение SAML без инициации SP процесса аутентификации. В SAML IdP-инициированном SSO утверждение SAML без правильного RequestID и RelayState может быть отправлено напрямую на URL ACS SP. SP должен быть в состоянии обработать подобное утверждение и предоставить доступ пользователю. (Примечание: Без RequestID и RelayState SP не имеет уверенности в целостности запроса).

Заключение#

Хотя IdP-инициированное SSO предоставляет централизованный способ управления доступом пользователей к нескольким приложениям, оно несёт в себе больше рисков по сравнению с SP-инициированным SSO. SP-инициированное SSO более безопасно и предоставляет больше уверенности в целостности запроса аутентификации. Рекомендуется использовать SP-инициированное SSO для обоих способов SSO на основе OIDC и SAML.