Что такое single sign on sso

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

SSO (Single Sign-On)

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

Содержание

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

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

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

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

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

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

Методы SSO

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

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

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

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

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

Источник

Использование единого Sign-On (SSO) через VPN и Wi-Fi подключения

В этой статье разъясняются требования к Sign-On единого доступа (SSO) к локальному домену через Wi-Fi или VPN-соединения. Обычно используются следующие сценарии:

Например, необходимо подключиться к корпоративной сети и получить доступ к внутреннему веб-сайту, для Windows комплексной проверки подлинности.

Учетные данные, используемые для проверки подлинности подключения, помещаются в Диспетчер учетных данных в качестве учетных данных по умолчанию для сеанса logon. Диспетчер учетных данных хранит учетные данные, которые можно использовать для определенных ресурсов домена. Они основаны на целевом имени ресурса:

Учетные данные размещаются в диспетчере учетных данных в качестве учетных данных «*Session». Учетные данные «*Session» предполагают, что он действителен для текущего сеанса пользователя. Учетные данные также очищаются при отключении подключения к Wi-Fi или VPN.

Например, если Microsoft Edge пытается получить доступ к ресурсу домена, Microsoft Edge имеет право Enterprise проверки подлинности. Это позволяет WinInet освободить учетные данные, которые он получает от диспетчера учетных данных к запрашиваемой службе SSP. Дополнительные сведения о возможностях Enterprise проверки подлинности см. в декларациях о возможностях приложения.

Местный орган безопасности будет смотреть на приложение устройства, чтобы определить, имеет ли оно нужные возможности. Это включает такие элементы, как универсальное приложение Windows платформы (UWP). Если приложение не является UWP, это не имеет значения. Но если приложение является приложением UWP, оно будет оцениваться по возможностям устройства для Enterprise проверки подлинности. Если у него есть такие возможности и если ресурс, к который вы пытаетесь получить доступ, находится в зоне Интрасети в Internet Options (ZoneMap), то учетные данные будут освобождены. Это поведение помогает предотвратить неправильное использование учетных данных сторонними лицами.

Зона Интрасети

Настройка ZoneMap

ZoneMap управляется с помощью реестра, который можно установить через MDM. По умолчанию однометные имена, http://finance например, уже находятся в зоне интрасети. Для нескольких имен меток, таких как http://finance.net ZoneMap, необходимо обновить.

Политика MDM

