IPROTECT Access - DOMBox API-integration
Installation Manual | IM-202401XX iProtect Access / Security | Functionalities |
|
Table of contents
- 1 Table of contents
- 2 1. Introduction
- 3 2. Support
- 3.1 2.1 Hardware and licence
- 3.2 2.2 RFID card type support
- 3.3 2.3 Supported features
- 3.4 2.4 Known not supported features
- 3.5 2.5 Data on card and Mobile access
- 3.5.1 2.5.1 MIFARE DESFire RFID
- 3.5.1.1 2.5.1.1 Standard OSS Application
- 3.5.2 2.5.2 Mobile device
- 3.5.1 2.5.1 MIFARE DESFire RFID
- 3.6 2.6 OSS Events
- 3.7 2.7 System architecture
- 4 3. DOM Service app
- 5 4. IPROTECT
- 5.1 4.1 Presets
- 5.2 4.2 Provisioner
- 5.3 4.3 Card coding
- 5.4 4.4 Hardware used for update and enrollment of OSS cards
- 5.5 4.5 Add the DOM controller
- 5.6 4.6 Add offline device
- 5.6.1 4.6.1 Add device
- 5.6.1.1 4.6.1.2 Link to existing reader
- 5.6.1.1.1 4.6.1.2.1 DOM Service app
- 5.6.1.2 4.6.1.3 Link to a new reader
- 5.6.1.2.1 4.6.1.3.1 DOM Service app
- 5.6.1.1 4.6.1.2 Link to existing reader
- 5.6.1 4.6.1 Add device
- 5.7 4.7 Lock sensor
- 5.8 4.8 Add online device
- 6 5. Configuration management
- 7 6. Migrating from A1/B1 to DOM API-implementation
- 8 7. Extensive information
1. Introduction
The use of cards or tags with Mifare® DESFire® technology in combination with battery-powered locks, such as door handles or door cylinders, is already widely used. TKH-Security has a close collaboration with DOM and together we have developed a solution to gain access to both wired and battery-powered locks with a Mobile device.
This manual describes only the use of a network-connected DOM controller (Bridge). When using an XML import/export, based on OSS version A1 or B1, please refer to another user manual.
Available in iProtect as of version 10.4.xx
For setting up the system for using access control, in combination with a desfire card and with mobile access, please refer to another user manual. This manual describes how to add DOM (OSS and Mobile Access) to a working system.
1.1 The Solution
IPROTECT connects to the DOM controller(s) based on a REST API. The connection works in real time, so both systems are always fully synchronized and there is no need to use old-fashioned XML import and export files (although this option will of course still exist).
When using DOM ENIQ hardware, the system is already prepared as standard for the use of "data on card", but also for mobile access. Using a mobile key makes it very flexible and easy. This applies not only to the use, but also to the creation and assignment of rights to locks and persons.
1.2 Features and Benefits DOMBox API-integration
The iProtect - DOM REST API is a new way to connect that greatly improves the A1/B1 setup. It brings new features to help both users and administrators.
It's important to note that switching from A1/B1 to the API is not mandatory.
The A1/B1 setup will still work as it always has. However, the API setup provides many extra benefits and features that can make the overall experience better.
Below are the key benefits of the iProtect - DOM REST API:
Support for multiple DOM controllers: Users can manage several DOM controllers at the same time, making security management more flexible and scalable.
IPROTECT ACCESS (mobile access): Users can conveniently access the offline devices from their mobile phones, enabling them to utilize a single mobile identifier for both online and offline locks.
Compatibility with DOM RF Netmanager: The API works well with the DOM RF Netmanager, making it easy to update lock configurations and send door commands, which improves efficiency.
Real-time synchronization of OSS configuration data: Configuration data changes are instantly updated across all systems, minimizing errors and ensuring that everyone has the most current configuration status of the locks.
Real-time synchronization of OSS device status: Users can continuously monitor the status of their devices, allowing for quick responses to any problems.
Ability to add temporary DOM controller users (APP USERS): Administrators can easily add or remove users who need temporary access, like contractors who need to implement a new lock, improving security without losing convenience.
Automation of DOM controller backup and restore processes: Automating these processes helps prevent configuration data loss and ensures backups are regularly maintained.
Provisioning of AES DESFire keys to the Bridge: This feature allows for secure sharing of encryption keys. It sends the encryption keys and configurations from the iProtect system to the bridge, with the key encrypted in a KTL file (keystore).
Installation of discovery function processes: The API can automatically find new devices from the bridge and link those devices to the correct readers, making the setup process easier and faster.
In summary, the A1/B1 setup remains unchanged, but the iProtect - DOM REST API introduces key enhancements that improve functionality, security, and user experience.
2. Support
2.1 Hardware and licence
2.2 RFID card type support
2.3 Supported features
2.5 Data on card and Mobile access
2.6 OSS Events
2.7 System architecture
3. DOM Service app
4. IPROTECT
iProtect supports the OSS, standard offline access application by means that it can enroll or update
cards which are confirmed to the standard data on card solution. The OSS offline standard is a data on card
standard in which the access profiles are distributed via the access cards instead of online card readers. This
is also called: “native” or “offline”, because the access rights are defined in the iProtect database itself and are
distributed to the Sirius i-Serie update readers.
Supporting OSS does not mean that every lock can be integrated effortless since this part is not standardized. This manual only describes the DOM OSS manufacturer.
4.1 Presets
To begin the installation, you must first have the correct key and configuration files.
Items required before the steps below can be performed:
File type | Type | Comment |
---|---|---|
OSS update.xml | Reader provisioner | Card number based on AID or UID |
OSS enroll.xml | Reader provisioner | PMK dependency (AES, 3DES) and card number based on AID or UID |
OSS.xml | Node provisioner | Customer specific, supplied by TKH-Security B.V. |
OSS.ktl | Node and reader provisioner | Customer specific, supplied by TKH-Security B.V. |
4.2 Provisioner
A provisioner group consists of one or more elements. These elements can be configurations, key files or firmware.
The sections below describe the required combinations.
4.3 Card coding
4.4 Hardware used for update and enrollment of OSS cards
4.5 Add the DOM controller
4.6 Add offline device
Using DOM OSS, the device is always linked to a door (a card reader in iProtect). Access rights are then associated with the card reader.
DOM devices such as ENIQPro or ENIQGuard, for example, are added to the system using the DOM Service app.
4.7 Lock sensor
4.8 Add online device
To change the offline device into an online device, a RF-NetManager is required.
The RF-NetManager needs to be configured using the DOMPloy software, please consult the DOMConnect manual and go to next chapter "Configure and deploy a RFNM".
5. Configuration management
5.1 Offline devices
The following section uses the DOM Service App
5.2 Online devices
The following section uses the RF-NetManager. The DOM service app is not needed.
6. Migrating from A1/B1 to DOM API-implementation
To take advantage of the new API-implementation and hereby the benefits (see Chapter 1.2), the OSS configuration in IPROTECT must be changed.