Что такое технология SSO

SSO, или Single Sign On, — метод сквозной аутентификации, который позволяет входить в разные корпоративные сервисы по одному логину и паролю. Сотруднику не приходится запоминать много комбинаций учетных данных — достаточно одной, чтобы зайти сразу во все приложения, которые он использует для работы.

В процессе аутентификации три участника. Первый — Service Provider, или SP. Это сервис, в который пользователь хочет войти. Второй участник — Identity Provider, или IdP. Это система аутентификации, например Active Directory. И третий участник — сотрудник с учетными данными.

Принцип работы SSO выглядит так:

1. Сотрудник заходит на сайт или в приложение, к которому хочет получить доступ, и SP перенаправляет пользователя в систему аутентификации.
2. IdP проверяет, есть ли активная сессия. Если пользователь ранее заходил в систему аутентификации, заполнял учетные данные и сессия еще активна, вводить логин и пароль заново не нужно. В ином случае на экране появится форма для их набора.
3. После успешной аутентификации IdP генерирует токен. Это цифровой ключ, который содержит сведения о сотруднике, например его адрес электронной почты или userID. Затем IdP подписывает токен своим сертификатом для подтверждения подлинности.
4. Токен передается в SP, который после успешной проверки ключа дает пользователю доступ к приложению или сайту.

Когда пользователь переходит на другой сайт или в приложение, процесс проверки повторяется: сервис анализирует данные посетителя по алгоритму и проверяет цифровую подпись токена. Это происходит автоматически: если есть активная сессия, повторно вводить логин и пароль пользователю не приходится.

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

SAML. Это протокол для обмена данными между системой аутентификации и сервисом. SAML помогает сервису понять, какой пользователь перед ним, то есть подтверждает личность человека. Можно представить, что аутентификация через SAML — это как предъявление паспорта: нужно, чтобы идентифицировать и пустить пользователя внутрь системы.

OAuth 2.0. Еще один протокол, с помощью которого система аутентификации и сервис обмениваются информацией. OAuth 2.0 позволяет сервису совершать действия от имени пользователя — но не все, а только разрешенные. Например, протокол дает корпоративному мессенджеру доступ к адресу электронной почты сотрудника, но не ко всем его данным сразу. OAuth 2.0 можно сравнить с билетом на концерт: он не подтверждает личность человека, но дает право войти в зал.

OpenID Connect, или OIDC. Протокол дополняет OAuth 2.0 и проверяет личность пользователя с помощью токена идентификации, в котором есть уникальный номер сотрудника, его имя, время аутентификации и срок действия токена.

Для интеграции приложений в локальную инфраструктуру обычно используют протокол SAML. Но из-за тяжелых XML-запросов он неудобен для веб- и мобильных приложений, поэтому для них часто выбирают протокол OAuth 2.0 в связке с OpenID Connect. Это более гибкое решение: система может запросить только адрес электронной почты пользователя, а не весь профиль, как в SAML.

Упрощает вход для сотрудника. Когда связок логина и пароля несколько, их сложнее запомнить, поэтому люди записывают учетные данные в блокноты или на стикеры, а потом теряют. С SSO нужно держать в уме всего одну связку.

Экономит время. Сотрудник вводит логин и пароль только один раз — в начале рабочего дня, а система автоматически дает доступ ко всем корпоративным сервисам.

Помогает ИТ-отделам управлять профилями работников. Администратор может сделать так, чтобы работать с информацией могли только сотрудники, которым она необходима. Если у человека изменится должность, его уровень доступа можно будет обновить сразу для всех сайтов и приложений.

Позволяет организовать единую поддержку. Если сотрудник столкнется с проблемами доступа к нескольким сервисам, он сможет обратиться в единое окно техподдержки и не искать системных администраторов, которые отвечают за отдельные приложения или сайты.

Заменяет менеджер паролей. Это программа, которая хранит логины и пароли сотрудника от разных сайтов и приложений. В отличие от SSO, где пользователи получают доступ к сервисам через систему аутентификации, менеджер паролей только запоминает учетные данные пользователя и подставляет их при повторном входе.

Если сотрудник уволится, в SSO можно будет разом закрыть ему доступ ко всем сервисам компании. В менеджере паролей такой возможности нет — придется вручную удалять учетные данные с каждого сайта и приложения.

Ускоряет внедрение новых сервисов. Когда компания подключает новый инструмент, например программу для автоматизации закупок, системный администратор не тратит время на создание еще одного набора учетных записей, а только интегрирует сервис с действующей системой единого входа.

Защищает от фишинга и утечки данных. Если сотрудник вводит десятки разных паролей и логинов за день, то может по невнимательности оставить свои данные на фишинговой странице, и злоумышленники получат доступ к его профилю. Благодаря SSO процесс входа в корпоративные сервисы не превращается в рутину, поэтому пользователь внимательнее относится к форме, которую заполняет.

Технология единого входа подключается локально или в облаке. Локальное решение устанавливается на серверах компании и требует ресурсов для поддержки и обновления. Этот вариант подходит крупным организациям, которые хотят полностью контролировать ИТ-инфраструктуру.

SSO в облаке не требует установки или обновления специалистами компании. Администратору достаточно настроить доступы к сервисам, в которых должна работать технология единого входа. Такое решение можно запустить за несколько дней, поэтому оно подходит среднему и малому бизнесу.

SSO запускают сотрудники ИТ-отдела, системные администраторы или специалисты по информационной безопасности. Дальше — шаги, которые помогут подключить технологию:

1. Проанализируйте важные для компании сервисы. Составьте список сайтов и приложений, которыми пользуются сотрудники на работе, и проверьте, все ли сервисы поддерживают SSO.
2. Определите цели внедрения SSO. Они зависят от бизнес-задач: например, обеспечить централизованный контроль доступа, упростить вход в десятки корпоративных сервисов, повысить безопасность за счет поддержки многофакторной аутентификации или выполнить требования регуляторов. Для банка это может быть стабильная работа с большим количеством пользователей и возможность отслеживать все входы в системы отчетности.
3. Настройте и протестируйте SSO. Проверьте, как работает система на всех сервисах, которые к ней подключены. После развертывания исправлять недочеты будет сложнее: любое изменение будет затрагивать всех пользователей, а не только контрольную группу.
4. Проведите инструктаж. Расскажите сотрудникам, как теперь получать доступ к сервисам. Посоветуйте внимательнее следить за тем, на каких страницах они вводят логин и пароль.

Если для компании важна безопасность данных, можно внедрить дополнительные системы защиты. Например, двухфакторную аутентификацию: с ней сотруднику нужно будет подтвердить личность с помощью одноразового кода или биометрии.

Мессенджер поддерживает технологию SSO и работает с протоколами SAML и OpenID Connect для разных провайдеров аутентификации, например Keycloak и ADFS. Чтобы быстро подключить и настроить SSO, в Time есть пошаговая инструкция.