SSO (Single Sign-On)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 16:43, 22 мая 2017.

Технология единого входа (англ. Single Sign-On) - это механизм, позволяющий пользователю пройти аутентификацию (вход со своими учетными данными) единовременно и получить доступ к различным программным продуктам, используя один идентификатор.

Таким образом ключевым моментом здесь является то, что пользователю требуется войти в систему для подключения к приложению только один раз, причем в контексте этой же сессии нет необходимости проходить аутентификацию повторно при доступе к другому приложению или серверу.[Источник 1]

Общая схема систем единого входа

Единый вход пользователя в несколько серверов

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

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

  • Напрямую: информация, предоставленная пользователем, передается на вторичный домен в качестве составной части данных при входе во вторичную систему.
  • Косвенно: информация, предоставленная пользователем, используется для извлечения других идентификационных и аутентификационных данных пользователя, хранящихся в базе управляющей информации технологии единого входа. Извлечённая информация затем используется как основа для операции входа во вторичный домен.
  • Немедленно: для установления сеанса со вторичным доменом как составной части установления первоначального сеанса. Это означает, что во время выполнения операции первичного входа автоматически вызываются клиенты приложений и устанавливаются необходимые соединения.
  • В отложенном режиме: информация временно сохраняется или кэшируется, используется по мере необходимости во время выполнения конечным пользователем запроса к сервисам вторичного домена.[Источник 2]

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

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

  • Вторичные домены должны доверять первичному в том, что он:
  1. корректно заявляет идентификационную сущность и атрибуты безопасности конечного пользователя;
  2. защищает аутентификационные данные, используемые для проверки идентификационной сущности конечного пользователя во вторичном домене, от несанкционированного использования.
  • При передаче между первичным доменом и вторичными доменами аутентификационные данные должны защищаться от перехвата или прослушивания, поскольку это может привести к атакам, при которых злоумышленник будет выдавать себя за реального пользователя.[Источник 3]

Основные достоинства и недостатки SSO

Достоинства Потенциальные недостатки
Снижение времени, требуемого для повторного ввода паролей; Попытка первоначальной реализации может быть сложной, в зависимости от количества существующих не сопоставимых систем
Снижение количества паролей, необходимых для различных программных продуктов; Скомпромитированные входные данные (credentials) пользователя могут привести к доступу к большому числу приложений
Снижение нагрузки на сеть, связанной с многократными процедурами аутентификации; Производитель либо не использует существующий открытый стандарт, либо использует стандарты, несовместимые со стандартами, используемыми другими приложениями.
Снижении стоимости IT-системы за счет снижения количества инцидентов ИБ, связанных с учетными данными пользователей; Данный механизм требует установки специальных агентов, поддерживаются не все устройства и операционные системы.

Методы SSO

Технология единого входа включает в себя следующие методы:

  1. Single Sign-On — метод, позволяющий пользователю получить доступ ко многим ресурсам, выполнив авторизацию в одном из них.
  2. Single Sign-Off (Signle Log Out) — обратный метод, прекращающий доступ пользователя к ресурсам после выполнения выхода из одного из ресурсов.
  3. Just-In-Time Provisioning — создание учетной записи, если она отсутствует в целевом приложении.

Основные преимущества SSO

Преимущества для конечных пользователей Преимущества для администратора безопасности
Необходимо хранить в памяти только один механизм аутентификации. Для аутентификации на основе пароля это означает, что пользователям надо помнить только один пароль Запись регистрационных данных пользователя в одном месте для управления и обеспечения безопасности.
При употреблении паролей пользователи должны изменять только один пароль и следовать только одному набору правил паролирования. Возможность ведения общих для организации политик паролирования и обеспечения безопасности, позволяющих обеспечить "сквозную" безопасность, возможно в рамках приложений и систем. Это позволит избежать проблем с несоответствием требований по сложности паролей и периодам их смены в различных системах.
Единственный вход для каждого пользователя в домене SSO, обычно только один раз в день. Проще контролировать информацию о правах доступа пользователя (user security information) и при необходимости корректировать ее, чем при отслеживании всех отдельных систем, к которым имеет доступ пользователь. Это особенно важно, когда пользователям назначают роли с другими уровнями доступа.

