Sso

Веб-приложения создают с использованием клиент-серверной архитектуры, применяя в качестве коммуникационного протокола HTTP. HTTP это протокол без сохранения состояния. Каждый раз, когда браузер отправляет серверу запрос, сервер обрабатывает этот запрос независимо от других запросов и не связывает его с предыдущими или последующими запросами того же самого браузера. Это, кроме прочего, означает, что получить доступ к серверным ресурсам, которые никак не защищены, может кто угодно. Если нужно защитить от посторонних некие серверные ресурсы, это значит, что нужно как-то ограничить то, что может запрашивать у сервера браузер. То есть нужно аутентифицировать запросы и отвечать только на те из них, которые прошли проверку, игнорируя те, которые проверку не прошли. Для аутентификации запросов нужно владеть некими сведениями о запросах, хранящимися на стороне браузера. Так как протокол HTTP не хранит состояние запросов, нам для этого нужны некие дополнительные механизмы, которые позволяют серверу и браузеру совместно управлять состоянием соединений. Среди таких механизмов можно отметить использование куки-файлов, сессий, JWT.



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

Есть одно хорошее правило, касающееся систем, сложность которых со временем растёт, и взаимодействия этих систем с их пользователями. А именно, нагрузка по решению задач, связанных с усложнением архитектуры проекта, ложится на систему, а не на её пользователей. При этом неважно то, насколько сложны внутренние механизмы веб-проекта. Для пользователя он должен выглядеть единой системой. Иными словами, пользователь, работающий с веб-системой, состоящей из множества компонентов, должен воспринимать происходящее так, будто он работает с одной системой. В частности, речь идёт об аутентификации в таких системах с использованием SSO (Single Sign-On) технологии единого входа.

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

В современных условиях таким решениям препятствует широкое распространение микросервисных архитектур. Управление сессиями усложнилось в тот момент, когда при разработке веб-проектов стали использовать различные технологии, и когда разные службы иногда размещались на разных доменах. Кроме того, веб-службы, которые раньше писали на Java, начали писать, пользуясь возможностями платформы Node.js. Это усложнило работу с куки-файлами. Оказалось, что сессиями теперь управлять не так уж и просто.

Эти сложности привели к разработке новых методов входа в системы, в частности, речь идёт о технологии единого входа.

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

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

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

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

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

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

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

Шаг 1

Пользователь пытается получить доступ к защищённому ресурсу системы (назовём этот ресурс потребителем SSO, sso-consumer). Потребитель SSO выясняет то, что пользователь не вошёл в систему, и перенаправляет пользователя на сервер SSO (sso-server), используя, в качестве параметра запроса, собственный адрес. На этот адрес будет перенаправлен пользователь, успешно прошедший проверку. Этот механизм представлен ПО промежуточного слоя для Express:

