Single Sign-On c OpenAM и OpenIG: Практические примеры реализации

Введение

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 не только упрощает взаимодействие пользователей с системами, но и повышает уровень безопасности за счет централизованного управления.