Create and manage locks
Before explaining how to start configuring the tenant by installing locks, creating lock groups, and assigning each resident their access permissions, let’s clarify what do we mean by locks and why they are a different thing from previously mentioned Secured Objects.
A lock secures access to a protected resource (room, furniture…) and it’s the entity for which keys are created. Secured Objects refer to the physical component of each lock, i.e.: a cylinder or door handle. Distinguishing between the two allow us to define a lock even if the actual cylinders are not installed yet, or to replace a broken cylinder without having to change the associated lock and generate new keys for all affected residents.
After purchasing locks from BlueID, in the backend the related Secured Objects ID will be available (as cylinders) and it will be possible to create a new lock and assign a cylinder to it.
Cylinders assigned to locks can be deleted to allow replacements in case of malfunctions without the need to have to rewrite all access permissions.
A name and a description can be given to the newly created lock and the lock can be added to a lock group.
Lock groups are group of locks that are logically associated to facilitate the creation of access permissions. Access permission (keys) are, in fact, created for each resident based on the lock groups they have access to. When access permissions are created, multiple tokens at the same time are generated, since there is a one-to-many relationship between lock groups and locks.
Lock Group Types
Lock groups can be classified or categorized via the Lock Group Types feature. Distinction can be made per division (Marketing, Sales…) user type (employees, technicians, fire brigade…) or any other classification that might occur.
The keyplan is a tool which allows batch operations on several locks at the same time (search all unassigned locks, assign multiple locks to a lock group or lock group types for all selected...).
Users & Roles
When we talk about users, we mean the ones for whom an account in the backend is created to manage the tenant, maintain locks, create access permissions. The end users, who interact with locks, are called Residents.
Users are people who have an account to access the backend under a specific tenant. For instance, lock installers need to have access to the backend and to the Lock Admin App to install locks.
Roles are a set of permissions granted to each user to perform actions. Among them: see and edit locks or lock groups, see and edit devices, see and edit residents, see and edit keys (access permissions) and many others.
A Lock installer, for instance, is granted permissions to perform his duties: see locks, edit locks, see lock groups, see lock group types, maintenance of cylinders.
Residents & Devices
Residents are the end users of BlueID Access, people who are granted permissions to open locks of a specific Tenant. Residents are logical entities to group all devices the end user can have. Several devices (smartphones and NFC cards) can be saved under the same Resident.
Devices, on the other hand, are among the most important component of BlueID Access, since Access Tokens are encrypted permissions that associate Secured Objects with Devices. When Residents are invited via BlueID, the initialization of the Keys App automatically transfers the DeviceID to the backend. For NFC cards this procedure happens during the initialization of the NFC card via the BlueID Token Writer app. The first time an NFC card is used, the Token Writer App sends the unique identifier of the card to the backend that stores it and create a DeviceID. This is sent back to the App that uses it to initialize the card. DeviceIDs are unique identifiers of the devices used by Residents to interact with BlueID locks. When a Resident changes mobile phone, or is given a new NFC card, a new invitation is sent, a new initialization happens, and a new DeviceID is added to the backend for that Resident.
Access permissions are the keys which authorize a Resident to open all locks belonging to a lock group. They are valid for a defined period and can be revoked any time by the Tenant’s administrator.
Access permissions are assigned to Residents. If a Resident has more than one device, all of them, once updated with the latest access permission, can be used to open the locks of the lock groups granted.
Best practices & FAQ
What's the best sequence of setting up BlueID Access for a new building? 1. Install physical locks and wall readers 2. Create locks and lock groups in Access (or import them) 3. Create users and assign roles in order to login (frontend, apps) 4. Bind the cylinders to locks using BlueID Lock Admin App 5. Connect mobile devices to Access a. either by sending invitation e-mails to residents, and using BlueID Keys App b. or by using your custom app with our SDK to connect the device to our backend 6. Create keys for residents/lock-groups
For how long should an Access Permission be issued? The shorter the better. Access Permissions can be revoked at any time, but revoked Tokens will remain in the lock’s blacklist storage until their expiration date. Therefore, when too many long-time Tokens are revoked, the lock’s storage will get full. With shorter validity periods this risk is much smaller.
Should I use predefined or customized roles for users? Every Access tenant comes with a set of predefined roles so that you - as a customer - don't have to worry about the correct set of permissions. The most powerful user is the "administrator" who is allowed to view and use all the features we offer. You should limit the access to this role in any case. We highly recommend to use the permissions and roles where necessary. It is possible to operate Access with the predefined roles and limit the permissions to whats necessary at the same time. If the predefined roles do not meet your requirements create your own customized roles and assign them to Users. Take your time to find the best fit in order to prevent misusage of the system.