ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT pos gosuslugi

Содержание
  1. Авторизация пользователей
  2. Строгая аутентификация
  3. Технология единого входа
  4. Комплекс решений Indeed ID
  5. Механизмы аутентификации в пользовательских интерфейсах
  6. Для кого эта статья
  7. Начало
  8. Процессы аутентификации
  9. Варианты фиксирования уникального имени пользователя (логин)
  10. Варианты подтверждения логина (пароль)
  11. Необходимость интернет соединения при различных видах аутентификации
  12. Комбинации ввода логина и пароля
  13. Механизм проверки соответствия логина и пароля
  14. Двухфакторная аутентификация
  15. Упрощённая схема двух факторной аутентификации
  16. Ошибки аутентификации
  17. Процесс восстановления пароля
  18. Упрощённое объяснение термина “сессия”
  19. Cookies
  20. Заключение
  21. Процедура авторизации сотрудников
  22. Что же это такое?
  23. Проблематика
  24. Пути решения
  25. Итого
  26. Описание системы Blitz Identity Provider и протокола авторизации OAuth 2.0
  27. Краткое описание протокола авторизации OAuth 2.0
  28. Схема работы протокола авторизации OAuth 2.0
  29. Схема работы личного кабинета с Blitz
  30. Проверка токена авторизации
  31. Процедура авторизации
  32. Аутентификация react-приложения в системе
  33. Описание механизма авторизации внутри системы
  34. Схема взаимодействия react-приложения с back-приложением
  35. Аутентификация внешних систем
  36. Схема взаимодействия внешних систем с личным кабинетом
  37. Заключение

Авторизация пользователей

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

Идентификация — это точное установление личности пользователя на основании различных признаков. Использование пароля – идентификация пользователя по одному признаку. Идентификация позволяет системе установить имя пользователя.

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

Алгоритм реализации процедуры проверки прав доступа пользователей может быть разным. Необходимо использовать все имеющиеся в СУБД средства для реализации точной настройки прав доступа, но не в коем случае не «зашивать» пароль пользователя в код прикладной программы.

Более тонкая настройка уровней доступа пользователей возможна средствами языка SQL
. Для этого можно использовать такие объекты БД как представления (просмотры, view
).

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

Привилегия доступа – возможность определенного пользователя (группы пользователей) выполнять определенный вид действия над определенными объектами БД. Привилегии определяется АД и реализуется АБД или другим пользователем, которому АБД предоставил такое право.

SQL
команда установки привилегий выглядит следующим образом: Grant <вид привилегии> On <имя таблицы/имя представления> To <объект/список пользователей>

Существуют следующие виды привилегий: — All
– возможность выполнения всех операций ( Select
, Delete
, Insert
, Update
, Execute)
; Select
– только чтение данных; Delete
– только удаление; Inser t
– только добавление; Update
– только обновление; Execute
– возможность выполнения хранимых процедур.

Объект это: процедура; триггер; представление (просмотр); пользователь и др.

По умолчанию доступ к таблицам и хранимым процедурам имеет только тот пользователь, который их создал. Естественно, АБД имеет доступ ко всем объектам БД. Для предоставления пользователю привилегии доступа к таблице в операторе Grant
необходимо указать, как минимум, следующие параметры: ключевое слово, обозначающее вид привилегии доступа; имя таблицы; имя пользователя.

Пример 2. Дать право выполнять все операции всем пользователям в таблице Adres
: Grant Select, Insert, Update On Adres To Public
.

Пример 3. Предоставить пользователям IvanovVV
и PetrovKL
добавлять и менять значения столбцов А1
и А2
в таблице Adres
: Grant Update (А1,A2) On Adres To IvanovVV, PetrovKL
.

Пример использования представления в команде назначения прав: Grant Select On «Представление1» To «Пользователь1», «Пользователь2»
. После выполнения команды пользователям «Пользователь1» и «Пользователь2» будут даны права на чтение названий должностей, относящихся к 5 категории.

Данные представления можно обновлять, т.е. применять к этому объекту БД операции добавления, изменения, вставки и удаления записей. Тогда пользователь, имеющий права на работу с этим представлением, сможет вследствие получить права и на операции, определенные для этого представления. При этом некоторые СУБД требуют выполнения трех условий: представление должно формироваться из записей только одной таблицы; в представление каждый столбец должен иметь опциональность Not Null
; оператор Select
представления не должен использовать агрегирующих функций, режима Distinct
, предложения Having
, операций соединения таблиц, хранимых процедур и функций, определенных пользователем.



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