Протоколы, обеспечивающие технологию единого входа

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

  • Протоколы семейства WS-Security (WS-Trust [LK07], WS-Federation[KM09]);
  • Протокол SAML
  • Протокол OpenID
  • Протокол OAuth
  • Протокол Kerberos [KN93]

Протоколы семейства WS-

Данный протокол основывается на стандартах WS-Security и WS-Trust и описан в спецификации WS-Federation Passive Requestor Profile, в которой представлены механизмы для запроса, обмена и выдачи маркера безопасности в ситуации с пассивным клиентом. Определение «пассивный клиент» подразумевает наличие на компьютере пользователя только веб-браузера, так как взаимодействие между пользователем, Центр Идентификации и Целевое Приложение (веб-сервер, предоставляющий ресурсы) происходит в пределах функциональности базы HTTP (методы GET, POST, перенаправления и cookies). Схема протокола имеет следующий вид:

  1. Браузер клиента запрашивает ресурсы, обычно используя метод GET.
  2. Запрос клиента перенаправляется к Центру Идентификации сервера. Перенаправленный URL может содержать дополнительную информацию, отражающую соглашения, установленные между Целевым Приложением и Центром Идентификации сервера, однако этот URL должен быть использован в дальнейшем в качестве URL для Центра Идентификации сервера. Рекомендуется, чтобы Центр Идентификации обеспечивал конфиденциальность информации (например, используя шифрование или HTTP/S).
  3. После перенаправления, Центр Идентификации должен определить область доверия пользователя. Она может быть сохранена в cookies во время прошлого обмена, может быть известна или фиксированная Целевым Приложением или же пользователю может быть предложено её выбрать. В случае выбора области доверия пользователем Центр Идентификации может потребовать у клиента информацию о ней
  4. Перенаправление Центром Идентификации сервера на пользовательский Центр Идентификации для проведения аутентификации пользователя. Обычно это происходит с использованием перенаправления HTTP 302. Пользовательский Центр Идентификации должен обеспечивать конфиденциальность информации, используя HTTP/S или другие механизмы защиты на транспортном уровне.
  5. Клиентский Центр Идентификации проводит процедуру аутентификации пользователя. Проверка пользователя может включать предоставление им некоторой информации о себе.
  6. После успешной проверки клиентских данных формируется ответ, содержащий маркер безопасности (RSTR), который отправляется путем переправления Центра Идентификации серверу для продолжения обработки. Хотя Центр Идентификации может вернуть указатель на информацию, содержащуюся в маркер безопасности с помощью описателя URL, рекомендуется, (если это возможно) возвращать RSTR, используя метод POST, чтобы уменьшить общее число сообщений.
  7. Центр Идентификации сервера получает и проверяет RSTR.
  8. Центр Идентификации сервера выполняет федеративную проверку аутентификации/авторизации (проверка на уровне политики). После успешной проверки, Центр Идентификации сервера может выпустить маркер безопасности для Целевого Приложения, затем происходит перенаправление Целевому Приложению.
  9. Целевое Приложение получает RSTR от Центра Идентификации сервера. В случае успешной проверки Целевое Приложение обрабатывает запрос (с учетом политики). Маркер безопасности должен быть передан по методу POST, при этом синтаксис должен соответствовать описанному в спецификации.
  10. Возвращая результат запроса, Целевое Приложение может установить cookies с указанием состояния клиента при входе.

С учетом требований, описанных в спецификации WS-Federation Passive Requestor Profile, протоколом поддерживаются следующие форматы маркеров безопасности:

  • Сертификат X.509;
  • Билет Kerberos;
  • XrML–токен;
  • SAML-токен.

