Single login android что это

Единый вход

Единый вход в приложения

Пользователи аутентифицируются в Blitz Identity Provider, а не в каждом приложении в отдельности. Так вы побеждаете парольный хаос: пользователи не сталкиваются с различными формами входа, не устают от многократного ввода логина и пароля при переключении между приложениями, им не нужно помнить много паролей.

С помощью сервера аутентификации Blitz Identity Provider вы сможете автоматически входить в приложения после успешного получения доступа к рабочей станции (операционной системе). Достаточно войти в домен — и при доступе к вашим веб-приложениям не нужно будет повторно вводить логин и пароль.

Технология единого входа Blitz Identity Provider не требует установки специальных программ на устройства пользователя и работает с любыми популярными клиентскими операционными системами и типами устройств (ПК, планшеты, смартфоны).

Single Sign-on для любых целей

Важно, кто входит в ваши приложения — сотрудники компании, клиенты, покупатели, абоненты. У каждой категории пользователей есть свои особенности.

Если ваши приложения — для сотрудников компании, то безопасность входа — ключевая задача. При доступе к внутренним ресурсам (Интранет) сотрудники будут использовать принятые в компании методы аутентификации даже в ущерб удобству.

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

Сервер аутентификации Blitz Identity Provider отлично подходит для организации доступа как к Интранет, так и Интернет-ресурсам. Для каждой сферы применения можно настроить свои правила доступа и использовать наиболее подходящие методы входа. Например:

• Для корпоративной среды можно требовать строгую/усиленную аутентификацию с использованием смарт-карт/USB-токенов или аппаратных брелоков HOTP/TOTP, можно разрешить сквозной вход в веб-приложения после аутентификации в корпоративном домене;
• Интернет-пользователям можно разрешить входить через соцсети (Facebook, ВКонтакте, Google) или госуслуги (ЕСИА). При желании пользователи могут защитить свои аккаунты с помощью SMS-кодов или специальных мобильных приложений (Google Authenticator, Яндекс.Ключ, Duo Mobile).

Поддерживаемые SSO-технологии

SAML 1.0, SAML 1.1, SAML 2.0

Сервер аутентификации Blitz Identity Provider поддерживает SAML — широко распространенный протокол, позволяющий подключить практически любое популярное корпоративное ПО или облачное приложение к сервису входа. Нужное вам приложение не поддерживает SAML? Посмотрите, SAML может быть дополнительной опцией или может потребоваться установка интеграционного коннектора/плагина.

Blitz Identity Provider позволяет использовать оба режима единого входа (SSO), предусмотренных SAML:

1. Приложение инициирует SSO. Для этого приложение обращается к серверу аутентификации Blitz Identity Provider с запросом на идентификацию пользователя. После успешной аутентификации приложение получает от Blitz Identity Provider специальный XML-документ, содержащий данные пользователя (SAML assertions).
2. Поставщик идентификации инициирует SSO. Здесь пользователь сначала входит в свой профиль Blitz Identity Provider, после чего переходит в нужное ему приложение. Сервер аутентификации Blitz Identity Provider перенаправляет пользователя в приложение, прикладывая к вызову требуемые для сквозного входа данные.

OpenID Connect 1.0 и OAuth 2.0

По сравнению с SAML, OpenID Connect (OIDC) / OAuth 2.0 — более современный протокол аутентификации, изначально ориентированный на работу с веб-приложениями в сети Интернет. Если вы создаете новое приложение, то гораздо проще подключить его к сервису авторизации по OIDC. Для разработчиков HTML5/JavaScript-приложений или мобильных приложений под IOS/Android в использовании OIDC также имеется ряд преимуществ.

Сервер аутентификации Blitz Identity Provider позволяет использовать OIDC / OAuth 2.0 в сценариях:

1. Приложение хочет идентифицировать пользователя. Для этого оно направляет пользователя в Blitz Identity Provider, где и происходит идентификация и аутентификация. После этого сервер аутентификации Blitz Identity Provider возвращает пользователя в приложение и передает специальный маркер (ID token). Получив данный маркер, приложение идентифицирует пользователя.
2. Приложение хочет вызывать сервисы другого приложения. Здесь приложение получает от Blitz Identity Provider маркер доступа (access token) на право вызывать сервисы другого приложения от имени определенного пользователя. Blitz Identity Provider выдает этот маркер только после того, как пользователь явно разрешил приложению получать данные о нем в некотором сервисе. Маркер доступа — это своеобразный билет, который используется приложением при обращении к ресурсу, предоставляющему данные. Конечно, пользователь может в любой момент отозвать это разрешение.