«Неудобны» пароли и для специалистов IТ- и ИБ-служб. Забытые после отпусков пароли и заблокированные учетные записи требуют от них дополнительных затрат на восстановление этих данных.

 «Неуправляемое» управление доступом

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

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

Для решения этих проблем используются технологии строгой аутентификации и единого доступа.

Строгая аутентификация

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

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

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

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

Кроме того, применение технологии строгой аутентификации обеспечивает автоматическое исполнение регламентов доступа к ИТ-системам компании.

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

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

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

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

Комплекс решений Indeed ID

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

Данный комплекс поддерживает широкий спектр различных технологий строгой аутентификации (смарт-карты, токены и RFID-карты различных производителей, биометрия, одноразовые пароли), позволяя реализовать различные сценарии многофакторной аутентификации пользователей. Все поддерживаемые технологии можно комбинировать между собой. Например, можно аутентифицировать пользователей по отпечатку пальца и бесконтактной карте, смарт-карте и ОТP и т.д. При этом если на предприятии уже используются какие-то способы строгой аутентификации, они могут быть поддержаны данным комплексом благодаря особенностям архитектуры входящих в него решений, что особенно удобно, поскольку не требует дополнительных затрат на приобретение новых средств аутентификации и дает возможность гибко адаптировать систему аутентификации к потребностям и текущим условиям работы компании.

Читайте также:  Шумная работа и тихий отдых вместе или по отдельности?

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

Indeed Enterprise SSO подходит для любых типов приложений (Windows, Java, Web), независимо от их архитектуры: однозвенная, двухзвенная, трехзвенная, «толстый» клиент, «тонкий» клиент, терминальные приложения. При этом организовать доступ можно как в коробочные приложения, так и в приложения, разработанные на заказ.

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

В компаниях, использующих смарт-карты и токены, Indeed Enterprise SSO позволяет связать учетные данные пользователей с жизненным циклом ключевых носителей, интегрировав систему аутентификации с системами управления ключевыми носителями (Card Management System, CMS). Можно отметить, что в состав комплекса входит CMS-система этого же разработчика (Indeed Card Management), хотя при необходимости интеграция возможна и с другими системами данного класса, представленными на рынке.

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

Механизмы аутентификации в пользовательских интерфейсах

Время на прочтение

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

Для кого эта статья

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

Начало

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

Аутентификация – это процесс, при котором пользователь подтверждает подлинность своей личности в какой-либо системе. Система предоставляет личные данные только своему владельцу.

Учётная запись – это хранимый в системе набор данных о пользователе. К учётной записи как правило имеет доступ лишь один пользователь – её владелец.

В кино, когда шпиона просят назвать кодовую фразу для подтверждения своей личности – то по факту осуществляется процесс аутентификации пользователя. Если кодовая фраза (пароль) верный – то шпиону доверяют и предоставляют закрытые от остальных данные. ( Утрированно)

Процессы аутентификации

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

  1. Регистрация (CREATE) – создание в системе вашей личной учётной записи

  2. Авторизация (READ) – получение доступа к вашей личной учётной записи

  3. Восстановление доступа к учётной записи (UPDATE) – если вы на пример забыли пароль – то его можно сменить, подтвердив свою личность.

  4. Удаление (DELETE) – удаление вашей учётной записи из системы

Варианты фиксирования уникального имени пользователя (логин)

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT
  1. Номер телефона (+996 777 777 777)

При аутентификации в сервисе А через сторонние сервисы Б – вам не нужно проходить процесс подтверждения личности в сервисе Б, а лишь нужно подтвердить свою личность в сервисе А. ( На пример зайти в учётную запись Google, и при помощи её зайти в учётную запись Figma). Могут использоваться проверки в виде сообщения на почту со ссылкой для подтверждения регистрации/авторизации.

Варианты подтверждения логина (пароль)

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT
  1. SMS код (9379992SMS)

  2. Код в электронном сообщении (9379992MAIL)

  3. PIN код (9379992)

  4. Ключи доступа / Токены (как пример

    ssh key)

  5. Сканеры внешности (лицо, отпечаток пальца)

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

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

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

Комбинации ввода логина и пароля

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

Механизм проверки соответствия логина и пароля

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT
  1. Отправляем данные на проверку

  2. Система отправляет результат проверки пользователю.

  3. Получаем результат проверки

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

Двухфакторная аутентификация

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

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

