Перейти к содержанию

Сценарии использования Access#

Access обеспечивает интеграцию с:

  • LP5;
  • LUNA CARS;
  • КБС.

В рамках интеграций с LP5 два сценария использований:

  • Однофакторная аутентификация — аутентификация пользователя проводится только по одному параметру — по биометрии лица.
  • Двухфакторная аутентификация — аутентификация по двум факторам: по карте доступа и по биометрии лица пользователя.

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

Однофакторная аутентификация#

Базовые пайплайны:

  • SendToLuna - отправка событий в LP5. Работает с событиями типа FaceDetectionEvent.
  • SendThermalEventToLuna - отправка событий в LP5 содержащих информацию о температуре человека. Работает с событиями типа ThermalEvent.
  • LunaEventListener - чтение и обработка информации, возвращаемой LP5. Работает с событиями типа LunaEvent.

ThermalEvent отличается от FaceDetectionEvent наличием поля «Температура».

Общая схема процесса (Рисунок 1):

Общая схема процесса однофакторной аутентификации
Рисунок 1. Общая схема процесса однофакторной аутентификации

Отправка событий в LP5#

Шаг 1. Инициация событий

Устройства для детектирования лиц (терминалы) посылают события типа FaceDetectionEvent и ThermalEvent в Access.

Шаг 2. Получение, обработка и отправка событий

Пайплайн SendToLuna и SendThermalEventToLuna получают события от устройств для детектирования лиц и отправляют их в LP:

  • SendToLuna — слушает и передает события типа FaceDetectionEvent в LP.
  • SendThermalEventToLuna — слушает и передает события типа ThermalEvent в LP.

Обработки ответов от LP5 через посредника#

В процессе работы с Access, когда мы обрабатываем ответы, полученные от компонента LP5 LunaEvents, используются два различных способа интеграции: через посредника и напрямую по API СКУДа. Эти способы определяют, как будет инициировано открытие турникета (СКУД).

Этот тип интеграции предусматривает использование физического посредника для взаимодействия с контроллером СКУД. Это означает, что задействуются специализированные устройства (GateController, PusrController и т.д.).

Процесс работы пайплайнов для обработки ответов от LP при интеграции через посредника:

Шаг 1. Инициация событий

LP5 посылает события типа LunaEvent в Access.

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

Шаг 2. Получение и обработка событий в пайплайне LunaEventListener

Пайплайн LunaEventListener настроен на прослушивание и обработку приходящих событий типа LunaEvent от LP.

Пайплайн LunaEventListener извлекает из события типа LunaEvent всю необходимую информацию, например, ФИО, процент схожести (similarity) и так далее.

Также LunaEventListener извлекает номер карты пользователя из поля userdata, чтобы затем отправить этот номер карты в контроллер.

Примечание по поводу извлечения номера карты. Это действие происходит не всегда. Логика такая: если в VL Access существует контроллер, настроенный на прием событий от определенного источника, то в этот контроллер отправляется фрагмент userdata, содержащий номер карты. А если такой контроллер отсутствует, соответственно, и номер карты никуда отправляться не будет.

Шаг 3. Передача данных контроллеру / устройству

Пайплайн LunaEventListener выводит сообщение об успешной /неуспешной идентификации на экран устройства.

Пайплайн LunaEventListener отправляет номер карты пользователя в физическое устройство-посредник (контроллер), которое напрямую соединено с контроллером СКУД.

Шаг 4. Принятие решения СКУД

СКУД, получив данные, принимает решение об открытии турникета или его блокировки.

LunaEventListener умеет выделять номер карты и отправлять в контроллер, исключая необходимость в дополнительных пайплайнах для передачи данных в контроллеры. Поэтому в Access не предусмотрены пайплайны для отправки в контроллеры.

Обработки ответов от LP5 через API СКУД#

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

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

Процесс работы пайплайнов для обработки ответов при интеграции без посредников (по API СКУДа):

Шаг 1. Инициация событий

LP5 посылает события типа LunaEvent в Access

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

Шаг 2. Одновременная работа пайплайна LunaEventListener и специализированного пайплайна для СКУД

На втором шаге в данном типе интеграции параллельно работают два пайплайна: LunaEventListener и специализированный пайплайн для СКУД.

