Open

Installation Manual | IM-202401XX iProtect Access / Security | Functionalities Open

Table of contents

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.

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.

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:

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.

7. Extensive information

7.1 Reader dialog details

7.2 DOMConnect Manual

Open