Упрощённая схема двух факторной аутентификации

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

Ошибки аутентификации

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT
  1. Пароль введён неверно

  2. Нет соединения с сервером

  3. Ошибка проверки данных сервером

  4. Превышен лимит ошибочных попыток аутентификации

  5. Пользователь ввёл верно свои денные, но он не зарегистрирован

  6. Учётная запись пользователя заблокирована администратором

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

Процесс восстановления пароля

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

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

  1. Подтвердить свою личность (на пример пройти по ссылке в электронном письме от сервиса восстановления пароля или ввести код из СМС)

  2. Ввести новый пароль

  3. Повторить ввод нового пароля

  4. Сохранить новый пароль

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

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

Упрощённое объяснение термина “сессия”

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

Для того что бы различать входы с различных устройств – каждой сессии присваивается свой уникальный для каждой авторизации номер (Токен), который хранится в Cookies. Это нужно для того, что бы при выходе (закрытии сессии) с одного из устройств вы не выходили из своей учёной записи во всех остальных устройствах.

Cookies

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

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

Читайте также:  Истоки пенсий: краткий урок истории

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

Заключение

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

Надеюсь вам было полезно, и хоть немного интересно.

Процедура авторизации сотрудников

Процедура регистрации (создания учетной записи) пользователя для сотрудника и предоставления ему (или изменения его) прав доступа к ресурсам АС инициируется заявкой начальника подразделения (отдела, сектора), в котором работает данный сотрудник. В заявке указывается:

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

· наименование подразделения, должность, фамилия, имя и отчество сотрудника;

· имя пользователя (учетной записи) данного сотрудника (при изменении полномочий и прав доступа);

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

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

Затем руководители подразделений автоматизации и обеспечения безопасности ИТ рассматривают представленную заявку и подписывают задание соответствующим системным администраторам (серверов, баз данных) и администратору специальных средств зашиты информации от несанкционированного доступа (СЗИ НСД) на внесение необходимых изменений в списки пользователей соответствующих подсистем.

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

Аналогичные операции для систем управления базами данных (СУБД) выполняет администратор баз данных.

Администратор СЗИ НСД в соответствии с формулярами указанных задач и Руководством администратора системы защиты от НСД производит необходимые операции по регистрации нового пользователя, присвоению ему начального значения пароля (возможно также регистрацию персонального идентификатора, например iButton) и прав доступа к ресурсам указанных в заявке рабочих станций, включению его в соответствующие задачам системные группы пользователей и другие необходимые операции.

После внесения изменений в списки пользователей администратор СЗИ НСД должен обеспечить соответствующие категориям защиты указанных рабочих станций настройки средств защиты. Проверка правильности настроек средств защиты должна осуществляться с участием сотрудника, ответственного за эксплуатацию конкретной рабочей станции, согласно «Порядку проверки работоспособности системы защиты после установки (обновления) программных средств АС и внесения изменений в списки пользователей».

По окончании внесения изменений в списки пользователей в заявке делается отметка о выполнении задания за подписями исполнителей – системного администратора, администратора баз данных и администратора СЗИ НСД.

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

Исполненная заявка передается в подразделение и хранится в архиве у ответственного за информационную безопасность подразделения (при его отсутствии – у руководителя подразделения). Копии исполненных заявок могут находиться также в подразделении автоматизации (у системных администраторов) и в подразделении обеспечения безопасности ИТ. Они могут впоследствии использоваться:

· для восстановления бюджетов и полномочий пользователей после аварий в АС;

· для контроля правомерности наличия у конкретного пользователя прав доступа к тем или иным ресурсам автоматизированной системы при разборе конфликтных ситуаций;

· для проверки правильности настройки средств разграничения доступа к ресурсам автоматизированной системы.



ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:


ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

В более чем 80% случаев термин употребляется неверно, вместо него следовало бы использовать слово «аутентификация». Далее я попытаюсь объяснить что это такое, и почему крайне важно уделить особое внимание этой теме.

Что же это такое?

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

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

Проблематика

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

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

  1. Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе
  2. Автор договора должен видеть его на всех этапах.
  3. Создавать договор имеет право пользователь с грейдом не ниже 10.
  4. Визирующий должен видеть договор, начиная с поступления к нему на этап и далее.
  5. Руководители подразделений должны видеть договоры своих подразделений вверх по иерархии.
  6. Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования.
  7. Руководство и секретариат головного офиса должны видеть документы всех филиалов.
  8. Пользователь, создавший договор, не должен иметь права его завизировать.