Веб-прокси для обеспечения SSO в устаревших веб-приложениях

SAML и OIDC позволяют подключить большинство приложений. Но что делать, если нужное вашей организации веб-приложение не поддерживает эти протоколы и не может быть доработано?

Для этого случая сервер аутентификации Blitz Identity Provider предоставляет следующий сценарий интеграции:

1. Доступ к развернутому в организации устаревшему веб-приложению настраивается через веб-прокси.
2. Производится интеграция веб-прокси с Blitz Identity Provider по специальному протоколу Simple.
3. Веб-прокси перехватывает запрос веб-приложением у пользователя ввода логина и пароля. Веб-прокси обращается к Blitz Identity Provider.
4. Blitz Identity Provider проводит идентификацию и аутентификацию пользователя. В случае успеха сервер аутентификации Blitz Identity Provider через веб-прокси подставляет логин и пароль пользователя в веб-приложение. В самый первый раз, когда Blitz Identity Provider еще не знает логин / пароль пользователя от веб-приложения, он запрашивает у пользователя эту информацию.

Автоматический вход в приложения после успешной аутентификации в ОС

«Зачем у меня просят ввести пароль при доступе к приложению, ведь я только что успешно прошел авторизацию при входе в ОС своей рабочей станции?»

Таким вопросом задаются многие сотрудники компаний. Чтобы исключить повторный запрос пароля, сервер аутентификации Blitz Identity Provider предоставляет функцию автоматического сквозного входа. Если пользователь прошел аутентификацию при входе в операционную систему своей рабочей станции, подключенной к Kerberos-серверу (например, контроллеру домена Active Directory), то доступ к веб-приложению через Blitz Identity Provider будет предоставлен автоматически.

Механизм сквозного входа в Blitz Identity Provider основан на технологии SPNEGO и стандарте GSSAPI. Воспользоваться сквозным входом можно как на ПК под управлением Windows, так и на рабочих станциях на основе macOS и Linux.

Единая учетная запись для всех типов приложений

К серверу аутентификации Blitz Identity Provider можно подключить не только веб-приложения. Blitz Identity Provider уже совместим со многими корпоративными десктопными приложениями и нативными мобильными приложениями. Например, Blitz Identity Provider совместим с MS Office 365 и G Suite.

Blitz Identity Provider может выступать в качестве OAuth 2.0 сервера. Если вы разрабатываете нативное мобильное приложение, Blitz Identity Provider поможет вам быстро реализовать функцию привязки устройств и приложений к учетной записи пользователя, осуществления контроля доступа привязанных приложений к серверным программным интерфейсам (API).

Источник

Реализация Single Sign On в Symfony2 приложении

Что такое Single Sign On?

Single Sign On — это технология, с помощью которой пользователь, будучи аутентифицированным на удостоверяющем центре (далее Identity Provider, IdP), будет автоматически аутентифицирован на другом сервисе (далее Service Provider, SP или Consumer[1-N]) этой компании.

Механизм Single Sign On используют такие сайты, как ХабраХабр, Yandex, Google. Приемущества такого подхода к аутентификации пользователей очевидны:

• Пользователь вводит пароль только 1 раз
• Или вовсе не вводит пароль на IdP, если там был использован вход через социальную сеть или с использованием OpenID
• Автоматически аутентифицируется на всех проектах компании
• Данные пользователя могут плавать между сервисами от IdP до SP прозрачно для пользователя

Минусы, конечно, вытекают, как всегда, из плюсов:

• Потеря пароля от IdP влечет за собой проблему входа во все сервисы
• Потенциально возросший риск кражи мастер сессии с IdP (может быть уменьшен с помощью привязки сессии к подсети провайдера, а также использования HTTPS, HTTP Only Cookies и SSL Only Cookies)
• Потенциально возросший риск кражи пароля от IdP
• .

Несмотря на это, с точки зрения бизнеса, а также user experience, реализация данного функционала перевешивает все минусы, и начинается эпопея по имплементации SSO в компании.

Перед тем как приступить к имплементации SSO в компании, хорошо было бы убедиться, что вы хорошо знаете, что такое:

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

На хабре есть еще одна отличная статья по базовым принципам работы с Cookies и как надо правильно ставить Cookies, чтобы не остаться без штанов: habrahabr.ru/company/mailru/blog/228997.

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

Как это будет работать

В общем случае аутентификация будет проходить по следующему сценарию:

