Windows SSO | Справка Firefox

# jwt токен

Токен состоит из трех частей, разделенных точкой (.):

1. Заголовок
2. Полезные данные
3. Подпись

# включение sso

1. Перейти в раздел Настройки компании -> Омнибокс -> Аутентификация.
2. Разрешить запрашивать аутентификацию при написании отзыва.
3. Выбрать способ аутентификации Single Sign-On (SSO).
4. Заполнить секретный ключ для подписи JWT токена.

# заголовок

Заголовок состоит из двух полей: тип токена и алгоритм формирования подписи:

# подпись

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

Пример формирования токена (псевдокод):

Секретный код (YOUR SECRET CODE) указывается в личном кабинете.

# полезные данные

Полезные данные содержат обязательные и необязательные поля.

1. Обязателен email или phone. Можно передать и то и другое.

Пример:

# регистрация js-обработчика

Обработчик — функция без аргументов, возвращающая Promise (then-able object).

▍потребитель sso

1. Подсистема-потребитель SSO не выполняет аутентификацию пользователя, перенаправляя пользователя на сервер SSO.
2. Эта подсистема получает токен, передаваемый ей сервером SSO.
3. Она взаимодействует с сервером, проверяя действительность токена.
4. Она получает JWT и проверяет этот токен с использованием публичного ключа.
5. Эта подсистема устанавливает локальную сессию.

▍сервер sso

1. Сервер SSO проверяет данные, вводимые пользователем для входа в систему.
2. Сервер создаёт глобальную сессию.
3. Он создаёт токен авторизации.
4. Токен авторизации отправляется потребителю SSO.
5. Сервер проверяет действительность токенов, передаваемых ему потребителями SSO.
6. Сервер отправляет потребителю SSO JWT с информацией о пользователе.

Windows sso | справка firefox

Авторизация по куки

1. Пользователь заходит на сайт. Проверяем если ли кука, если есть поднимаем сессию, если нет, то идем дальше.

2. Делаем редирект на сервер авторизации с шифрованным адресом возврата.

3. Сервер авторизации проверяет есть ли кука.

4. Если есть то шифруем токен с ид сессии и временем жизни токена если нет то флаг что куки нету.

5. Делаем редирект обратно с полученным параметром.

6. Расшифровываем токен и ставим куку.

7. Делаем редирект сами на себя чтобы очистить урл в адресной строке.

Алгоритм sso в manageengine servicedesk

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

ServiceDesk Plus внедрил безопасный канал в Active Directory, используя службу NETLOGON через учетную запись компьютера. Для включения службы NetLogon эта учетная запись компьютера требует пароль. Сервис NetLogon является внутренним каналом связи Microsoft.

Один компьютер создаст уникальный идентификатор в домене и создаст некоторый случайный пароль для дальнейшей связи в домене. Например, когда пользователь пытается войти в систему, компьютер выдаст свою идентификационную информацию AD, а затем попытается аутентифицировать пользователя.

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

ServiceDesk Plus использует VBScript для создания учетной записи компьютера и установки пароля для них. Начиная с версии 7600, ServiceDesk Plus для сквозной аутентификации использует метод NTMLV2, который обеспечивает лучшую безопасность и проверяет учетные данные с помощью сервиса NETLOGON, и NTLMV1 больше не будет поддерживаться.

Показывать настройку сквозной авторизации я буду на ManageEngine ServiceDesk 10016, которую я недавно обновил. Открываем веб интерфейс ManageEngine ServiceDesk, находим раздел “Параметры – Active Directory”.

Находим раздел “Проверка подлинности Active Directory” и активируем функцию “Включить сквозную авторизацию (единый вход)”.

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

Чтобы использовать поставщик безопасности NTLM в качестве службы проверки подлинности, необходимо создать учетную запись компьютера в Active Directory с определенным паролем, который соответствует политике паролей в Active Directory.

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

Если вы указываете имя существующей учетной записи компьютера, указанный здесь пароль также будет установлен в Active Directory для этой учетной записи компьютера. Вы также можете сбросить пароль учетной записи компьютера, нажав на ссылку «Сбросить пароль».