const isAuthenticated = (req, res, next) => {// простая проверка того, аутентифицирован ли пользователь,// если это не так - нужно перенаправить пользователя на SSO-сервер для входа в систему и// передать серверу текущий URL как URL, на который должен быть перенаправлен// пользователь, успешно прошедший проверкуconst redirectURL = `${req.protocol}://${req.headers.host}${req.path}`;if (req.session.user == null) {return res.redirect(`http://sso.ankuranand.com:3010/simplesso/login?serviceURL=${redirectURL}`);}next();};module.exports = isAuthenticated;

Шаг 2

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

const login = (req, res, next) => {// В req.query будет url, на который надо будет перенаправить пользователя//после успешного входа в систему, туда же надо передать sso-токен.// Эти данные о перенаправлении пользователя ещё можно использовать// для проверки источника поступления запросаconst { serviceURL } = req.query;// Попытка прямого доступа приведёт к ошибке в новом URL.if (serviceURL != null) {const url = new URL(serviceURL);if (alloweOrigin[url.origin] !== true) {return res.status(400).json({ message: "Your are not allowed to access the sso-server" });}}if (req.session.user != null && serviceURL == null) {return res.redirect("/");}// если сведения о пользователе уже имеются в глобальной сессии - перенаправить// пользователя с токеномif (req.session.user != null && serviceURL != null) {const url = new URL(serviceURL);const intrmid = encodedId();storeApplicationInCache(url.origin, req.session.user, intrmid);return res.redirect(`${serviceURL}?ssoToken=${intrmid}`);}return res.render("login", {title: "SSO-Server | Login"});};

Сделаю тут некоторые комментарии относительно безопасности.

Мы проверяем serviceURL, поступающий в виде параметра запроса к SSO-серверу. Благодаря этому мы узнаём о том, зарегистрирован ли этот URL в системе, и о том, может ли представленная им служба пользоваться услугами SSO-сервера.

Вот как может выглядеть список URL служб, которым разрешено использование SSO-сервера:

const alloweOrigin = {"http://consumer.ankuranand.in:3020": true,"http://consumertwo.ankuranand.in:3030": true,"http://test.tangledvibes.com:3080": true,"http://blog.tangledvibes.com:3080": fasle,};

Шаг 3

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


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

Шаг 4

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

Шаг 5

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

const doLogin = (req, res, next) => {// Выполнить проверку с использованием адреса электронной почты и пароля.// Тут мы не вдаёмся в подробности использования хранилищ данных, поэтому// userDB - это обычный объект, описанный тут же, в коде сервераconst { email, password } = req.body;if (!(userDB[email] && password === userDB[email].password)) {return res.status(404).json({ message: "Invalid email and password" });}// В противном случае выполнить перенаправлениеconst { serviceURL } = req.query;const id = encodedId();req.session.user = id;sessionUser[id] = email;if (serviceURL == null) {return res.redirect("/");}const url = new URL(serviceURL);const intrmid = encodedId();storeApplicationInCache(url.origin, id, intrmid);return res.redirect(`${serviceURL}?ssoToken=${intrmid}`);};

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

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

Шаг 6

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

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

const ssoRedirect = () => {return async function(req, res, next) {// проверяется, есть ли в req queryParameter, представляющий ssoToken,// и то, что именно является реферером.const { ssoToken } = req.query;if (ssoToken != null) {// для удаления ssoToken в параметре запроса, задающем перенаправление.const redirectURL = url.parse(req.url).pathname;try {const response = await axios.get(`${ssoServerJWTURL}?ssoToken=${ssoToken}`,{headers: {Authorization: "Bearer l1Q7zkOL59cRqWBkQ12ZiGVW2DBL"}});const { token } = response.data;const decoded = await verifyJwtToken(token);// теперь у нас есть декодированный jwt, поэтому используем// global-session-id как id сессии, что позволит// реализовать процедуру выхода из системы с использованием глобальной сессии.req.session.user = decoded;} catch (err) {return next(err);}return res.redirect(`${redirectURL}`);}return next();};};

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

В нашем случае сервер SSO, после успешной проверки токена, возвращает подписанный JWT с информацией о пользователе.

const verifySsoToken = async (req, res, next) => {const appToken = appTokenFromRequest(req);const { ssoToken } = req.query;// Если нет токена приложения или запрос на ssoToken недействителен.// Усли ssoToken отсутствует в кеше - значит, нас пытаются обмануть.if (appToken == null ||ssoToken == null ||intrmTokenCache[ssoToken] == null) {return res.status(400).json({ message: "badRequest" });}// Если appToken присутствует - проверяем его действительность для приложенияconst appName = intrmTokenCache[ssoToken][1];const globalSessionToken = intrmTokenCache[ssoToken][0];// Если appToken не соответствует токену, выданному выданному SSO-приложению при регистрации или на более поздней стадии работыif (appToken !== appTokenDB[appName] ||sessionApp[globalSessionToken][appName] !== true) {return res.status(403).json({ message: "Unauthorized" });}// проверяем, был ли сгенерирован переданный токенconst payload = generatePayload(ssoToken);const token = await genJwtToken(payload);// удаляем из кеша ключ, который больше использоваться не будетdelete intrmTokenCache[ssoToken];return res.status(200).json({ token });};

Вот некоторые замечания о безопасности.

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

Кроме того, можно определить политику безопасности уровня приложения и организовать её централизованное хранение:

const userDB = {"info@ankuranand.com": {password: "test",userId: encodedId(), // в том случае, если вы не хотите передавать адрес электронной почты пользователя.appPolicy: {sso_consumer: { role: "admin", shareEmail: true },simple_sso_consumer: { role: "user", shareEmail: false }}}};

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


Установка локальной и глобальной сессий

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

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

Потребитель SSO

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

Сервер SSO

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

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

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

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

Итоги

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

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

Технология единого входа обладает массой преимуществ по сравнению с классическими методами аутентификации, главное из которых заключается в том, что именно SSO обеспечивает наилучший баланс между удобством пользователя и информационной безопасностью предприятия. Ранее мы уже рассказывали о том, как реализовать SSO в Zimbra OSE при использовании аутентификации в Active Directory с помощью Kerberos. На этот раз мы расскажем о том, как внедрить Zimbra OSE другую технологию единого входа SAML на примере провайдера Okta.



Единый вход с помощью SAML в Zimbra OSE доступен только для пользователей Zextras Suite Pro.

Подготовка к интеграции

В первую очередь для включения интеграции в SAML, необходимо пропатчить NGINX. Для этого в папке /opt/zimbra/conf/nginx/templates/ отредактируйте поочередно файлы:

• nginx.conf.web.http.default.template
• nginx.conf.web.http.template
• nginx.conf.web.https.default.template
• nginx.conf.web.https.template

Во всех файлах в разделе location ^~ /zx/ замените содержимое на

location ^~ /zx/

{

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Host $http_host;

proxy_set_header X-Forwarded-Proto $scheme;

proxy_set_header X-Forwarded-Port $server_port;

proxy_pass ${web.upstream.zx};

}

Эти изменения нужны для того, чтобы составлять полноценные URL-запросы Protocol X и X-Port.

Также необходимо активировать движок аутентификации от Zextras на уровне домена. Сделать это может администратор сервера, введя в командной строке команду zmprov modifyDomain example.ru zimbraAuthMech custom:zx.

Создание приложения в Okta

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

1. Зарегистрируйтесь в качестве разработчика на сайте okta.com

2. В личном кабинете нажмите на кнопку Create App Integration



3. В открывшемся списке выберите SAML 2.0 и нажмите Next



4. В следующем окне укажите название своего приложения, выберите иконку и настройте его видимость и нажмите кнопку Next, когда всё будет готово



5. В следующем окне:

1. В качестве SSO URL укажите адрес вашего сервера с аппендиксом /zx/auth/saml
2. В качестве Audiend URI укажите адрес вашего сервера с аппендиксом /zx/auth/samlMetadata
3. В качестве Name ID Format укажите EmailAddress
4. Нажмите кнопку Next

6. В мини-опросе выберите первый вариант ответа и нажмите кнопку Finish



7. Скачайте метаданные своего приложения SAML



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

Экспорт учетных записей из домена Zimbra OSE

Приложение SAML поддерживает как создание новых учетных записей, так и импортирование уже существующих из Zimbra. Для того, чтобы импортировать учетные записи, необходимо сперва экспортировать их из Zimbra в формате .csv.

Для экспорта учетных записей перейдите в консоль администратора Zimbra, перейдите во вкладку Поиск и осуществите поиск по пользователям с названием домена в поисковом запросе. Результатом поиска будет полный список пользователей домена, который можно выгрузить в формате CSV, нажав на иконку Дополнительные настройки в правом верхнем углу и выбрав раздел Загрузить



Импортируйте полученный CSV в приложение SAML с помощью соответствующего инструмента в личном кабинете разработчика.

Интеграция приложения в Zimbra OSE

Чтобы интегрировать приложение SAML в Zimbra OSE, вам потребуются данные из скачанного ранее файла с метаданными приложения.

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

Для того, чтобы выполнить интеграцию в автоматическом режиме, введите команду zxsuite auth saml import example.ru url dev-3299935.okta.com/app/exkvjcggn7C7jrhc75d6/sso/saml/metadata. Если вы используете собственный сервер SAML с самоподписанными сертификатами, используйте параметр allow_insecure true для пропуска проверки подлинности SSL-сертификата.

Чтобы провести интеграцию в ручном режиме, экспортируйте настройки SAML по умолчанию при помощью команды zxsuite auth saml get example.ru export_to /tmp/saml.json. Откройте полученный файл /tmp/saml.json в любом редакторе и добавьте в него следующие данные, заменяя строки отмеченные знаками >> << данными из файла с метаданными. В нашем случае добавленные строки будут выглядеть следующим образом:

sp.nameidformat:urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress ,
sp.entityid: >>example.ru/zx/auth/samlMetadata?domain=example.ru<<,
sp.assertion_consumer_service.url: >>example.ru/zx/auth/saml<<,
idp.single_sign_on_service.url: >>dev-3299935.okta.com/app/dev-3299935_zextrassamlintegration_1/exkvjcggn7C7jrhc75d6/sso/saml<<,
idp.entityid: >>www.okta.com/exkvjcggn7C7jrhc75d6<<,
idp.x509cert: >>MIIDpjCCAo6gAwIBAgIGAXmC9e8bMA0GCSqGSIb3DQEBCwUAMIGTMQswCQYDVQQGEwJVUzETMBEG A1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNU2FuIEZyYW5jaXNjbzENMAsGA1UECgwET2t0YTEU MBIGA1UECwwLU1NPUHJvdmlkZXIxFDASBgNVBAMMC2Rldi0zMjk5OTM1MRwwGgYJKoZIhvcNAQkB Fg1pbmZvQG9rdGEuY29tMB4XDTIxMDUxOTA0NDkyNloXDTMxMDUxOTA0NTAyNlowgZMxCzAJBgNV BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1TYW4gRnJhbmNpc2NvMQ0wCwYD VQQKDARPa3RhMRQwEgYDVQQLDAtTU09Qcm92aWRlcjEUMBIGA1UEAwwLZGV2LTMyOTk5MzUxHDAa BgkqhkiG9w0BCQEWDWluZm9Ab2t0YS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCOJA7bhf/LO89VpuGTHur77RbwKlJg3Eni/P4JKowSVrQD6PghwprCdzThyTsKWcHwESZoYwEL WdrZ6CVzDZWAegWJnaJivfiFlFjsEZ15UHOGizMBM3VI0ePWjaWJ6O2DM9BID2mGULnXUDbQXbf6 rE1EHxzlxzCKIBWmT8ut/JsA/lmBm0YNi4BKfP06KXCLianxoH+fEETNd/NH2mXwgHdxMV1BS/mm TAHSJtkDfWxTM+dTGngrjMANKvmChGjSO1ZXFs/pm+vx0o6ffYcoeXnfgodBX3FZ7aTFBTk0s5Se Wms1utjfa8qhHbrolErqqIc1PPBngEFvzcLjFAfRAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAByU jjdAc5tdH+QFAHS0CJNYa9VNaapxuEFrlR3ZdAztIaczKUqYfHqHdXuDHYCjdHXhLFHwntBsnphk M2sk8D2zG0wpoYsEA3IrvbXoTwwqDzACpLF37S7Pfn0RjE5IvvJ9WP4DoZa9ikM/p0N+H7fpqkU2 xavoiNGOMqot9xpWrytM0P+luXereriOOzVaBS1+DuhA4INhze5luyc52X18T4HrJ3iGivfXR2os L8/PI4gZwR956Ju8tDEcmFVCelLN4FlN3ITogPK+SyKHhlTBuSGHidrGKQJBRmkLhk6lhKWTHjWP mI88ECqrA63+QvxU4KRUl1zzRgKVwrgzos4=<<

Сохраните внесенные в файл изменения и импортируйте его в Zimbra OSE с помощью команды zxsuite auth saml import example.ru /tmp/saml.json



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

По всем вопросам, связанными c Zextras Suite Pro и Team Pro вы можете обратиться к Представителю компании Zextras Technology Екатерине Триандафилиди по электронной почте ekaterina.triandafilidi@zextras.com

Что такое 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 Access 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.

В начале 2019 года мы провели ребрендинг и поменяли название с RealtimeBoard на Miro. Следовательно, изменился домен сайта с realtimeboard.com на miro.com.

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

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

• Поддержать пользователей, которые выполняли авторизацию с помощью SSO провайдеров через старый домен.
• Передать токен авторизации пользователя со старого домена на новый.
• Передать LocalStorage с пользовательскими настройками приложения.

Передача данных и шифрование

Передавать токен было решено с помощью get-параметров, так как сайт не использовал хранилищ, в которых можно было бы сохранить токен и переиспользовать его. Передавать токен в открытую через get-параметр небезопасно, его необходимо защитить от перехвата. У нас было два способа шифрования: OpenSSL и Mcrypt. Mcrypt давно не обновлялся, медленнее шифрует данные по сравнению с OpenSSL, а лишняя нагрузка на сервер нам не нужна. Поэтому мы шифровали токен с помощью OpenSSL.

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

Получившийся хэш передавался в виде get-параметра и был дополнительно обработан с помощью url_encode для безопасной передачи через URL, так как символы могли экранироваться или испортить структуру адреса.

Структура хэша:

url_encode(OpenSSL({  'token': 'токен',  'date': 'Дата шифрования',  'additional_values': ['param', 'param']}))

LocalStorage доступен только через JavaScript. Для решения этой задачи был выбран интерфейс postMessage и iframe, что позволяло безопасно отправлять кроссдоменные запросы. Данные в LocalStorage были сконвертированы в строки с помощью JSON.stringify() и переданы на домен miro.com, где они конвертировались обратно и записывались в LocalStorage домена miro.com.

Схема работы с описанием всех шагов

Схема в удобном для просмотра виде.

Пользователи могли попасть в сервис двумя путями: через старый домен realtimeboard.com (например, из закладок) или через новый miro.com (например, через рекламу).

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

1. После открытия любой страницы realtimeboard.com выполняется шифрование токена пользователя, даты создания и дополнительной служебной информации.
2. После шифрования происходит редирект на miro.com/migration/?data={hash} с передачей hash как Get параметр. Сам токен и служебная информация удаляются на старом домене, т.к они больше были не нужны.
3. На новом домене miro.com выполняется расшифровка хэша, проверка на то, что он не просрочен, и установка токена пользователя, если он был передан.
4. Проставляется флаг migrationToken, чтобы не выполнять миграцию снова.
5. Для миграции LocalStorage мы проверяли наличие куки migrationLocalstorage. Если куки не существовало, выполнялся рендеринг страницы с JS-скриптом, который открывал в iFrame страницу relatimeboard.com/localstorage/ и принимал сообщения от неё с помощью postmessage После окончания миграции пользователя редиректило на страницу, которую он пытался открыть первый раз.

Если пользователь заходил сразу на новый домен miro.com, выполнялась проверка на прохождение пользователем миграции токена и LocalStorage. Если пользователь уже выполнил миграцию, то он оставался на домене miro.com. Если не выполнил происходил редирект на realtimeboard.com для получения токена (для этого мы хранили в куках два флага: migrationToken и migrationLocalstorage).

Эта схема так же хорошо работала для пользователей с SSO, которые выполнили авторизацию на старом домене realtimeboard.com. Был добавлен список маршрутов, которые работали без миграции токена на новый домен. В них входил маршрут для SSO, который выполнялся как обычно и выполнял редирект на /app/ или /login/ в зависимости от состояния своей работы, после чего снова подключался механизм миграции токена.

Вывод

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