Рассмотрим сценарий, когда пользователь через закладки переходит на какую-либо защищенную авторизацией страницу (п. 1 на схеме).
Далее в Symfony2 активируется механизм Entry point и переадресовывает нас на наш IdP, где нам должны докинуть OTP. Тут есть несколько сценариев развития событий:

1. Пользователь аутентифицирован на IdP, тогда IdP просто докинет в цепочку переадресаций OTP (п. 3 на схеме, зеленая линия)
2. Пользователь не аутентифицирован на IdP, тогда его надо отправить на форму ввода логина/пароля (п. 3 на схеме, красная линия)
3. Пользователь вообще в первый раз нас видит, но хочет зарегистрироваться и уходит на форму регистрации (В этот момент в сессии на IdP сохранен SP, с которого он пришел.)

После того как пользователь, например, прошел регистрацию, его надо перенаправить на п. 3 по зеленой линии на валидацию OTP на SP, с которого он пришел к нам на IdP. Когда мы на SP валидируем OTP, мы делаем доверенный REST запрос к нашему IdP, чтобы удостовериться, что такой OTP действительно существует и еще не истек по времени. В этот момент REST сервис должен инвалидировать этот OTP. Ставьте лок, эта операция должна быть атомарна. Дальнейшие запросы с таким OTP должны возвращать либо HTTP 400, либо HTTP 404 для SP.

В случае, когда 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 отвечает за:

• Генерацию одноразовых паролей (OTP)
• Запоминает в сессию, с какого SP пришел пользователь
• Функциональность для выхода со всех SP-ов

Ставим через composer:

Далее обновляем зависимости и прописываем наш бандл в AppKernel:

Источник

Как работает single sign-on (технология единого входа)?

Что такое single sign-on?

Технология единого входа (Single sign-on SSO) — метод аутентификации, который позволяет пользователям безопасно аутентифицироваться сразу в нескольких приложениях и сайтах, используя один набор учетных данных.

Как работает SSO?

SSO базируется на настройке доверительных отношений между приложением, известным как провайдер услуг, и системой управления доступами, например, OneLogin. Такие доверительные отношения часто базируются на обмене сертификатом между системой управления доступами и провайдером услуг. Такой сертификат может использоваться, чтобы обозначить идентификационную информацию, которая отправляется от системы управления доступами провайдеру услуг, таким образом провайдер услуг будет знать, что информация поступает из надежного источника. В SSO идентификационные данные принимают форму токенов, содержащих идентификационные значения информации о пользователе такие, как email или имя пользователя.

Порядок авторизации обычно выглядит следующим образом:

1. Пользователь заходит в приложение или на сайт, доступ к которому он хочет получить, то есть к провайдеру услуг.
2. Провайдер услуг отправляет токен, содержащий информацию о пользователе (такую как email адрес) системе SSO (так же известной, как система управления доступами), как часть запроса на аутентификацию пользователя.
3. В первую очередь система управления доступами проверяет был ли пользователь аутентифицирован до этого момента. Если да, она предоставляет пользователю доступ к приложению провайдера услуг, сразу приступая к шагу 5.
4. Если пользователь не авторизовался, ему будет необходимо это сделать, предоставив идентификационные данные, требуемые системой управления доступами. Это может быть просто логин и пароль или же другие виды аутентификации, например одноразовый пароль (OTP — One-Time Password).
5. Как только система управления доступами одобрит идентификационные данные, она вернет токен провайдеру услуг, подтверждая успешную аутентификацию.
6. Этот токен проходит “сквозь браузер” пользователя провайдеру услуг.
7. Токен, полученный провайдером услуг, подтверждается согласно доверительным отношениям, установленным между провайдером услуг и системой управления доступами во время первоначальной настройки.
8. Пользователю предоставляется доступ к провайдеру услуг.

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

Что такое токен в контексте SSO?

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

Является ли технология SSO безопасной?

Ответом на этот вопрос будет «в зависимости от ситуации».

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

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

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

Как внедрить SSO?

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

• С какими типами пользователей вы работаете и какие у них требования?
• Вы ищете локальное или облачное решение?
• Возможен ли дальнейший рост выбранной программной платформы вместе с вашей компанией и ее запросами?
• Какие функции вам необходимы, чтобы убедиться в том, что процесс авторизации проходят только проверенные пользователи? MFA, Adaptive Authentication, Device Trust, IP Address Whitelisting, и т.д?
• С какими системами вам необходимо интегрироваться?
• Нужен ли вам доступ к программному интерфейсу приложения (API)?

Что отличает настоящую SSO от хранилища или менеджера паролей?