Даже если при создании учетной записи компьютера или сброса пароля (уже созданной учетной записи компьютера) из приложения возникнет ошибка, сведения, указанные в окне, будут сохранены в базе данных приложения. Загрузите сценарии и сохраните сценарии NewComputerAccount.vbs и SetComputerpass.vbs. Оба сценария нам пригодятся.

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (
access key, API key

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный
certificate authority
(CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

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

1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

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

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

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем
Single Sign-On
(SSO), где одно приложение (
service provider
или
relying party
) делегирует функцию аутентификации пользователей другому приложению (
identity provider
или
authentication service
). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение
доверяет
функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.На общем уровне, весь процесс выглядит следующим образом:

1. Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
2. Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
3. Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

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

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

1. Токен был выдан доверенным identity provider приложением (проверка поля issuer).
2. Токен предназначается текущему SP-приложению (проверка поля audience).
3. Срок действия токена еще не истек (проверка поля expiration date).
4. Токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Вариант 2

Особенности этого варианта, что не нужен сервер авторизации и не страшны роботы, а также работает с отключенным JavaScript. Хотя решение честно говоря не самое красивое.

Включаем kerberos аутентификацию в google chrome

Google Chrome берет все настройки SSO из Internet Explorer, так что настройте его и еще выполните вот такую команду. Кроме того, нужно отметить, что все новые версии Chrome автоматически определяют наличие поддержки Kerberos. В том случае, если используется одна из старых версий Chrome (Chromium), для корректной авторизации на веб-серверах с помощью Kerberos, его нужно запустить с параметрами:

Например, “C:Program Files (x86)GoogleChromeApplicationchrome.exe” –auth-server-whitelist=”*.vhod-v-lichnyj-kabinet.ru” –auth-negotiate-delegate-whitelist=”*.vhod-v-lichnyj-kabinet.ru”. Сделать это можно из командной строки.

На этом у меня все. Мы с вами подробно разобрали настройку сквозной авторизации (единого входа) в ManageEngine ServiceDesk 10016. С вами был Иван Семин, автор и создатель IT портала vhod-v-lichnyj-kabinet.ru.

Выход

1. Удаляем куку и шифруем урл возврата.

2. Делаем редирект на сервер авторизаци с урлом возврата и удаляем сессию и куку.

Запуск сценариев на сервере active directory

Скопируйте в корень диска C: оба сценария, NewComputerAccount.vbs и SetComputerpass.vbs.

На контроллере домена, куда вы скопировали ваши скрипты, откройте командную строку от имени администратора. Перейдите в командной строке в корень диска C:, через команду cd C:. Если нужно создать новый компьютер, то введите:

Если нужно сменить пароль, то конструкция будет такой

Так же я вас советую включить логирование на вашем сервере ManageEngine ServiceDesk, поставив соответствующую галку в SSO. Логи будут лежать в C:ManageEngineServiceDesklogssso.txt

Как организован вход в систему с использованием sso?

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

Вот репозиторий с кодом проекта simple-sso, реализацию которого я здесь опишу. Я использую платформу Node.js, но вы можете реализовать то же самое и используя что-то другое. Давайте пошагово разберём действия пользователя, работающего с системой, и механизмы, из которых состоит эта система

Краткий обзор потребителя sso и сервера sso

Давайте сделаем краткий обзор функционала потребителя SSO и сервера SSO.

Настройка google chrome

Запустить с параметрами командной строки
–auth-server-whitelist=”*.domain.name” –auto-negotiate-delegate-whitelist=”*.domain.name”

Настройка internet explorer

Настройки IE лучше применять средствами GPO AD Windows.

Настройка kerberos аутентификации в internet explorer

Рассмотрим, как включить Kerberos аутентификацию в Internet Explorer 11.

Напомним, что с января 2022 года, единственная официально поддерживаемая версия Internet Explorer – это IE 11.

Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:

Далее перейдите на вкладку Дополнительно (Advanced) и в разделе Безопасность (Security) убедитесь, что включена опция Разрешить встроенную проверку подлинности Windows (Enable Integrated Windows Authentication).

Важно. Убедитесь, что веб сайты, для которых включена поддержка Kerberos аутентификации приустают только в зоне Местная интрасеть. Для сайтов, включенных в зону Надежные сайты (Trusted sites), токен Kerberos не отправляется на соответствующий веб-сервер.

Настройка kerberos аутентификации в mozilla firefox

По умолчанию поддержка Kerberos в Firefox отключена, чтобы включить ее, откройте окно конфигурации браузера (в адресной строке перейдите на адрес about:config). Затем в следующих параметрах укажите адреса веб-серверов, для которых должна использоваться Kerberos аутентификация.

• network.negotiate-auth.trusted-uris
• network.automatic-ntlm-auth.trusted-uris

Для удобства, можно отключить обязательное указание FQDN адреса в адресной строке Mozilla Firefox, включив параметр network.negotiate-auth.allow-non-fqdn

Проверить, что ваш браузер работает через аутентифицировался на сервере с помощью Kerberos можно с помощью Fiddler или команды klist tickets.

Настройка mozilla firefox

1. Перейти в about:config.
2. Найти строки “network.negotiate-auth.delegation-uris” и “network.negotiate-auth.trusted-uris”
   и прописать там наш домен в формате .domain.name (например, .bazalt.team).

Настройка контроллера ecp veil

Включение доменной авторизации в ECP VeiL производится в окне Настройки – Службы каталогов основного меню интерфейса управления ECP VeiL.
При нажатии кнопки Добавить в верхней части интерфейса откроется окно, в котором необходимо заполнить поля:

• Название службы каталогов – произвольное имя, по которому пользователь будет идентифицировать службу каталогов в интерфейсе ECP VeiL.

• Имя домена – указать имя домена Windows AD (в примере выше – bazalt.team).

• Тип подключения – выбрать протокол подключения LDAP или LDAPS. В поле ниже – указать FQDN или IP сервера Windows AD.

• Тип службы каталогов – выбрать Active Directory.
  Для проверки соединения можно нажать кнопку Проверить соединение.

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

Организация централизованного выхода из системы

Аналогично тому, как была реализована технология единого входа, можно реализовать и «технологию единого выхода». Здесь нужно лишь учитывать следующие соображения:

1. Если существует локальная сессия — обязательно существует и глобальная сессия.
2. Если существует глобальная сессия, это необязательно означает существование локальной сессии.
3. Если локальная сессия уничтожается — должна быть уничтожена и глобальная сессия.

Подготовка windows сервера

Необходимо выполнить:

Стандарт saml

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Стандарты oauth и openid connect

В отличие от SAML и WS-Federation, стандарт OAuth (Open Authorization) не описывает протокол аутентификации пользователя. Вместо этого он определяет механизм получения доступа одного приложения к другому от имени пользователя. Однако существуют схемы, позволяющие осуществить аутентификацию пользователя на базе этого стандарта (об этом — ниже).

Первая версия стандарта разрабатывалась в 2007 – 2022 гг., а текущая версия 2.0 опубликована в 2022 г. Версия 2.0 значительно расширяет и в то же время упрощает стандарт, но обратно несовместима с версией 1.0. Сейчас OAuth 2.0 очень популярен и используется повсеместно для предоставления делегированного доступа и третье-сторонней аутентификации пользователей.

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

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

Как раз эту проблему и позволяет решить стандарт OAuth: он описывает, как приложение путешествий (client) может получить доступ к почте пользователя (resource server) с разрешения пользователя (resource owner). В общем виде весь процесс состоит из нескольких шагов:

1. Пользователь (resource owner) дает разрешение приложению (client) на доступ к определенному ресурсу в виде гранта. Что такое грант, рассмотрим чуть ниже.
2. Приложение обращается к серверу авторизации и получает токен доступа к ресурсу в обмен на свой грант. В нашем примере сервер авторизации — Google. При вызове приложение дополнительно аутентифицируется при помощи ключа доступа, выданным ему при предварительной регистрации.
3. Приложение использует этот токен для получения требуемых данных от сервера ресурсов (в нашем случае — сервис Gmail).

Взаимодействие компонентов в стандарте OAuth.

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

Стандарты ws-trust и ws-federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Технология единого входа

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

Мы, в учебных целях, собираемся реализовать технологию SSO на платформе Node.js.

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

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Шаг 1

Пользователь пытается получить доступ к защищённому ресурсу системы (назовём этот ресурс «потребителем SSO», «sso-consumer»). Потребитель SSO выясняет то, что пользователь не вошёл в систему, и перенаправляет пользователя на «сервер SSO» («sso-server»), используя, в качестве параметра запроса, собственный адрес.

Шаг 2

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

Шаг 3

Пользователь вводит имя пользователя и пароль, которые отправляются SSO-серверу в запросе на вход в систему.

Страница входа в систему

Шаг 4

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

Шаг 5

SSO-сервер берёт токен авторизации и передаёт его туда, откуда к нему пришёл только что авторизовавшийся пользователь (то есть — передаёт токен потребителю SSO).

Шаг 6

Потребитель SSO получает токен и обращается к серверу SSO для проверки токена. Сервер проверяет токен и возвращает ещё один токен с информацией о пользователе. Этот токен используется потребителем SSO для создания сессии с пользователем. Эта сессия называется локальной.

Вот код ПО промежуточного слоя, используемого в потребителе SSO, построенном на основе Express:

Заключение

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

Итоги

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

Используются ли в ваших проектах механизмы SSO?