От безопасности мы могли бы получить следующие требования
:

  1. Знать, кто имеет доступ к конкретному договору.
  2. Знать, кто имел доступ к конкретному договору в заданный момент времени.
  3. Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей.

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

Итак, обозначим, почему эти требования проблемные:

  • Они не стабильны. Вероятность их изменения, даже в краткосрочной перспективе, стремится к 1.
  • Они сквозные. Их реализация влияет на все слои, от дизайна БД до UI.
  • Они лежат в плоскости предметной области. Это ведет к сильной связности механизма авторизации со слоем бизнес-логики. 
  • Они влияют на производительность. 

Пути решения

Решить данную задачу нам помогают разработанные модели управления доступом:

Читайте также:  Откройте для себя природную красоту Еся-Алтая: скрытую жемчужину региона

MAC
— мандатная модель управления доступом. Доступ субъекта к объекту определяется его уровнем доступа: уровень доступа субъекта должен быть не ниже уровня секретности объекта.

DAC
— прямое управление доступом. Доступ субъекта к объекту определяется наличием субъекта в списке доступа (ACL)
объекта.

RBAC
— ролевая модель управления доступом. Доступ субъекта к объекту определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу.

АВАС
— атрибутивная модель управления доступом. Доступ субъекта к объекту определяется динамически на основании анализа политик учитывающих значения атрибутов субъекта, объекта и окружения. Сюда же относятся PBAC, RAdAC, CBAC
, с некоторыми нюансами ( шикарный обзор от CUSTIS
).

Их крайне рекомендуется использовать в первозданном виде, не изобретая велосипед. Достаточно часто в сложных информационных системах используется комбинация моделей. Например, популярна комбинация ACL + RBAC, когда роль включается в список доступа. Однако, правильное применение готовых моделей — тоже не простая задача. Не всем удается правильно выбрать модель, отделить ее от бизнес-логики и достичь приемлемой производительности механизма авторизации.

Для реализации озвученных выше в разделе «Проблематика» требований, на первый взгляд, я бы выбрал комбинацию PBAC + ACL. Требования могли бы быть реализованы следующим образом:

Перечисленные требования ИБ без всяких проблем реализуются с использованием ACL, однако бизнес-требования 5 и 7 мы реализуем с помощью PBAC. Так что для реализации требований ИБ 1 и 2 придется добавить к ним журнал или аналогичный механизм, поскольку при всей своей красоте динамические правила плохо аудируются:

Итого

Авторизация — незаслуженно обойденная вниманием тема, как в публикациях, так и непосредственно в процессе разработки. Двухфакторную аутентификацию по СМС к сайту прикрутит и ребенок. Правильно реализовать авторизацию в корпоративной системе, не наделав костылей — сложнейшая задача, о которую ломают копья сеньоры и архитекторы, а множество популярных коммерческих продуктов (к примеру, Atlassian Jira) стоят на костылях благодаря сложности требований. 

Мы планируем серию статей, посвященных моделям авторизации и предмету в целом. Будем рады вопросам и предложениям по темам для рассмотрения.

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

Актуальна ли тема?

Тема интересна, пишите еще!

Тема уныла, потому никто о ней и не говорит.

Проголосовали 326 пользователей.

Воздержались 34 пользователя.

Время на прочтение

В данной статье мы рассмотрим систему аутентификации пользователей и внешних систем в личном кабинете через сервер аутентификации Blitz Identity Provider. 

Согласно требованиям проекта, который мы рассмотрим здесь в качестве примера, взаимодействие клиентской и серверной частей должно происходить по Rest API, реализованном на микрофреймворке Slim. Для авторизации пользователей необходимо провести интеграцию с сервером аутентификации Blitz Identity Provider, который в свою очередь интегрирован с внутренней системой единого входа заказчика (SSO). Это мастер-система, определяющая возможность доступа и уровень доступа пользователя для личного кабинета является Blitz. Поэтому при каждой авторизации пользователя в системе обновляется уровень доступа по данным из Blitz. 

Данные в личный кабинет должны приходить из систем хранения информации (ERP и SRM) и управления учетными записями пользователей, также использующие Rest Api Личного кабинета. Эти системы должны проходить аутентификацию напрямую в ЛК.

Описание системы Blitz Identity Provider и протокола авторизации OAuth 2.0