Шаг 2.1. Обработка событий в пайплайне LunaEventListener

Пайплайн LunaEventListener настроен на прослушивание и обработку приходящих событий LunaEvent от LP5. Пайплайн LunaEventListener извлекает из события LunaEvent всю необходимую информацию, например, ФИО, процент схожести (similarity) и так далее.

Шаг 2.2. Обработка событий в специализированном пайплайне для СКУД

Специализированный пайплайн для СКУД создает событие и направляет его в СКУД.

В зависимости от типа системы СКУД будет задействован соответствующий пайплайн: SendToParsec, SendToStrazh, CreateBastionEvent и другие.

В Access существуют различные специализированные пайплайны, которые необходимы для создания понятных ответов для различных СКУД. В случае отсутствия пайплайна для конкретного СКУД (например, для Bolid), применяется первый тип интеграции — через посредника, где ответ от LP обрабатывается только пайплайном LunaEventListener.

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

Пайплайны двухфакторной аутентификации делятся по тому, кто принимает решение о доступе:

  • Access;
  • СКУД.

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

Контроль на стороне Access#

Базовые пайплайны для отправки событий в LP5:

  • SendToLuna - отправка событий в LP5. Работает с событиями типа FaceDetectionEvent.
  • SendThermalEventToLuna - отправка событий в LP5 содержащих информацию о температуре человека. Работает с событиями типа ThermalEvent.