Протокол SAML

SAML (англ. security assertion markup language — язык разметки декларации безопасности) — язык разметки, основанный на языке XML. Открытый стандарт обмена данными аутентификации и авторизации между участниками, в частности, между поставщиком учётных записей (англ. identity provider) и поставщиком сервиса (англ. service provider). SAML — продукт OASIS, разработанный Техническим комитетом безопасности сервиcов. SAML создан в 2001 году; последнее значимое обновление SAML было опубликовано в 2005 году, но расширения протокола постоянно выпускались через дополнительные, опциональные стандарты.

Одной из важных проблем, которую пытается решить SAML, является обеспечение сквозной аутентификации при работе через Web-браузер. Использование SAML в качестве технологии единого входа на уровне сети (intranet) распространено (например, с использованием cookies), но расширение за пределы частной сети (intranet) было проблематично и привело к созданию несовместимых запатентованных технологий (другой, более современный подход обеспечения SSO — это протокол OpenID)

Протокол OpenID

OpenID — открытый стандарт децентрализованной системы аутентификации, предоставляющей пользователю возможность создать единую учётную запись для аутентификации на множестве не связанных друг с другом интернет-ресурсов, используя услуги третьих лиц.

Аутентификация посредством OpenID [FH07] обеспечивает возможность подтвердить, что пользователь обладает идентификатором без запроса доверенной стороной у пользователя его идентификационных данных, таких как пароль или адрес электронной почты. OpenID – децентрализованный протокол, пользователь может выбрать идентификатор какого провайдера OpenID предоставить. Для поддержки данного протокола требуется только JavaScript или современный веб-браузер. OpenID использует только стандарты HTTPS, то есть не требует никаких специальных возможностей клиентского программного обеспечения. Основными элементами процесса аутентификации являются:

  • Идентификатор OpenID
  • Клиент OpenID (ЦП)
  • Провайдер OpenID (ЦИ)

Идентификатор OpenID – это строка, которая является уникальной для каждого пользователя. Один идентификатор не может принадлежать более чем одному пользователю. Различают следующие два вида идентификаторов:

  • Идентификатор, предъявленный пользователем;
  • Заявленный идентификатор – преобразованная строка, которая была получена Целевое Приложение от пользователя, необходимая для нахождения Центра Идентификации (этот процесс называется "обнаружением провайдера"), который должен будет провести процедуру аутентификации.

Клиент OpenID (ЦП) – онлайн – ресурс (чаще всего веб-сайт, но им также может быть файл, изображение или любой ресурс, к которому необходимо контролировать доступ), который использует OpenID для идентификации обращающихся к нему пользователя.

Провайдер OpenID (ЦИ) – сайт, на котором пользователи могут получить идентификатор OpenID. Данный сайт может в будущем авторизовывать и аутентифицировать пользователей, обращающихся к Целевому Приложению. Провайдер OpenID также предоставляет веб-интерфейс для управления выданными идентификаторами.

Схема протокола выглядит следующим образом:

  1. Целевое Приложение получает предъявленный пользователем идентификатор
  2. Целевое Приложение преобразует этот идентификатор в предъявленный идентификатор
  3. При помощи предъявленного идентификатора происходит обнаружение информации о Центре Идентификации
  4. Целевое Приложение, на основании полученной информации устанавливает соединение с провайдером идентификации
  5. Целевое Приложение перенаправляет браузер к провайдеру OpenID, пользователь вводит параметры учетной записи для аутентификации
  6. Целевое Приложение проводит процедуру аутентификации и принимает решение о том, аутентифицировать ли пользователя
  7. Центр Идентификации сообщает о своем решение Целевое Приложение
  8. Целевое Приложение на основании полученного результата аутентификации принимает решение о предоставлении доступа к запрошенному ресурсу

Протокол OAuth