Blitz Identity Provider реализует более простой доступ к системам заказчика и бесшовное переключение между различными приложениям. Этому способствуют технологии однократной аутентификации и единого входа (Single Sign-On), а также работа с механизмами аутентификации устройств доступа пользователей.

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

Краткое описание протокола авторизации OAuth 2.0

OAuth 2.0 базируется на возможностях базовых web-технологий: HTTP-запросах, редиректах. Поэтому применение OAuth возможно на любой платформе с доступом к сети и браузеру: на сайтах, в мобильных и desktop-приложениях.

Общая схема работы приложения, использующего OAuth, такова:

  1. обращение к защищенным ресурсам

Результатом авторизации является access token
— некий ключ (обычно просто набор символов), предъявление которого является пропуском к защищенным ресурсам. Обращение к ним в самом простом случае происходит по HTTPS с указанием в заголовках или в качестве одного из параметров полученного access token
‘а.

В протоколе описано несколько вариантов авторизации, подходящих для различных ситуаций:

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

  • авторизация для полностью клиентских приложений (мобильные и desktop-приложения)

  • восстановление предыдущей авторизации

Схема работы протокола авторизации OAuth 2.0

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

Схема работы личного кабинета с Blitz

Проверка токена авторизации

При заходе пользователя в личный кабинет react-приложение проверяет, есть ли в куках браузера пользователя access_token. Если токен присутствует, то front отправляет запрос на back для получение нужных ему данных, передавая в параметре или в заголовках access_token.

Если на запрос react-приложения, back отдает 401 ответ (то есть действие токена закончилось либо токен некорректный), front  отправляет новый http запрос на обновление access_token. Back приложение пытается обновить access_token с помощью refresh_token, делая запрос в Blitz. Если обновление прошло успешно, то на front возвращается новый access_token, который записывается в куки. 

Если access_token не найден в системе (БД back приложения) или срок жизни refresh_token закончился или access_token отсутствует в куках, то фронт начинает процедуру авторизации.

Процедура авторизации

Сначала со стороны react-приложения отправляется запрос на back-приложения для получения адреса страницы системы Blitz, чтобы перенаправить туда пользователя для авторизации.

В системе Blitz сотрудник вводит свои учетные данные, авторизуется по номеру телефона или по сеансу ОС, если находится во внутренней сети заказчика.

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

Front-приложение делает запрос на back с параметром code, полученным из Blitz. Далее back-приложение отправляет http-запрос с параметром code в Blitz для получения токенов доступа и времени их жизни. После этого back-приложение отправляет еще один http-запрос в Blitz, передавая в параметрах полученный access_token, для получения информации о сотруднике.

При успешном получении информации о сотруднике из Blitz система (back-приложение личного кабинета) проверяет для пользователя внутри системы учетная запись  и при ее наличии обновляет информацию о сотруднике, а при отсутствии создает новую УЗ.

Затем ID УЗ сотрудника и информации о токенах доступа записывается в БД, а на фронт отдается access_token.

На этом процедура авторизации сотрудника в системе через Blitz заканчивается.

Аутентификация react-приложения в системе

Описание механизма авторизации внутри системы

Получение токена доступа react-приложением от back-приложения описано в разделе “Схема работы с blitz”.

После получения токена front-приложение передает в каждом запросе на back этот токен параметром либо в заголовках запроса. Так происходит до тех пор пока не истечет срок хранения токена в куках, либо от back не вернется код ответа 401, что будет означать окончание действия токена и станет сигналом для его обновления.

Схема взаимодействия react-приложения с back-приложением

ПРОЦЕДУРА АВТОРИЗАЦИИ СОТРУДНИКОВ И АВТОРИЗАЦИЯ ПОЛЬЗОВАТЕЛЕЙ В СИСТЕМЕ ЧЕРЕЗ СЕРВЕР АУТЕНТИФИКАЦИИ BLITZ IDENTITY PROVIDER BITRIX SLIM REACT

Аутентификация внешних систем

Схема взаимодействия внешних систем с личным кабинетом

В bitrix создается пользователь с этими данными и привязывается к соответствующей группе доступа. 

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

После окончания время жизни токена (получения 401 ответа от back приложения личного кабинета) должна заново пройти процедуру авторизации.

Заключение

Выбранный стек технологий для реализации проекта и наличие системы единой авторизации у заказчика породило необходимость реализации “двойной авторизации”: авторизации web-приложения личного кабинета в blitz и авторизации react-приложения для работы с back по Rest Api.

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

Оцените статью