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