STRAZH ACS {#strazh-scud}
Performs replication of user data from the ACS to the specified list of the Biometric System and generates StrazhController controllers from the received list of devices for subsequent execution of requests for entry or exit.
- Supports the ACS version: 1.2.211201.648.
The integration supports operation in 1-phase and 2-phase modes.
Supported integration options for STRAZH ACS {#strazh-scud-integration}
The face recognition device generates an event, Access passes the event to LP5, LP5 processes the event and returns the result to Access for further processing.
Transfer of user data from the ACS to LP5 occurs using two mechanisms:
- replication - the mechanism for the initial transfer of user data;
- synchronization - the mechanism for periodic transfer of user data when the composition/data of users changes.
For the synchronization/replication settings, see the service settings.
Each integration with LP5 (Table 65) uses the Luna service.
If the terminal does not have data output facilities (e.g., a screen), the SendToDevice pipeline is not required.
Table 65. LP5 integration options
In each integration with CBS (Table 69), the CBS service is used.
Table 69. KBS integration options
| Service | Device | Pipeline |
|---|---|---|
| 1f | ||
| CbsMts + Strazh + StrazhController | Beward | MatchByPhoto + SendToDevice + SendToController |
| 2f | ||
| CbsMts + Strazh + StrazhController | Beward | MatchByPhoto + Strazh2FA |
| Dahua | MatchByPhoto + Strazh2FA | |
| HikvisionCamera | MatchByPhoto + Strazh2FA | |
| LunaFast4A1 | MatchByPhoto + Strazh2FA | |
| UniUbi | MatchByPhoto + Strazh2FA |
Standard integration using STRAZH ACS {#strazh-integration}
When integrating with STRAZH, standard Access components (Figure 106) and (Table 67) are used.
Table 67. Integration Description
| Component | Description |
|---|---|
| Person | A person wishing to pass through a passage point. |
| Passage point | A set of components used to control human access. More than one passage point can be connected, limited by the ACS license. A passage point can be used for both entry and exit. Each direction uses its own reader and video data source. |
| Video data source | A device for extracting a frame of a person's face. It can be either a biometric terminal (LUNA FAST 4A1 and others) or a camera connected via FaceStream. A biometric terminal allows you to create feedback to show a person information about the passage. |
| Controller | Pass point control board. |
| Turnstile | Barrier device for access control |
| STRAZH ACS | Central software for working with Strazh. Stores employee data and makes decisions on granting access. |
| STRAZH Service | An Access component for replicating/synchronizing employees from the ACS and listening to ACS events. |
| StrazhController | Access Component for interacting with the ACS controller. A separate controller must be created for each reader. |
| Device ... | An Access component for receiving data from a video data source. Selected based on the device used. |
| MatchByPhoto Pipeline | Access Component for interaction with the BS. When working with a biometric terminal, it is necessary to additionally connect the SendToDevice pipeline |
| Biometric system | A system for comparing a reference photo of a person with the best frame obtained from a video data source. Can be either Luna or support KBS. |
| SendToController Pipeline | Access Component for sending card number and full name to StrazhController after matching a person and confirming the card number in Access. |
| Storage | Local system for storing relationships between ACS persons and their biometric data. |
2f integration (Figure 107) and (Table 68).
Table 68. Integration description
| Component | Description |
|---|---|
| Person | A person wishing to pass through a passage point. |
| Passage point | A set of components used to control human access. More than one passage point can be connected, limited by the ACS license. A passage point can be used for both entry and exit. Each direction uses its own reader and video data source. |
| Video data source | A device for extracting a frame of a person's face. It can be either a biometric terminal (LUNA FAST 4A1 and others) or a camera connected via FaceStream. A biometric terminal allows you to create feedback to show a person information about the passage. |
| Controller | Passage point control board. |
| Device ... | An Access component for receiving data from a video data source. Selected based on the device used. |
| MatchByPhoto pipeline | Access component for interacting with the BS. When working with a biometric terminal, it is necessary to additionally connect the pipeline SendToDevice |
| BS Service | Access component for interaction with the Biometric System: for LP5 it is Luna, for KBS - the corresponding KBS service. |
| Biometric system | A system for comparing a reference photo of a person with the best frame obtained from a video data source. |
| Strazh service | Access component for replicating/synchronizing employees from the ACS and listening to ACS events. |
| Strazh2FA Pipeline | Access Component for Data Exchange with ACS |
| StrazhController | Access component for sending the card number to the ACS. |
| STRAZH ACS | Central software for working with the ACS. Stores employee data and makes decisions on granting access. |
| Turnstile | Barrier device for access control |
| Storage | Local system for storing relationships between ACS persons and their biometric data. |
Setting up STRAZH ACS software for two-factor authentication {#strazh-acs-settings}
The ACS has implemented privilege levels. For 1F and 2F authorization to work, the access point privilege level must be equal to the employee's level, otherwise access will be denied.
If the employee has a higher privilege level than the access point, authorization will only occur by 1F (by card).
To configure the software, follow these steps:
1․ Go to ACS Settings > Access Points > Create a new one (if not created).
2․ Enter the required access point data if necessary.
This completes the process of setting up 1F authorization, follow steps 3-5 if 2F is planned.
3․ Click the "Additional parameters" tab and add "Confirmation of access by an external system" with the value "Yes".
4․ Add the "Maximum waiting time for confirmation of access by an external system" parameter.
5․ Adjust the timeout for waiting for a response from the external system and the default decision if the system does not have time to process the request.
After this, when trying to pass through this point with a card whose privilege level is lower than the privilege level of the point, an event with type: access_confirmation and data in the form of a JSON object with the fields request and response will be sent via the SSE mechanism.
The request contains a request for access, and the response contains a preliminary decision of the ACS about the possibility of access (i.e., a decision after standard checks of the profile, schedule, etc.).
Then the ACS waits for a decision on access to be sent to it via HTTP POST to /access_confirmation indicating the UUID of the request and a decision to let in or not.
Regardless of the ACS decision in response, the external system can let in or not let in.
Methods of interaction with STRAZH {#strazh-methods}
An API is used тo exchange data with the ACS (Table 69).
Table 69. STRAZH methods
| Task | Method | Description |
|---|---|---|
| Log in | POST /api/v1/login/ | Access authorization in ACS. Authorization occurs when adding a service and after the token expires |
| Get information about ACS | GET /api/v1/info | Getting the ACS version to check compatibility and display in the UI. |
| Get employees | GET /api/v1/staff | Replication and synchronization of employees (person_id, full name, photo) from ACS to local storage |
| Get information about an employee | GET /api/v1/staff/{person_id} | Getting employee data from ACS (full name, photo) |
| Get employee photo | GET /api/v1/images/{person_id} | Get employee photo from ACS to send to biometric system |
| Get access points | GET /api/v1/access_points | Get access point (controller) IDs for manual matching of cameras/terminals and access points |
| Open access point | POST /api/v1/request_access | Send signal to controller to grant access. |
| Confirm 2nd factor | POST /api/v1/access_confirmation | Send confirmation to ACS about passing verification by the second factor (photo) |
| Open SSE connection | GET /sse | Open SSE connection to view event queue (reading, updating employee data) |
STRAZH interaction process diagrams {#strazh-diagrams}
Strazh service connection {#strazh-init}
Sequence diagram (Figure 108).
1․ The user added the Strazh service to Access.
2․ Access sends an authorization request to the ACS.
3․ The ACS returns an authorization token. The token has a lifetime, after which Access re-performs authorization.
4․ Access sends a request to obtain information about the ACS.
5․ The ACS returns information. Access uses only the ACS version to check compatibility and user information in the UI.
6․ Access requests information about access points (controllers) connected to the ACS.
7․ The ACS returns the access point IDs.
8․ Access creates StrazhController controllers in accordance with the received IDs.
9․ Access sends a request to obtain information about employees to replicate data to the local storage.
10․ ACS returns person_id, full name and photo.
11․ Access sends a request to open an SSE connection to view the list of events (changes in employees, access).
12․ ACS opens an SSE connection with Access.
Modifying employees in STRAZH ACS {#strazh-staff-edit}
Sequence diagram (Figure 109).
1․ Access views the event queue in ACS via SSE connection.
2․ The employee is changed in ACS (added, changed or deleted).
3․ Access finds events with the CREATE, MODIFY_DATA or DELETE tags in the queue.
4․ Access deletes the employee from the local storage.
5․ Access requests data on the employee by his person_id.
6․ ACS returns the full name and photo of the employee.
7․ Access updates the employee information in the local storage.
Processing STRAZH events with 1 factor {#strazh-1f}
Sequence diagram (Figure 110).
1․ Employee at the biometric terminal at the checkpoint.
2․ Terminal sends the best photo of the employee to Access.
3․ Access sends a photo of the employee to the Biometric System.
4․ BS compares the photo from the terminal and the one saved in the database.
5․ BS returns to Access a decision on granting access.
6․ Access sends a signal to the controller to open the access point.
Processing STRAZH events with 2 factors {#strazh-2f}
Sequence diagram (Figure 111).
1․ Employee at the biometric terminal at the checkpoint.
2․ The terminal sends the best shot of the employee to Access.
3․ Access sends the employee's photo to the Biometric System.
4․ The BS compares the photo from the terminal and the one stored in the database.
5․ The BS returns to Access a decision on granting access.
6․ The employee applies the card (the card use subprocess does not depend on photo processing, but, as a rule, the photo arrives first).
7․ The access point sends information to Access via SSE about the passage (access point ID, passage direction, and person_id).
8․ Access aggregates information about each factor and sends a signal to the controller to open the access point.