Важно понимать разницу между SSO (Технологией единого входа) и хранилищем или менеджерами паролей, которые периодически путают с SSO, но в контексте Same Sign-On — что означает “такой же/одинаковый вход”, а не “единый вход” (Single Sign-On). Говоря о хранилище паролей, у вас может быть один логин и пароль, но их нужно будет вводить каждый раз при переходе в новое приложение или на новый сайт. Такая система попросту хранит ваши идентификационные данные для других приложений и вводит их когда это необходимо. В данном случае между приложением и хранилищем паролей не установлены доверительные отношения.

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

В чем разница между программным обеспечением единого входа и решением SSO?

Изучая доступные варианты единого входа, вы можете увидеть, что их иногда называют программным обеспечением единого входа, а не решением единого входа или провайдером единого входа. Часто разница состоит лишь в том, как позиционируют себя компании. Фрагмент программного обеспечения предполагает локальную установку. Обычно это то, что разработано для определенного набора задач и ничего более. Программный продукт предполагает, что есть возможность расширяться и кастомизировать потенциальные возможности исходного варианта. Провайдер будет отличным вариантом, чтобы обратиться к компании, которая производит или пользуется программным продуктом. Например, OneLogin в качестве провайдера SSO.

Бывают ли разные типы SSO?

Когда мы говорим о едином входе (SSO), используется множество терминов:

• Federated Identity Management (FIM)
• OAuth (OAuth 2.0 в настоящее время)
• OpenID Connect (OIDC)
• Security Access Markup Language (SAML)
• Same Sign On (SSO)

На самом деле, SSO это часть более крупной концепции под названием Federated Identity Management, поэтому иногда SSO обозначается, как федеративная SSO. FIM просто относится к доверительным отношениям, созданным между двумя или более доменами или системами управления идентификацией. Система единого входа (SSO) — это характеристика/фича, доступная внутри архитектуры FIM.

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

OpenID Connect (OIDC) — это уровень аутентификации, наложенный на базу OAuth 2.0, чтобы обеспечить фунциональность SSO.

Security Access Markup Language (SAML) — это открытый стандарт, который также разработан для обеспечения функциональности SSO.

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

Также существуют несколько конкретных систем, которые стоит упомянуть, говоря о платформе SSO: Active Directory, Active Directory Federation Services (ADFS) и Lightweight Directory Service Protocol (LDAP).

Active Directory, который в настоящее время именуется, как Active Directory Directory Services (ADDS) — это централизованная служба каталогов Microsoft. Пользователи и ресурсы добавляются в службу каталогов для централизованного управления, а ADDS работает с такими аутентификационными протоколами, как NTLM и Kerberos. Таким образом, пользователи, относящиеся к ADDS могут аутентифицироваться с их устройств и получить доступ к другим системам, интегрированным с ADDS. Это и есть форма SSO.

Active Directory Federation Services (ADFS) это тип управления федеративной идентификацией (Federated Identity Management system), которая также предполагает возможность Single Sign-on. Он также поддерживает SAML и OIDC. ADFS преимущественно используется для установления доверительных отношений между ADDS и другими системами, такими как Azure AD или других служб ADDS.

Протокол LDAP (Lightweight Directory Service Protocol) — это стандарт, определяющий способ запроса и организации информационной базы. LDAP позволяет вам централизованно управлять такими ресурсами, как пользователи и системы. LDAP, однако, не определяет порядок авторизации, это означает, что он не устанавливает непосредственный протокол, используемый для аутентификации. Но он часто применяется как часть процесса аутентификации и контроля доступа. Например, прежде, чем пользователь получит доступ к определенному ресурсу, LDAP сможет запросить информацию о пользователе и группах, в которых он состоит, чтобы удостовериться, что у пользователя есть доступ к данному ресурсу. LDAP платформа на подобие OpenLDAP обеспечивает аутентификацию с помощью аутентификационных протоколов (например, Simple Authentication и Security Layer SASL).

Как работает система единого входа как услуга?

SSO функционирует также, как и многие другие приложения, работающие через интернет. Подобные OneLogin платформы, функционирующие через облако, можно отнести к категории решений единого входа “Software as a Service” (SaaS).

Что такое App-to-App (приложение-приложение) SSO?

В заключение, возможно вы слышали о App-to-App SSO. Пока еще такой подход не является стандартным. Такое понятие больше используется SAPCloud для обозначения процесса передачи идентификационных данных пользователя из одного приложения в любое из других, состоящих в их экосистеме. В какой-то степени такой метод присущ OAuth 2.0, но хочется снова подчеркнуть, что это не стандартный протокол или метод. В настоящее время он является характерным только для SAPCloud.

Источник