OAuth – это протокол, который обеспечивает клиентскому приложению возможность получения доступа к ресурсам, расположенным на сервере, от имени их владельца (в роли которого может быть клиентское приложение или конечный пользователь). Используя методы HTTP GET, POST и перенаправления, протокол позволяет конечным пользователям предоставить доступ к ресурсам третьей стороне, не раскрывая свои идентификационные данные (обычно логин и пароль). Финальная версия протокола OAuth 1.0 была представлена в рекомендации RFC 5849 в октябре 2007 года , на данный момент уже существуют предварительные версии спецификации, описывающие протокол OAuth 2.0 [RH11]. Данный протокол широко используется в социальных сетях и информационных порталах. В протоколе участвуют три роли:

  • Клиентский браузер, с помощью которого пользователь (владелец защищенных ресурсов), способен делегировать приложению (третьей стороне) доступ к ним;
  • Приложение – сторона, которая пытается получить доступ к ресурсам от имени их владельца;
  • Провайдер – объединение двух компонентов модели CBA: сервер, на котором хранятся ресурсы (ЦП), и сервер, на котором происходит процесс авторизации и выпуск токенов (ЦИ).

Схема протокола имеет следующий вид:

  1. Приложение запрашивает временный токен необходимый для инициации процесса авторизации по протоколу OAuth;
  2. После проверки приложения провайдер выпускает токен, действительный в течение небольшого промежутка времени;
  3. Получив временный токен, приложение перенаправляет пользователя по OAuth User Authorization URL для прохождения процесса аутентификации.
  4. Если пользователь доверяет приложению (временный токен получен), то он предоставляет свои идентификационные данные провайдеру.
  5. В случае успешной аутентификации клиента браузер перенаправляется на страницу приложения.
  6. Приложение запрашивает у провайдера токен, необходимый для получения доступа к ресурсам (запрос должен содержать временный токен, выпущенный на шаге 2)
  7. Если проверка прошла успешно, провайдер выпускает токен, необходимый для доступа к защищенным ресурсам.
  8. Приложение предоставляет токен провайдеру для получения доступа к ресурсам от имени клиента.
  9. Провайдер проверяет каждый входящий запрос и если приложение авторизовано (токен действителен) предоставляет доступ к защищенным ресурсам.

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

Ссылки/Литература

  1. Vittorio Bertocci [Understanding Windows CardSpace: An Introduction to the Concepts and Challenges of Digital Identities]: Addison Wesely, 2007. - 354с.
  2. B. Ferg, C. Howells OpenID Authentication 2.0 - Draft 11. – URL: http://openid.net/specs/openid-authentication-2_0-11.html
  3. J. Kohl, C. Neuman The Kerberos Network Authentication Service (V5). - 112 с. – URL: http://tools.ietf.org/html/rfc1510
  4. K. Lawrence, C. Kaler WS-Trust 1.3 OASIS Specification. – URL: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html
  5. Marc Mercuri. Beginning Information Cards And Cardspace: From Novice To Professional. - 428 с. – Apress. -2007.
  6. D. Recordon, D. Hardt. The OAuth 2.0 Authorization Protocol. – URL: http://tools.ietf.org/html/draft-ietf-oauth-v2-20
  7. Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) . - 25 с. – URL: http://docs.oasis-open.org/security/saml/v2.0/

Источники

  1. Web Services Federation Language (WS-Federation) Version 1.2 // docs.oasis-open. [2017—2017]. Дата обновления: 22.05.2009. URL: http://docs.oasis-open.org/wsfed/federation/v1.2/ws-federation.pdf (дата обращения: 25.03.2017).
  2. Аутентификация OpenID 2.0 // openid. [2017—2017]. Дата обновления: 18.01.2006. URL: http://openid.net/specs/openid-authentication-2_0-11.html (дата обращения: 25.03.2017).
  3. WS-Trust 1.3 // docs.oasis-open. [2017—2017]. Дата обновления: 22.05.2009. URL: http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-os.html (дата обращения: 25.03.2017).