Skip to content

Access Use Cases#

Access provides integration with:

  • LP5;
  • LUNA CARS;
  • CBS.

There are two use cases for LP5 integrations:

  • Single-factor authentication — user authentication is performed using only one parameter — facial biometrics.
  • Two-factor authentication — authentication using two factors: an access card and the user's facial biometrics.

The key difference between single-factor and two-factor authentication is the level of security and procedures. Two-factor authentication is the most secure access control method, which is used in areas with increased security requirements. Single-factor pipelines implement a simplified access scheme. This method is the most common and is suitable for areas with standard security requirements. It ensures fast and efficient passage through checkpoints with high traffic.

Single-factor authentication#

Basic pipelines:

  • SendToLuna - sending events to LP5. Works with events of type FaceDetectionEvent.
  • SendThermalEventToLuna - sending events to LP5 containing information about a person's temperature. Works with events of type ThermalEvent.
  • LunaEventListener - reading and processing information returned by LP5. Works with events of type LunaEvent.

ThermalEvent differs from FaceDetectionEvent by having a "Temperature" field.

General flow chart of the process (Figure 1):

General flow chart of the single-factor authentication process
Figure 1. General flow chart of the single-factor authentication process

Sending events to LP5#

Step 1. Initiating events

Face detection devices (terminals) send events of type FaceDetectionEvent and ThermalEvent to Access.

Step 2. Receiving, processing and sending events

The SendToLuna and SendThermalEventToLuna pipeline receives events from face detection devices and sends them to LP:

  • SendToLuna — listens for and sends events of type FaceDetectionEvent to LP.
  • SendThermalEventToLuna — listens for and sends events of type ThermalEvent to LP.

Processing LP5 responses via an controller#

When working with Access, when we process responses received from the LP5 LunaEvents component, two different integration methods are used: via an intermediary and directly via the ACS API. These methods determine how the turnstile (ACS) opening will be initiated.

This type of integration involves the use of a physical intermediary to interact with the ACS controller. This means that specialized devices are involved (GateController, PusrController, etc.).

The process of pipelines for processing LP responses during integration via an intermediary:

Step 1. Initiating events

LP5 sends events of type LunaEvent to Access.

Regardless of what event was sent to LP, the response from LP is always standardized.

Step 2. Receiving and processing events in the LunaEventListener pipeline

The LunaEventListener pipeline is configured to listen to and process incoming events of type LunaEvent from LP.

The LunaEventListener pipeline extracts all the necessary information from the LunaEvent event, such as full name, similarity percentage, etc.

The LunaEventListener also extracts the user's card number from the userdata field, in order to send this card number to the controller.

A note about extracting the card number. This action does not always occur. The logic is as follows: if there is a controller in VL Access configured to receive events from a certain source, then the userdata fragment containing the card number is sent to this controller. And if such a controller is missing, then the card number will not be sent anywhere.

Step 3. Transferring data to the controller/device

The LunaEventListener pipeline displays a message about successful/unsuccessful identification on the device screen.

The LunaEventListener pipeline sends the user's card number to the physical intermediary device (controller), which is directly connected to the ACS controller.

Step 4. Making a decision by the ACS

After receiving the data, the ACS makes a decision about opening the turnstile or blocking it.

LunaEventListener can extract the card number and send it to the controller, eliminating the need for additional pipelines for transferring data to controllers. Therefore, Access does not provide pipelines for sending to controllers.

Processing responses from LP5 via the ACS API#

This type of integration provides the ability to directly transfer events to the ACS using the API. This is an event with a message about the need to open the door for a specific person.

With this type of integration, events are transferred directly via the API, which ensures high processing speed and minimizes delays.

The process of working with pipelines for processing responses during integration without intermediaries (via the ACS API):

Step 1. Initiating events

LP5 sends events of type LunaEvent to Access

Regardless of what event was sent to LP5, the response from LP5 is always standardized.

Step 2. Simultaneous operation of the LunaEventListener pipeline and a specialized pipeline for ACS

In the second step in this type of integration, two pipelines work in parallel: LunaEventListener and a specialized pipeline for ACS.

Step 2.1. Processing events in the LunaEventListener pipeline

The LunaEventListener pipeline is configured to listen to and process incoming LunaEvent events from LP5.

The LunaEventListener pipeline extracts all the necessary information from the LunaEvent event, such as full name, similarity percentage, etc.

Step 2.2. Processing events in a specialized pipeline for ACS

A specialized pipeline for ACS creates an event and sends it to the ACS.

Depending on the type of ACS, the appropriate pipeline will be used: SendToParsec, SendToStrazh, CreateBastionEvent and others.

Access has various specialized pipelines that are necessary to create understandable responses for various ACS. In the absence of a pipeline for a specific ACS (for example, for Bolid), the first type of integration is used - through an intermediary, where the response from the LP is processed only by the LunaEventListener pipeline.

Two-factor authentication#

Two-factor authentication pipelines are divided by who makes the access decision:

  • Access;
  • ACS.

Since one of the factors in two-factor user authentication is facial biometrics, to ensure interaction with LP5, it is necessary to use pipelines for sending detections - SendToLuna or SendThermalEventToLuna pipelines.

Access-side control#

Basic pipelines for sending events to LP5:

  • SendToLuna - sending events to LP5. Works with events of the FaceDetectionEvent type.
  • SendThermalEventToLuna - sending events to LP5 containing information about a person's temperature. Works with events of the ThermalEvent type.