Базовые пайплайны для обработки событий от LP5:

  • Custom2FA - универсальный пайплайн для работы с разными СКУД. Наиболее популярный сценарий использования — со СКУД Bolid
  • Apacs2FA - специализированный пайплайн для работы со СКУД — Apacs. Apacs2FA отличается от Custom2FA дополнительным атрибутом access_denied_card`.

Атрибут access_denied_card нужен для того, чтобы в случае если карта и лицо не совпадают, Access мог отправить номер карты, указанный в поле access_denied_card, в СКУД. В этом случае отправленный номер карты является индикатором, что что-то пошло не так с биометрией.

При использовании Custom2FA и Apacs2FA должно обеспечиваться:

  • считыватель карт должен быть подключен к терминалу;
  • этот же терминал выполняет детектироваие лица;
  • этот же терминал передает вместе данные в Access.

Общая схема процесса (Рисунок 2):

Общая схема процесса двухфакторной аутентификации с контролем на стороне Access
Рисунок 2. Общая схема процесса двухфакторной аутентификации с контролем на стороне Access

Шаг 1. Отправка событий в LP5

Отправка событий в LP5 происходит аналогично однофакторной аутентификации.

Шаг 2. Инициация событий

LP5 посылает события типа LunaEvent в Access

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

Устройства детектирования лиц (терминалы) посылают события типа CardReaderEvent в Access. Предполагается, что считыватель для карты должен быть подключен к терминалу.

Шаг 3. Обработка событий и отправка событий

Пайплайны Custom2FA и Apacs2FA настроены на прослушивание и обработку приходящих событий CardReaderEvent от терминала и LunaEvent от LP5, полученные события поступают в Access.

Шаг 4. Принятие решения о проходе

Происходит сверка номера карты, приложенной к терминалу, с номером карты, указанным в базе данных LP5 для лица.

На основе сверки номеров карт, Access принимает решение о проходе.

Решение о проходе передается в СКУД для выполнения действий по предоставлению или отказу в доступе.

Контроль на стороне СКУД#

При работе со СКУД Strazh и Bastion решение о проходе принимается на стороне СКУД. В этих СКУД поддерживается подтверждение прохода внешней системой - Access c событием типа FaceDetectionEvent/ThermalEvent.

Общая схема процесса (Рисунок 3):

Общая схема процесса двухфакторной аутентификации с контролем на стороне СКУД
Рисунок 3. Общая схема процесса двухфакторной аутентификации с контролем на стороне СКУД

Процесс работы двухфакторных пайплайнов для обработки ответов от LP, когда решение о проходе принимается на стороне СКУДа

Шаг 1. Инициация событий

Пользователь прикладывает карту напрямую к считывателю СКУД.

СКУД инициирует ожидание подтверждения от внешней системы.

В этом случае считыватель должны быть подключены к контроллеру СКУД. События считывания карт в Access не обрабатываются.

Шаг 2. Получение и обработка событий

Устройство отправляет событие типа FaceDetectionEvent/ThermalEvent, Access перенаправляет данные в LP5 с помощью пайплайна SendToLuna/SendThermalEventToLuna и LP5 возвращает событие типа LunaEvent.

Пайплайн CreateBastionEvent или SendToStrazh (в зависимости от СКУД) слушают события LunaEvent и их на основе формируют события для матчинга лица средствами СКУД.

Шаг 3. Принятие решения о проходе

СКУД сравнивает данные о персоне, которой принадлежит считанная карта, с данными о «владельце» лица, которые отправляет Access, и принимает решение о проходе

Контроль доступа ТС#

Базовые пайплайны:

  • SendCarsToLaurent — слушает и обрабатывает события типа CarDetectionEvent;
  • SendCarsToSigur — слушает и обрабатывает события типа CarDetectionEvent.

Пайплайны обладают схожей функциональностью с пайплайном LunaEventListener и отвечают за обработку поступающих от LUNA CARS событий.

В интеграциях с LUNA CARS не используются пайплайны, аналогичные пайплайну SendToLuna (из интеграции с LP5), поскольку у Access нет прямого доступа к устройству детектирования машин.

Процесс работы пайплайнов для обработки событий от LUNA CARS:

Шаг 1. Инициация событий

Пайплайн SendCarsToLaurent/SendCarsToSigur слушает события от LUNA CARS.

Шаг 2. Формирование нового события / Отправка команды на замыкание реле

Для СКУД Sigur пайплайн SendCarsToSigur формирует событие типа SigurCarEvent, которое затем отправляется в СКУД Sigur.

Для Laurent-контроллера не формируется событие. Пайплайн SendCarsToLaurent выполняет команду на активацию (замыкание) реле устройства Laurent, обеспечивая прямое управление устройством (Рисунок 4).

Процесс работы пайплайнов для обработки событий от LUNA CARS
Рисунок 4. Процесс работы пайплайнов для обработки событий от LUNA CARS

Работа с КБС#

Для работы с КБС используется единый стандартизированный пайплайн MatchByPhotolnCbs, задача которого — передача данных о детекции лиц непосредственно в КБС.

Пайплайн MatchByPhotolnCbs работает с событием типа FaceDetectionEvent и получает событие одним из способов:

  • напрямую от устройства, когда событие генерируется и передаётся непосредственно от устройства детектирования.
  • через поток от устройства, в этом случае событие получается посредством сконфигурированного потока в LUNA Streams с добавлением сервиса LunaStreams в Access.

Информация о LUNA Streams см. в официальной документации FaceStream.

Общая схема процесса (Рисунок 5):

Общая схема процесса интеграции с КБС
Рисунок 5. Общая схема процесса интеграции с КБС

Процесс работы Access с КБС:

Шаг 1. Инициализация компонентов КБС в Access

Компонент КБС вносится в Access на вкладке «Сервисы», позволяя выбрать его в настройках пайплайна MatchByPhotolnCbs для отправки событий.

Шаг 2. Обработка и отправка событий

Событие типа FaceDetectionEvent поступает в Access напрямую через устройство или через поток от устройства.

Пайплайн MatchByPhotolnCbs принимает событие и передаёт его в выбранную КБС, которая заведена как компонент.

Шаг 3. Генерация событий

Пайпплайн MatchByPhotolnCbs генерирует события в зависимости от ответа КБС.

Успешный ответ КБС#

Пайплайн MatchByPhotolnCbs формирует событие типа SuccessMatchEvent.

В зависимости от типа системы СКУД будет задействован соответствующий пайплайн СКУД.

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

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

Пайплайн MatchByPhotolnCbs формирует событие типа DeviceMessageEvent и отправляет его в пайплайн SendToDevice.

Пайплайн SendToDevice выводит сообщение об успешной идентификации на экран устройства.

Неуспешный ответ КБС#

Пайплайн MatchByPhotolnCbs формирует событие типа DeviceMessageEvent.

Пайплайн SendToDevice настроен на прослушивание событий DeviceMessageEvent, и при возникновении такого события, выводит на девайс сообщение о неуспешной идентификации.