Содержание статьи
Постановка задачи
Сперва определимся, что нам нужно для полного счастья, а затем попробуем подобрать решение. В идеале у него должны быть:
- поддержка технологии единого входа (Single Sign-On);
- настраиваемые сервисы регистрации, личного кабинета и восстановления доступа;
- двухфакторная аутентификация;
- подключение внешних систем идентификации;
- контроль доступа;
- настройка внешнего вида.
Сервер аутентификации должен упростить доступ к приложениям, разрешив использовать существующую запись социальной сети. Пользователю не нужно регистрироваться на твоих сайтах, он может зайти через свою учетную запись в Facebook, Google и других социальных сетях. Это удобно и для тебя, и для пользователя.
Также сервер аутентификации должен позволять использовать себя в качестве поставщика идентификации для приложений и сайтов сторонних организаций. Было бы хорошо построить сеть доверия нескольких организаций и структурных подразделений и обеспечить совместное использование приложений.
Поддержка различных способов аутентификации (обычная аутентификация по паролю, двухфакторная аутентификация, смарт-карты, ключи электронной подписи) — это прямая обязанность сервера. Думаю, об этом даже не стоит и говорить. Наш будущий сервер должен контролировать доступ пользователей к приложениям в соответствии с политикой безопасности твоей организации, позволяя администраторам гибко задавать правила доступа.
Когда идет речь об организации доступа к приложениям, нужно решить множество дополнительных задач. Некоторые из этих задач выполняют сами пользователи. Так, они вводят данные о себе при регистрации, настраивают способы подтверждения входа, изменяют свои пароли, восстанавливают доступ к своей учетной записи. Сервер аутентификации должен содержать сервисы самообслуживания: регистрации, восстановления доступа, личный кабинет — все это должно быть гибко настроено под твои задачи.
Сервер должен быть хорошо масштабируемым, выдерживать большие нагрузки и обладать приемлемым уровнем производительности. Вход по учетной записи социальной сети — это хорошо, но, если аутентификация будет проходить мучительно больно, твоим пользователям это не понравится.
INFO
На тестовом стенде начального уровня ПО Blitz Identity Provider устойчиво функционирует при нагрузке 1700 запросов в секунду, обеспечивая среднее время отклика одной операции в 70 мс (95% запросов имели отклик менее 200 мс). На протяжении 8-часового тестового цикла не было зафиксировано ни одного неуспешного запроса.
Немаловажен и дизайн — пользовательские страницы должны выглядеть привлекательно, а у администратора должна быть возможность легко изменить тему оформления и редактировать ее.
Как видишь, требований достаточно много, но, к счастью, подходящее решение есть — Blitz Identity Provider от РЕАК СОФТ.
Досье
РЕАК СОФТ известны как команда программистов, разработавших Единую систему идентификации и аутентификации (ЕСИА) сайта gosuslugi.ru. Сейчас в этой системе зарегистрировано более 40 миллионов аккаунтов. Возможно, там есть и ты, наш читатель, и, возможно, ты использовал эту систему для доступа к каким-либо из более 1000 подключенных к ЕСИА сайтов.
Основные возможности Blitz Identity Provider
Сервер аутентификации Blitz Identity Provider эффективно решает задачу защиты пользовательских учетных записей. Также он предоставляет готовые (и при этом гибко настраиваемые под заказчика) функции защиты учетных записей:
- обеспечение единого сквозного входа пользователя в приложения (Single Sign-On);
- двухфакторную аутентификацию с использованием различных методов;
- конфигурируемый пользовательский интерфейс страниц входа, регистрации, восстановления доступа, управления учетной записью;
- вход с использованием сторонних поставщиков идентификации: вход с помощью аккаунтов социальных сетей (Social Login), идентификация с использованием государственной Единой системы идентификации и аутентификации (ЕСИА, госуслуги), федеративный вход пользователей с использованием установок Blitz Identity Provider у организаций-партнеров или в филиалах организации;
- авторизацию входа в приложения в соответствии с настроенными правилами доступа различных групп пользователей к разным приложениям с требуемым уровнем аутентификации;
- протоколирование событий безопасности, связанных с использованием учетных записей пользователей;
- защиту RESTful-веб-сервисов, обеспечение авторизации при вызове сервисов различными клиентами с делегированными пользователями разрешениями на доступ от их имени.
Данный продукт идеально подходит для решения нескольких задач: обеспечить пользователям доступ к интернет-сервисам компании и контролировать доступ сотрудников к ресурсам своей организации. Также Blitz Identity Provider можно использовать в качестве интеграционной платформы для подключения приложений организации и ее филиалов к LDAP и серверам Microsoft Active Directory.
Как работает Blitz Identity Provider
Типичная схема развертывания Blitz Identity Provider изображена на рис. 1. Разберемся, что есть что. Как видишь, есть приложения и есть сервер аутентификации, к которому обращаются пользователи для получения доступа к приложениям. Сервер аутентификации обеспечивает все основные функции: саму аутентификацию, сервисы самообслуживания (регистрация, личный кабинет, восстановление доступа), а также предоставляет консоль управления. Опционально могут быть использованы хранилище учетных записей, SMTP-сервер и SMS-шлюз.
В качестве хранилища можно взять существующее хранилище на основе LDAP или Microsoft Active Directory либо иную систему хранения учетных записей и паролей (в этом случае потребуется разработка REST-сервисов, обеспечивающих возможность интеграции Blitz Identity Provider и хранилища учетных записей).
Консоль управления
В разделе «Приложения» консоли управления настраиваются твои приложения, которым нужна аутентификация (рис. 2). На рис. 3 показан пример конфигурации одного из приложений с помощью протокола SAML — нужно ли шифровать и подписывать идентификаторы и утверждения, какие атрибуты пользователя должны использоваться и так далее.
Раздел «Хранилище» позволяет добавить новое хранилище. Сейчас сконфигурировано два хранилища — встроенное и LDAP (рис. 4). Сконфигурировать доступные методы аутентификации можно в разделе «Аутентификация». Ненастроенные методы отмечаются желтым (рис. 5). Поддерживается много разных методов:
- логин и пароль;
- средство электронной подписи;
- вход через внешние сервисы идентификации;
- вход по разовой ссылке;
- прокси-аутентификация;
- вход по сеансу операционной системы;
- разовый пароль на основе секрета (HOTP);
- SMS-код подтверждения;
- разовый пароль на основе времени (TOTP)
В этом же разделе («Аутентификация») задается максимальная продолжительность сессии и продолжительность сессии при бездействии пользователя.
Внешние поставщики идентификации настраиваются в разделе «Поставщики идентификации». Именно здесь можно настроить идентификацию посредством Google, Facebook, VK, ЕСИА.
Настроить сервисы самообслуживания можно в одноименном разделе. На рис. 7 видно, что доступны такие сервисы, как регистрация, личный кабинет и восстановление доступа. Здесь можно настроить, какие данные пользователи указывают о себе при регистрации, что за действия им доступны в личном кабинете (редактирование атрибутов, смена пароля, включение двухфакторной аутентификации, привязка аккаунтов социальных сетей).
Ранее мы говорили о том, что сервер аутентификации должен поддерживать темы оформления, чтобы предоставляемые им сервисы (регистрация, личный кабинет, восстановление доступа) можно было «вписать» в дизайн сайта. Тему оформления можно выбрать в разделе «Внешний вид».
Что видит пользователь
А теперь посмотрим, что видит пользователь. Типичная страница входа показана на рис. 9. Можно войти как по обычному паролю, так и через Facebook и другие социальные сети. Также доступен вход через филиал в Санкт-Петербурге — доступные внешние источники идентификации настраиваются в разделе «Поставщики идентификации» (рис. 6).
В личном кабинете отображаются основные данные пользователя, а также последние события безопасности, вместе с IP-адресами — источниками этих событий.
В разделе «Безопасность» можно сменить пароль, настроить привязку к учетным записям в социальных сетях, а также настроить подтверждение входа (рис. 11). Поддерживаются различные способы подтверждения, в том числе популярная нынче доставка SMS-кодов подтверждения доступа.
При входе через социальную сеть пользователь увидит окошко (рис. 13). Наверняка ты уже сталкивался с подобными. Теперь ты знаешь, с помощью чего можно прикрутить такое окно к своим приложениям.
Дорого?
Смотришь на все это, и создается впечатление, что такое решение должно стоить дорого. Отнюдь. Есть две редакции продукта: Standard Edition и Enterprise Edition. Так вот, Standard Edition для некоммерческого использования бесплатна. Standard Edition можно свободно загрузить с сайта производителя. Существуют версии для Windows и Linux (Ubuntu, Debian, RHEL, CentOS).
Понятно, что Standard Edition и Enterprise Edition отличаются функциональностью. Например, в Enterprise допускается возможность одновременного использования нескольких хранилищ учетных записей, поддерживается гибкая настройка правил контроля доступа при входе в приложения, предоставляются дополнительные инструменты администрирования, дополнительные методы идентификации и аутентификации. Подробно о возможностях этих двух версий можно прочитать на сайте разработчика.
Стоимость Enterprise-версии можно узнать у партнеров компании РЕАК СОФТ.
Заключение
Пользователи могут входить в созданное тобой приложение и в другие приложения компании (о существовании которых ты даже можешь и не знать), используя учетную запись Blitz Identity Provider в качестве признаваемой всеми приложениями «визы». Пользователи избавлены от парольного хаоса. Больше не нужно иметь различные логины и пароли в каждом из приложений.
Система аутентификации Blitz Identity Provider существует не в вакууме — она стыкуется с аналогичными системами: системами идентификации социальных сетей, системой идентификации в корпоративном Kerberos-домене, партнерскими системами федеративного входа, удостоверяющими центрами и хранилищами учетных записей. С Blitz Identity Provider ты конструируешь свое собственное Шенгенское соглашение, определяешь пространство доверия и включаешь в него приложения, пользователей и механизмы аутентификации.