Basic pipelines for processing events from LP5:

  • Custom2FA - a universal pipeline for working with different ACS. The most popular use case is with the Bolid ACS
  • Apacs2FA - a specialized pipeline for working with the Apacs ACS. Apacs2FA differs from Custom2FA by an additional attribute access_denied_card`.

The access_denied_card attribute is needed so that if the card and face do not match, Access can send the card number specified in the access_denied_card field to the ACS. In this case, the sent card number is an indicator that something went wrong with the biometrics.

When using Custom2FA and Apacs2FA it should be ensured:

  • the card reader should be connected to the terminal;
  • the same terminal performs face detection;
  • the same terminal transmits data to Access.

General scheme of the process (Figure 2):

General scheme of the two-factor authentication process with control on the Access side
Figure 2. General scheme of the two-factor authentication process with control on the Access side

Step 1. Sending events to LP5

Sending events to LP5 is similar to single-factor authentication.

Step 2. Initiating events

LP5 sends LunaEvent events to Access

Regardless of what event was sent to LP5, the response from LP5 is always standardized.

Face detection devices (terminals) send CardReaderEvent events to Access. That is, it is assumed that a card reader must be connected to the terminal.

Step 3. Processing events and sending events

The Custom2FA and Apacs2FA pipelines are configured to listen to and process incoming CardReaderEvent events from the terminal and LunaEvent from LP5, the received events are sent to Access.

Step 4. Making a decision on access

The card number attached to the terminal is checked against the card number specified in the LP5 database for the person.

Based on the check of card numbers, Access makes a decision on access.

The decision on access is sent to the ACS to perform actions to grant or deny access.

Control on the ACS side#

When working with Strazh and Bastion ACS, the decision to pass is made on the ACS side. These ACS support confirmation of passage by an external system - Access with an event of the FaceDetectionEvent/ThermalEvent type.

General process diagram (Figure 3):

General process diagram of two-factor authentication with control on the ACS side
Figure 3. General process diagram of two-factor authentication with control on the ACS side

The process of two-factor pipelines for processing responses from LP, when the decision to pass is made on the ACS side

Step 1. Initiation of events

The user applies the card directly to the ACS reader.

The ACS initiates waiting for confirmation from the external system.

In this case, the reader must be connected to the ACS controller. Card reading events are not processed in Access.

Step 2. Receiving and processing events

The device sends an event of the FaceDetectionEvent/ThermalEvent type, Access forwards the data to LP5 using the SendToLuna/SendThermalEventToLuna pipeline and LP5 returns an event of the LunaEvent type.

The CreateBastionEvent or SendToStrazh pipeline (depending on the ACS) listens to LunaEvent events and, based on them, generates events for face matching by means of the ACS.

Step 3. Making a decision on passage

The ACS compares the data on the person to whom the swiped card belongs with the data on the "owner" of the face, which Access sends, and makes a decision on passage

Vehicle access control#

Basic pipelines:

  • SendCarsToLaurent — listens and processes events of the CarDetectionEvent type;
  • SendCarsToSigur — listens and processes events of the CarDetectionEvent type.

The pipelines have similar functionality to the LunaEventListener pipeline and are responsible for processing events received from LUNA CARS.

Integrations with LUNA CARS do not use pipelines similar to the SendToLuna pipeline (from the LP5 integration), since Access does not have direct access to the vehicle detection device.

The process of working with pipelines for processing events from LUNA CARS:

Step 1. Initiating events

The SendCarsToLaurent/SendCarsToSigur pipeline listens for events from LUNA CARS.

Step 2. Creating a new event / Sending a command to close the relay

For the Sigur ACS, the SendCarsToSigur pipeline creates an event of the SigurCarEvent type, which is then sent to the Sigur ACS.

For the Laurent controller, no event is created. The SendCarsToLaurent pipeline executes a command to activate (close) the relay of the Laurent device, providing direct control of the device (Figure 4).

Workflow of pipelines for processing events from LUNA CARS
Figure 4. Workflow of pipelines for processing events from LUNA CARS

Working with CBS#

A single standardized MatchByPhotolnCbs pipeline is used to work with CBS, the purpose of which is to transfer face detection data directly to CBS.

The MatchByPhotolnCbs pipeline works with an event of the FaceDetectionEvent type and receives the event in one of the following ways:

  • directly from the device, when the event is generated and transmitted directly from the detection device.
  • via a stream from the device, in this case the event is received via a configured stream in LUNA Streams with the addition of the LunaStreams service in Access.

For information about LUNA Streams, see the official FaceStream documentation.

General process flow (Figure 5):

General flow chart of the integration process with CBS
Figure 5. General flow chart of the integration process with CBS

The process of Access working with CBS:

Step 1. Initializing CBS components in Access

The CBS component is added to Access on the "Services" tab, allowing you to select it in the MatchByPhotolnCbs pipeline settings for sending events.

Step 2. Processing and sending events

The FaceDetectionEvent type event comes to Access directly through the device or through a stream from the device.

The MatchByPhotolnCbs pipeline receives the event and passes it to the selected CBS, which is entered as a component.

Step 3. Generating events

The MatchByPhotolnCbs pipeline generates events depending on the CBS response.

Successful CBS response#

The MatchByPhotolnCbs pipeline generates an event of the SuccessMatchEvent type.

The generated event is processed using the pipeline.

Depending on the type of the ACS system, the corresponding ACS pipeline will be used.

These pipelines work similarly to the LunaEventListener pipeline and are used to extract user card numbers.

This mechanism allows you to associate events with the corresponding data processing.

The MatchByPhotolnCbs pipeline generates an event of the DeviceMessageEvent type and sends it to the SendToDevice pipeline.

The SendToDevice pipeline displays a message about successful identification on the device screen.

Unsuccessful CBS response#

The MatchByPhotolnCbs pipeline generates an event of the DeviceMessageEvent type.

The SendToDevice pipeline is configured to listen for DeviceMessageEvent events, and when such an event occurs, it displays a message on the device about unsuccessful identification.