Что такое sso связка
Реализация Single Sign On в Symfony2 приложении
Что такое Single Sign On?
Single Sign On — это технология, с помощью которой пользователь, будучи аутентифицированным на удостоверяющем центре (далее Identity Provider, IdP), будет автоматически аутентифицирован на другом сервисе (далее Service Provider, SP или Consumer[1-N]) этой компании.
Механизм Single Sign On используют такие сайты, как ХабраХабр, Yandex, Google. Приемущества такого подхода к аутентификации пользователей очевидны:
Перед тем как приступить к имплементации SSO в компании, хорошо было бы убедиться, что вы хорошо знаете, что такое:
Это важно, потому что неправильная реализация SSO, может привести к критическим ошибкам во всех сервисах, которые подключены к SSO: начиная от компрометации пользовательских данных в одном сервисе, заканчивая угоном аккаунта в IdP, что влечет за собой компрометацию данных во всех сервисах.
На хабре есть еще одна отличная статья по базовым принципам работы с Cookies и как надо правильно ставить Cookies, чтобы не остаться без штанов: habrahabr.ru/company/mailru/blog/228997.
Итак, после ознакомления с базовой теорией: что такое SSO, аспектами безопасности, которые связаны с этой задачей, — мы можем приступить к ее реализации.
Как это будет работать
В общем случае аутентификация будет проходить по следующему сценарию:
Рассмотрим сценарий, когда пользователь через закладки переходит на какую-либо защищенную авторизацией страницу (п. 1 на схеме).
Далее в Symfony2 активируется механизм Entry point и переадресовывает нас на наш IdP, где нам должны докинуть OTP. Тут есть несколько сценариев развития событий:
В случае, когда IdP ответил, что такой OTP существует и валиден, SP аутентифицирует пользователя посредством выдачи ему PreAuthenticatedToken’а.
Выход будет работать по следующей схеме:
Обратите внимание, что данный тип выхода рассматривается с точки зрения начала процесса на SP. Это важно, потому что пользователь будет возвращен туда, где он начал делать эту операцию.
Предположим, что пользователь был на некой странице /secured_area и нажал на «Выход». В этот момент происходит локальный логаут в рамках SP. Затем мы уходим на IdP на специальный URL /sso/logout, который будет управлять процессом выхода со всех сервисов для этого пользователя. Т.к. пользователь уже пришел с SP, то IdP выбирает следующий сервис, который есть в компании, и отправляет на него делать выход. Тот сервис, в свою очередь, снова по завершению, отправляет нас на IdP и в случае, если сервисы кончились, выполняет локальный выход (п. 5 на схеме). После пользователь отправляется обратно на SP, с которого он начал делать выход.
Есть и другой вариант развития событий, в котором пользователь начинает процесс выхода не с SP а с IdP. И выглядит это примерно так:
Удостоверяющий центр (IdentityProvider)
Чтобы сделать удостоверяющий центр, сначала вы должны выбрать приложение в вашей компании, которое будет за это отвечать, наподобие, как это сделано у Yandex (Яндекс.Паспорт) или у Google (Google Accounts).
В это приложение мы будем устанавливаеть первую часть: SingleSignOnIdentityProviderBundle
SingleSignOnIdentityProviderBundle отвечает за:
Далее обновляем зависимости и прописываем наш бандл в AppKernel:
What is single sign-on (SSO)?
Single sign-on (SSO) is an authentication capability that lets users access multiple applications with one set of sign-in credentials. Enterprises typically use SSO to provide simpler access to a variety of web, on-premises, and cloud applications for a better user experience. It can also give IT more control over user access, reduce password-related help desk calls, and improve security and compliance.
Explore additional SSO topics:
Why use single sign-on?
Today, applications are deployed across datacenters and clouds, and being delivered as software as a service (SaaS). Every business application requires users to be authenticated before they are given access to a resource. In the pre-SSO days, every time a user needed to move between applications, they had to sign in with a set of credentials. Most of the time, every application had a separate set of credentials, and it resulted in poor user experience, failed sign-ins as a result of forgotten credentials, inconsistent access control policies, and higher cost to support these applications.
SSO has simplified the way users interact with and access their applications. With SSO, users can save time by accessing all their SaaS, enterprise, web, and virtual applications, as well as other corporate resources like network file shares with only one set of credentials.
How does single sign-on work?
Single sign-on is a component of federated identity management (FIM), an arrangement between enterprises that lets subscribers use the same identification data to access each enterprise’s network. FIM is often referred to as identity federation.
The user’s identity is linked across multiple security domains, each with its own identity management system. When the domains are federated, the user can authenticate to one and access resources in another without having to sign in again.
The framework that allows third parties, like LinkedIn or Facebook, to use someone’s account information to sign them in without exposing their password is called OAuth. It acts as an intermediary by providing the service with a token allowing only specified account information to be shared. When a user accesses an application, the service sends an authentication request to the identity provider, which then verifies the request and grants access.
There are other authenticating protocols, like Kerberos and the Security Assertion Markup Language (SAML). Kerberos-based SSO services issue a time-stamped authentication ticket, or ticket-granting ticket (TGT), which gets service tickets for other applications without prompting the user to enter new credentials. SAML-based SSO services exchange user authentication and authorization data across secure domains, and manage communications between the user, an identity provider with a user directory, and a service provider.
Make the right decision when selecting an SSO solution
Learn the five features you should prioritize when looking for a single sign-on solution.
What are the benefits of single sign-on?
SSO offers benefits to both users and IT. From a user perspective, SSO alleviates password fatigue, making it easier and faster to access applications.
For IT, SSO can help reduce the number of password-related support calls. And automated credential management alleviates the burden of manually managing employees’ access to apps and services. SSO also makes it easier for IT to quickly provision and roll out SaaS applications to employees.
Additionally, from a security perspective, SSO can reduce the threat of cyberattacks, like phishing, by reducing the number of credentials at risk. It’s critical, however, to also implement multi-factor authentication as a backup in case passwords do become compromised.
Single sign on best practices
When searching for an SSO solution, it’s important to keep the following best practices in mind.
SSO на микросервисной архитектуре. Используем Keycloak. Часть №1
В любой крупной компании, и X5 Retail Group не исключение, по мере развития возрастает количество проектов, где требуется авторизация пользователей. С течением времени требуется бесшовный переход пользователей из одного приложения в другой и тогда возникает необходимость использования единого сервера Single-Sing-On (SSO). Но как быть, когда такие идентификационные провайдеры как AD или иные, не обладающие дополнительными атрибутами, уже используются в различных проектах. На помощь придет класс систем под названием «идентификационные брокеры». Наиболее функциональными являются его представители, такие как Keycloak, Gravitee Access management и пр. Чаще всего сценарии использования могут быть различны: машинное взаимодействие, участие пользователей и пр. Решение должно поддерживать гибкий и масштабируемый функционал, способный объединить все требования в одном, и такие решением в нашей компании сейчас является индикационный брокер – Keycloak.
Keycloak – это продукт с открытым исходным кодом, предназначенный для идентификации и контроля доступа и поддерживаемый компанией RedHat. Он является основой для продуктов компании использующих SSO – RH-SSO.
Основные понятия
Прежде чем начать разбираться с решениями и подходами следует определиться в терминах и последовательности процессов:
Идентификация — это процедура распознавания субъекта по его идентификатору (проще говоря, это определение имени, логина или номера).
Аутентификация – это процедура проверки подлинности (пользователя проверяют с помощью пароля, письмо проверяют по электронной подписи и т.д.)
Авторизация – это предоставление доступа к какому-либо ресурсу (например, к электронной почте).
Идентификационный брокер Keycloak
Keycloak — это решение для управления идентификацией и доступом с открытым исходным кодом, предназначенное для использования в ИС где могут использоваться паттерны микросервисной архитектуры.
Keycloak предлагает такие функции, как единый вход (SSO), брокерская идентификация и социальный вход в систему, федерация пользователей, клиентские адаптеры, консоль администратора и консоль управления учетными записями.
Базовый функционал, поддерживаемый в Keycloak:
Идентификационные провайдеры уровня предприятия (On-Premise)
Возможность аутентификации пользователей через User Federation сервисы.
Также может быть использована сквозная аутентификация — если пользователи проходят аутентификацию на рабочих станциях с Kerberos (LDAP или AD), то они могут быть автоматически аутентифицированы на Keycloak без необходимости снова указывать свое имя пользователя и пароль.
Для аутентификации и дальнейшей авторизации пользователей возможно использование реляционной СУБД, что наиболее применимо для сред разработки, так как не влечет длительных настроек и интеграций на ранних стадиях проектов. По умолчанию в Keycloak используется встроенная СУБД для хранения настроек и данных о пользователях.
Список поддерживаемых СУБД обширен и включает в себя: MS SQL, Oracle, PostgreSQL, MariaDB, Oracle и другие. Наиболее протестированными на данный момент являются Oracle 12C Release1 RAC и Galera 3.12 cluster для MariaDB 10.1.19.
Идентификационные провайдеры — social login
Возможно использование логина из социальных сетей. Для активации возможности аутентифицировать пользователей используется консоль администратора Keycloack. Изменений в коде приложений не требуется и данный функционал доступен «из коробки» и может быть активирован в любой стадии реализации проекта.
Для аутентификации пользователей возможно использование OpenID/SAML Identity провайдеров.
Типовые сценарии авторизации с использование OAuth2 в Keycloak
Authorization Code Flow — используется с серверными приложениями (server-side applications). Один из наиболее распространенных типов разрешения на авторизацию, поскольку он хорошо подходит для серверных приложений, в которых исходный код приложения и даные клиента не доступны посторонним. Процесс в данном случае строится на перенаправлении (redirection). Приложение должно быть в состоянии взаимодействовать с пользовательским агентом (user-agent), таким как веб-браузер — получать коды авторизации API перенаправляемые через пользовательский агент.
Implicit Flow — используется мобильными или веб-приложениями (приложения, работающие на устройстве пользователя).
Неявный тип разрешения на авторизацию используется мобильными и веб-приложениями, где конфиденциальность клиента не может быть гарантирована. Неявный тип разрешения также использует перенаправление пользовательского агента, при этом токен доступа передается пользовательскому агенту для дальнейшего использовании в приложении. Это делает токен доступным пользователю и другим приложениям на устройстве пользователя. При этом типе разрешения на авторизацию не осуществляется аутентификация подлинности приложения, а сам процесс полагается на URL перенаправления (зарегистрированный ранее в сервисе).
Implicit Flow не поддерживает токены обновления токена доступа (refresh tokens).
Client Credentials Grant Flow — используются при доступе приложения к API. Этот тип разрешения на авторизацию обычно используется для взаимодействий «сервер-сервер», которые должны выполняться в фоновом режиме без немедленного взаимодействия с пользователем. Поток предоставления учетных данных клиента позволяет веб-службе (конфиденциальному клиенту) использовать собственные учетные данные вместо олицетворения пользователя для проверки подлинности при вызове другой веб-службы. Для более высокого уровня безопасности возможно вызывающей службе использовать сертификат (вместо общего секрета) в качестве учетных данных.
JWT токен и его преимущества
JWT (JSON Web Token) — открытый стандарт (https://tools.ietf.org/html/rfc7519), который определяет компактный и автономный способ для защищенной передачи информации между сторонами в виде JSON-объекта.
Согласно стандарту, токен состоит из трех частей в base-64 формате, разделенных точками. Первая часть называется заголовком (header), в которой содержится тип токена и название хэш-алгоритма для получения цифровой подписи. Вторая часть хранит основную информацию (пользователь, атрибуты и т.д.). Третья часть – цифровая подпись.
Refresh-токен — это токен, позволяющий клиентам запрашивать новые access-токены по истечении их времени жизни. Данные токены обычно выдаются на длительный срок.
Основные преимущества применения в микросервисной архитектуре:
JWT токен — состав
Заголовок — по умолчанию, заголовок содержит только тип токена и алгоритм, используемый для шифрования.
Тип токена хранится в ключе «typ». Ключ «typ» игнорируется в JWT. Если ключ «typ» присутствует, его значение должно быть JWT, чтобы указать, что этот объект является JSON Web Token.
Второй ключ «alg» определяет алгоритм, используемый для шифрования токена. По умолчанию он должен быть установлен в HS256. Заголовок кодируется в base64.
< "alg": "HS256", "typ": "JWT">
Payload (содержимое) — в полезной нагрузке хранится любая информация, которую нужно проверить. Каждый ключ в полезной нагрузке известен как «заявление». К примеру, в приложение можно войти только по приглашению (закрытое промо). Когда мы хотим пригласить кого-то поучаствовать, мы отправляем ему письмо с приглашением. Важно проверить, что адрес электронной почты принадлежит человеку, который принимает приглашение, поэтому мы включим этот адрес в полезную нагрузку, для этого сохраним его в ключе «e-mail»
< "email": "example@x5.ru" >
Ключи в payload могут быть произвольными. Тем не менее, есть несколько зарезервированных:
Берутся закодированные в base64: заголовок и payload, они объединяются в строку через точку. Затем эта строка и секретный ключ поступает на вход алгоритма шифрования, указанного в заголовке (ключ «alg»). Ключом может быть любая строка. Более длинные строки будут наиболее предпочтительнее, поскольку потребуется больше времени на подбор.
Построение архитектуры отказоустойчивого кластера Keycloak
При использовании единого кластера для всех проектов возникают повышенные требования к решению для SSO. Когда количество проектов невелико эти требования не так ощутимы для всех проектов, однако с увеличением количества пользователей и интеграций повышаются требования к доступности и производительности.
Повышение рисков отказа единого SSO повышает требования к архитектуре решения и используемых методов резервирования компонентов и приводит к очень жесткому SLA. В связи с этим чаще при разработке или ранних стадиях внедрения решений проекты имеют собственную не отказоустойчивую инфраструктуру. По мере развития требуется заложить возможности развития и масштабирования. Наиболее гибко строить отказоустойчивый кластер с применением контейнерной виртуализации или гибридного подхода.
Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных — оба узла базы данных должны синхронно реплицироваться между различными геораспределенными ЦОД.
Самый простой пример отказоустойчивой инсталяции.
Какие преимущества дает использование единого кластера:
На что стоит обратить внимание при планировании кластера
Keycloak использует систему управления СУБД для сохранения: realms, clients, users и пр.
Поддерживается большой спектр СУБД: MS SQL, Oracle, MySQL, PostgreSQL. Keycloak поставляется с собственной встроенной реляционной базой данных. Рекомендуется использование для ненагруженных сред – такие как среды разработки.
Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных и оба узла кластера баз данных синхронно реплицируются между ЦОД.
Распределенный кеш (Infinspan)
Для корректной работы кластера требуется дополнительная синхронизация следующих типов кеша с использованием JBoss Data Grid:
Authentication sessions — используемый для сохранения данных при аутентификации конкретного пользователя. Запросы из этого кэша обычно включают только браузер и сервер Keycloak, а не приложение.
Action tokens — используются для сценариев, когда пользователю необходимо подтвердить действие асинхронно (по электронной почте). Например, во время потока forget password кэш actionTokens Infinispan используется для отслеживания метаданных о связанных маркерах действий, которые уже использовались, поэтому его нельзя использовать повторно.
Caching and invalidation of persistent data – используется для кэширования постоянных данных, чтобы избежать лишних запросов к базе данных. Когда какой-либо сервер Keycloak обновляет данные, все остальные серверы Keycloak во всех центрах обработки данных должны знать об этом.
Work — используется только для отправки сообщений о недействительности между узлами кластера и центрами обработки данных.
User sessions — используются для сохранения данных о сеансах пользователя, которые действительны в течение сеанса браузера пользователя. Кэш должен обрабатывать HTTP-запросы от конечного пользователя и приложения.
Brute force protection — используется для отслеживания данных о неудачных входах.
Балансировка нагрузки
Балансировщик нагрузки является единой точкой входа в keycloak и должен поддерживать sticky sessions.
Сервера приложений
Используются для контроля взаимодействия компонентов между собой и могут быть виртуализированы или контейнерезированы с применением имеющихся средств автоматизации и динамического масштабирования средств автоматизации инфраструктуры. Наиболее распространенные сценарии развертывания в OpenShift, Kubernetes, Rancher.
На этом первая часть – теоретическая — закончена. В следующих циклах статей будут разобраны примеры интеграций с различными идентификационными провайдерами и примеры настроек.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
SSO (Single Sign-On)
Таким образом ключевым моментом здесь является то, что пользователю требуется войти в систему для подключения к приложению только один раз, причем в контексте этой же сессии нет необходимости проходить аутентификацию повторно при доступе к другому приложению или серверу. [Источник 1]
Содержание
Общая схема систем единого входа
Подход технологии единого входа продемонстрирован на схеме. При этом подходе система может собирать от пользователя (в рамках первичного входа) все идентификационные и аутентификационные данные, необходимые для поддержки аутентификации этого пользователя на каждом из вторичных доменов, с которыми ему потенциально может понадобиться взаимодействовать. Эти предоставленные пользователем данные впоследствии используются сервисами единого входа в пределах первичного домена для поддержки аутентификации этого конечного пользователя на каждом из вторичных доменов, с которыми ему реально требуется взаимодействовать.
Информация, предоставленная конечным пользователем в рамках процедуры входа в первичный домен, может использоваться для поддержки входа во вторичный домен несколькими способами:
С точки зрения управления, модель единого входа предоставляет единый интерфейс управления учётными записями пользователей, через который все домены могут управляться координированным и синхронизированным способом.
С точки зрения интеграции, важнейшие аспекты безопасности модели единого входа заключаются в следующем:
Основные достоинства и недостатки SSO
| Достоинства | Потенциальные недостатки |
|---|---|
| Снижение времени, требуемого для повторного ввода паролей; | Попытка первоначальной реализации может быть сложной, в зависимости от количества существующих не сопоставимых систем |
| Снижение количества паролей, необходимых для различных программных продуктов; | Скомпромитированные входные данные (credentials) пользователя могут привести к доступу к большому числу приложений |
| Снижение нагрузки на сеть, связанной с многократными процедурами аутентификации; | Производитель либо не использует существующий открытый стандарт, либо использует стандарты, несовместимые со стандартами, используемыми другими приложениями. |
| Снижении стоимости IT-системы за счет снижения количества инцидентов ИБ, связанных с учетными данными пользователей; | Данный механизм требует установки специальных агентов, поддерживаются не все устройства и операционные системы. |
Методы SSO
Технология единого входа включает в себя следующие методы:
Основные преимущества SSO
| Преимущества для конечных пользователей | Преимущества для администратора безопасности |
|---|---|
| Необходимо хранить в памяти только один механизм аутентификации. Для аутентификации на основе пароля это означает, что пользователям надо помнить только один пароль | Запись регистрационных данных пользователя в одном месте для управления и обеспечения безопасности. |
| При употреблении паролей пользователи должны изменять только один пароль и следовать только одному набору правил паролирования. | Возможность ведения общих для организации политик паролирования и обеспечения безопасности, позволяющих обеспечить «сквозную» безопасность, возможно в рамках приложений и систем. Это позволит избежать проблем с несоответствием требований по сложности паролей и периодам их смены в различных системах. |
| Единственный вход для каждого пользователя в домене SSO, обычно только один раз в день. | Проще контролировать информацию о правах доступа пользователя (user security information) и при необходимости корректировать ее, чем при отслеживании всех отдельных систем, к которым имеет доступ пользователь. Это особенно важно, когда пользователям назначают роли с другими уровнями доступа. |
Протоколы, обеспечивающие технологию единого входа
На данный момент существует множество протоколов, которые обеспечивают технологию единого ввода. Рассмотрим лишь некоторые из них:
Протоколы семейства WS-
Данный протокол основывается на стандартах WS-Security и WS-Trust и описан в спецификации WS-Federation Passive Requestor Profile, в которой представлены механизмы для запроса, обмена и выдачи маркера безопасности в ситуации с пассивным клиентом. Определение «пассивный клиент» подразумевает наличие на компьютере пользователя только веб-браузера, так как взаимодействие между пользователем, Центр Идентификации и Целевое Приложение (веб-сервер, предоставляющий ресурсы) происходит в пределах функциональности базы HTTP (методы GET, POST, перенаправления и cookies). Схема протокола имеет следующий вид:
С учетом требований, описанных в спецификации WS-Federation Passive Requestor Profile, протоколом поддерживаются следующие форматы маркеров безопасности:
Протокол 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 также предоставляет веб-интерфейс для управления выданными идентификаторами.
Схема протокола выглядит следующим образом:
Протокол OAuth
Схема протокола имеет следующий вид:
Протокол OAuth является широко распространенным, благодаря его использованию сервисами поисковых систем, почтовыми сервисами, а также в социальных сетях.