./Vendor/MSFT/Registry/HKU/S-1-5-21-2702878673-795188819-444038987-27 81/Software/Microsoft/Windows/CurrentVersion/Internet%20Settings/ZoneMap/Domains/ /* в качестве значения 1 для каждого из доменов, которые вы хотите в SSO с вашего устройства. Это добавляет указанные домены в зону Интрасети Microsoft Edge браузера.

Требования к учетным данным

Для VPN после проверки подлинности в диспетчер учетных данных будут добавлены следующие типы учетных данных:

Имя пользователя также должно включать домен, который можно получить по подключению (VPN или WiFi).

Шаблоны сертификатов пользователей

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

Конфигурация сервера NDES

Сервер NDES необходимо настроить таким образом, чтобы входящие запросы SCEP можно было сопопооставить с нужным шаблоном, который будет использоваться. Дополнительные сведения см. в справке Настройка инфраструктуры сертификатов для SCEP.

Требования Active Directory

Необходимо подключение IP к DNS-серверу и контроллеру домена через сетевой интерфейс, чтобы проверка подлинности также была успешной.

Контроллеры домена должны иметь соответствующие сертификаты KDC, чтобы клиент доверял им в качестве контроллеров домена. Так как телефоны не соединены с доменом, корневой ЦС сертификата KDC должен быть в сторонней корневой ЦС или магазине доверенных корневых корней смарт-карт.

Контроллеры домена должны использовать сертификаты на основе обновленного шаблона сертификата KDC Kerberos Authentication. Это требует, чтобы все контроллеры проверки подлинности домена Windows Server 2016, или вам необходимо включить строгую проверку KDC на контроллерах домена, которые запускают предыдущие версии Windows Server.

Дополнительные сведения см. в дополнительных сведениях о включаемой строгой проверке KDC в Windows Kerberos.

Источник

Принцип единого входа (Single sign-on)

Начнем с представления более строгого определения SSO :

Это определение взято с Web-сайта компании The Open Group по адресу:

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

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

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

Потенциальные недостатки SSO :

7.1 Методы SSO

Все методы SSO должны быть направлены на решение трех проблем:

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

7.1.1 Единый пароль или SSO

Чтобы иметь единый пароль несмотря на то, что каждое приложение использует специализированное хранилище для ID и пароля ( credentials store ), идентификаторы ( ID ) пользователей и пароли должны быть каким-то образом синхронизированы. Так как же можно синхронизировать пароли в различных хранилищах (каталогах)? Самый простой ответ, это пользователи могут вручную поддерживать идентичность своих logon-имен и паролей для различных систем, если у них есть на это соответствующие полномочия. Конечно, это без сомнения, самый недружелюбный к пользователю подход, потому что нагрузка в этом случае полностью ложится на него. Могут ли пароли быть синхронизированы программно? В некоторых случаях могут, хотя на самом деле процесс синхронизации представляет из себя одновременную смену паролей.

Одновременные изменения паролей

Большинство процессов «синхронизации» паролей технически являются процессом одновременного изменения паролей, происходящим в фоновом режиме. К примеру, если вы разрешили синхронизацию паролей Notes и Windows, то при изменении вами своего пароля в Notes введенный новый пароль временно сохраняется в буфере, после чего автоматически передается процессу изменения пароля Windows в фоновом режиме. Процесс очень похож на процесс синхронизации пароля Notes и Domino интернет-паролей. Одновременное изменение эффективно там, где вам необходимо набрать пароль только один раз, и он автоматически будет передан второй парольной системе.

Синхронизация паролей

С точки зрения обеспечения безопасности, возможность синхронизации значения пароля из хранилища, непременно связано с возникновением очень нежелательных слабых мест в системе безопасности. Слабым местом в этом случае была бы возможность извлечения версии пароля пользователя в виде открытого текста для того, чтобы его можно было записать в другой каталог. Безопасные хранилища входных данных не хранят пароль в виде открытого текста, скорее они хранят хеш или зашифрованную версию пароля. Алгоритм хеширования не должен быть реверсивным. Так, чтобы у нас не было возможности прочитать из каталога значение хеша и конвертировать его в текст. А если мы просто перепишем хешированый пароль из одного каталога в другой, то второй каталог будет иметь «хеш»-значение пароля, которое не сможет быть воспроизведено в исходный пароль, и поэтому никогда не пройдет процесс аутентификации или «связывания» ( «bind» ).

Если каталог предусматривает доступ администратора или программы для получения пароля в виде открытого текста, это не является безопасным.

Источник

Что такое единый вход в Azure Active Directory?

В этой статье содержатся сведения о доступных параметрах единого входа (SSO), а также вводные сведения о планировании развертывания единого входа при использовании Azure Active Directory (Azure AD). Единый вход — это метод проверки подлинности, позволяющий пользователям входить в систему, используя один набор учетных данных для нескольких независимых систем программного обеспечения. При использовании единого входа пользователю не нужно входить в каждое используемое приложение. С помощью единого входа пользователи могут получить доступ ко всем необходимым приложениям без прохождения проверки подлинности с разными учетными данными. Краткое введение см. на странице Единый вход в Azure Active Directory.

В Azure AD уже существует множество приложений, для которых можно использовать единый вход. Существует несколько вариантов единого входа в зависимости от потребностей приложения и способа его реализации. Перед созданием приложений в Azure AD стоит уделить время планированию развертывания единого входа. Воспользовавшись порталом «Мои приложения», можно упростить управление приложениями.

Варианты реализации единого входа

Выбор способа единого входа зависит от того, как приложение настраивается для аутентификации. Облачные приложения могут использовать варианты на основе федерации, например OpenID Connect, OAuth и SAML. Приложение также может использовать единый вход на основе паролей, единый вход на основе ссылки или просто единый вход.

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

При использовании федеративного единого входа служба Azure AD выполняет аутентификацию пользователя в приложении, используя его учетную запись Azure Active Directory. Этот метод поддерживается для приложений SAML 2.0, WS-Federation и OpenID Connect. Федеративный единый вход — это наиболее функциональный режим единого входа. Вместо единого входа на основе пароля и службы федерации Active Directory (AD FS) используйте федеративный единый вход с Azure AD, если его поддерживает приложение.

Существует несколько сценариев, в которых для корпоративного приложения отсутствует параметр единого входа. Если приложение было зарегистрировано с использованием Регистрации приложений на портале, то для единого входа настроено использование OpenID Connect и OAuth (по умолчанию). В этом случае в области навигации в разделе «Корпоративные приложения» не будет параметра «Единый вход».

Единый вход недоступен, если приложение размещено в другом клиенте. Он также недоступен, если у вашей учетной записи нет необходимых разрешений (глобальный администратор, администратор облачных приложений, администратор приложений или владелец субъекта-службы). Кроме того, неподходящие разрешения могут стать причиной того, что, хоть и можно будет открыть настройки единого входа, но сохранить их не удастся.

Пароль. В локальных приложениях может использоваться метод единого входа на основе пароля. Этот вариант подходит, если для приложений настроено использование Application Proxy.

При использовании единого входа на основе пароля пользователям, чтобы войти в приложение, необходимо ввести имя пользователя и пароль при первом обращении к нему. После первого входа Azure AD предоставляет приложению имя пользователя и пароль. Единый вход на основе пароля позволяет безопасно хранить пароли приложений и воспроизводить их с помощью расширения веб-браузера или мобильного приложения. При этом варианте используется уже имеющийся процесс входа, предоставляемый приложением, однако администраторы имеют возможность управлять паролями, что избавляет пользователей от необходимости знать свой пароль. Дополнительные сведения см. в статье Добавление единого входа на основе пароля в приложение в Azure Active Directory.

Связанный. Единый вход на основе ссылки предоставляет согласованный пользовательский интерфейс при переносе приложений в течение определенного времени. Если вы переносите приложения в Azure AD, вы можете использовать единый вход на основе ссылки, чтобы быстро опубликовать ссылки на все приложения, которые планируется перенести. Пользователи могут найти ссылки на портале «Мои приложения» или Microsoft 365.

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

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

Единый вход следует отключать в следующих случаях:

Если вы настроили в приложении единый вход на основе SAML, инициированного поставщиком служб, а затем отключаете режим единого входа, это не помешает пользователям входить в приложение в обход портала «Мои приложения». Чтобы это предотвратить, нужно отключить возможность входа пользователей.

Планирование развертывания единого входа

Веб-приложения размещаются различными компаниями и предоставляются как услуга. Популярными примерами веб-приложений могут служить Microsoft 365, GitHub и Salesforce. Однако есть еще и тысячи других. Пользователи получают доступ к веб-приложениям через веб-браузер на своем компьютере. Единый вход дает им возможность перемещаться между различными веб-приложениями без многократного выполнения процедуры входа. Дополнительные сведения см. в статье Планирование развертывания единого входа.

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

Для облачных приложений используются протоколы федерации. Вы также можете использовать единый вход для локальных приложений. Вы можете использовать Application Proxy для настройки доступа к локальному приложению. Дополнительные сведения см. в разделе Удаленный доступ к локальным приложениям с помощью прокси приложения Azure AD.

Мои приложения

Если вы пользователь приложения, вас, скорее всего, не слишком интересуют сведения о едином входе. Вы просто хотите использовать приложения, обеспечивающие продуктивность работы без необходимости ввода пароля. Вы можете находить приложения и управлять ими на портале «Мои приложения». Дополнительные сведения см. в статье о входе на портал «Мои приложения» и запуске приложений на нем.

Источник

👨⚕️️ Что такое единый вход ( Single Sign-on или SSO)👨⚕️ – решение для обеспечения безопасности данных вашей компании

Single Sign-on или Единая регистрация – это метод аутентификации, который помогает войти в несколько приложений с использованием единой учетной записи.

Безопасность повышается за счет единого входа (SSO) в свете того факта, что пользователи избавляются от различных проблем с секретными паролями.

Давайте будем честными, пользователи не любят сложные пароли;

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

Есть две основные проблемы, с которыми сталкиваются эти предприятия:

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

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

Расширение стороннего доступа

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

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

В исследовании, проведенном Aberdeen, было показано, что около 1/3 исследованных предприятий предоставили доступ по крайней мере 25 сторонним организациям, в то время как у 10% было свыше 200 внешних партнеров.

В этом случае единый вход (SSO) будет очень полезным решением для защиты активов вашей компании.

Балансировка между безопасностью и удобством использования

При работе с растущей пользовательской базой безопасность и стоимость имеют первостепенное значение.

Если предприятие не готово к расширению, риск проблем с безопасностью выше.

Кража данных такого типа может иметь разрушительные последствия для компании.

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

Частота и стоимость кибератак

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

Одна утечка данных стоит в среднем около 450 тыс. долларов, но может стоить значительно дороже.

Немного подготовки может сэкономить много денег и доверия.

Традиционные системные расходы

Использование традиционной системы может быть дорогостоящим, около 3,5 миллионов долларов для производителей.

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

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

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

Уменьшите головную боль помощи пользователям с восстановлением пароля с помощью единого входа (SSO)

Представьте себе организацию с десятью различными администрациями.

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

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

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

Клиентам настоятельно рекомендуется использовать бесконечно уникальные пароли для разных систем.

Очевидно, что это не проблема, если клиент использует инструмент управления паролями, но как насчет того, насколько мы разумны, и на какое количество пользователей вы могли бы надеяться?

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

Источник