Введение
Single Sign-On или SSO — технология, которая позволяет пользователям получать доступ к различным приложениям, используя единый сервис аутентификации и одни учетные данные.
Такой подход повышает не только удобство пользователей, но и безопасность, так как управление учетными данными, политиками доступа, процессами аутентификации и мониторинг централизованы.
В статье мы рассмотрим основные подходы к реализации SSO на примере решений с открытым исходным кодом OpenAM и OpenIG.
Несколько сайтов на одном домене
Рассмотрим компанию с клиентскими или партнерскими сервисами на одном домене. Например, банком и маркетплейсом на домене example.org.
Архитектура SSO показана на схеме ниже:
На схеме OpenAM выступает в качестве сервиса аутентификации, OpenIG — в качестве шлюза авторизации.
Процесс аутентификации через SSO для пользователя будет выглядеть следующим образом:
Пользователь пытается получить доступ к банковскому приложению.
Шлюз OpenIG определяет, что пользователь не аутентифицирован, и перенаправляет его на сервер аутентификации OpenAM.
OpenAM аутентифицирует пользователя:
Пользователь вводит свои учетные данные в OpenAM. Это может быть логин и пароль, вход по SMS или биометрические данные (например, отпечаток пальца).
OpenAM создает сессию пользователя и устанавливает идентификатор этой сессии в cookie на домен верхнего уровня, в данном случае,
example.org.После успешной аутентификации OpenAM перенаправляет пользователя обратно в банковское приложение
OpenIG извлекает из cookie идентификатор сессии пользователя. По идентификатору получает данные сессии пользователя от OpenAM, проверяет, что она валидна и предоставляет доступ к банковскому приложению
Теперь пользователь пытается получить доступ к марткетплейсу.
OpenIG снова извлекает из cookie идентификатор сессии пользователя. Так как маркетплейс и банковское приложение находятся на одном домене верхнего уровня, то OpenIG имеет доступ к cookie этого домена.
Если сессия все еще валидна, OpenIG предоставляет доступ к маркетплейсу без запроса учетных данных
Использование корпоративного SSO на примере Kerberos
Рассмотрим предприятие, сотрудники которого работают в домене под управлением Windows Server. Для доступа к корпоративным сервисам будет использоваться встроенная аутентификация Windows по протоколу Kerberos.
Архитектура системы выглядит следующим образом:
Процесс аналогичен примеру выше. Отличается тем, что для аутентификации пользователей OpenAM обращается в Kerberos Key Distribution Center (KDC).
Процесс аутентификации с технической точки зрения:
Пользователь предварительно аутентифицирован в домене
Аутентифицированный в домене пользователь пытается открыть корпоративное приложение, расположенное за шлюзом OpenIG.
OpenIG видит, что пользователь не аутентифицирован, и перенаправляет его на OpenAM для аутентификации
OpenAM запрашивает у браузера токен Kerberos.
OpenAM аутентифицирует полученный токен в Kerberos Key Distribution Center (KDC) и получает информацию об учетной записи пользователя
После аутентификации OpenAM создает аутентифицированную сессию для пользователя, выставляет идентификатор сессии в cookie на домен
internalи перенаправляет пользователя на требуемое приложениеOpenIG получает сессию из cookie, авторизует сессию и пропускает запрос пользователя в приложение
С технической точки зрения процесс выглядит достаточно сложным, но для пользователя — максимально простым: он просто открывает в браузере нужное приложение и сразу получает доступ без каких-либо дополнительных действий.
Федеративный SSO
В примерах выше все сервисы были расположены на одном домене. Как же решить задачу, если сервисы находятся в разных доменах? Например, сеть супермаркетов стала партнером компании доставки продуктов и хочет использовать учетные записи своих клиентов для оформления доставки.
Для такого случая подходит федеративный SSO.
Федеративный SSO — технология, позволяющая сервисам на разных доменах, использовать доверенный сервис аутентификации.
Такой подход реализуется при помощи федеративных протоколов SAML, OAuth2 или OpenID Connect. Несмотря на различия в реализации, эти протоколы выполняют одну задачу - использование доверенного провайдера учетных записей (Identity Provider) для аутентификации.
Федерация состоит из двух сущностей - Identity Provider (IdP) и Service Provider (SP). IdP и SP знают друг о друге и доверяют друг другу.
Архитектура федеративного выглядит следующим образом:
OpenAM выступает качестве Identity Provider, приложение — качестве Service Provider.
OpenAM может выступать как в качестве Service Provider, так и в качестве Identity Provider. Но, как правило, используется в качестве Identity Provider.
Аутентификация при использовании федеративного SSO в общем случае выглядит так, независимо от используемого протокола:
Пользователь пытается аутентифицироваться в SP.
SP перенаправляет пользователя для аутентификации в IdP
IdP аутентифицирует пользователя
При успешной аутентификации IdP перенаправляет пользователя обратно на SP
При перенаправлении на SP, IdP передает данные об аутентифицированной сессии или случайный идентификатор для получения данных сессии.
На основе полученных данных Service Provider создает сессию аутентификации и, при необходимости, создает локальную учетную запись.
После успешной аутентификации пользователь начинает работать с Service Provider.
Заключение
Мы рассмотрели в статье только самые основные способы организации Single Sign-On. На практике возможна их комбинация, например, использование Kerberos аутентификации в OpenAM для федеративного доступа во внешнее приложение по протоколу SAML.
Технология Single Sign-On предоставляет удобный и безопасный способ управления доступом к различным сервисам, будь то сайты на одном домене, корпоративные приложения или сервисы на разных доменах. Использование решених, таких как OpenAM и OpenIG, позволяет гибко настраивать процессы аутентификации и авторизации, адаптируя их под конкретные задачи бизнеса. Внедрение SSO не только упрощает взаимодействие пользователей с системами, но и повышает уровень безопасности за счет централизованного управления.