DE102022105680A1 - User/account management for identification systems - Google Patents

Abstract

A user/account management method for identification systems includes the steps of: reusing an ID from an existing user database (LDAP), packaging the ID into an encrypted token, decrypting the ID from each application, and delegating authentication to LDAP.

Description

Technical area

The invention relates to an identification system based on RFID cards.

State of the art

Nowadays, RFID cards are widely used for authentication. They are reliable, easy to use and comfortable. However, they must be physically transported to a user and can break. There are ideas to replace these with "virtual mobile badges" by placing a unique identifier on a cell phone and using the cell phone's NFC or BLE connection to display the ID information at an interrogation point, such as a mobile phone. B. an RFID reader.

However, systems with RFID cards are often already installed and in operation. If you now want to switch to mobile IDs, the system needs to know which usage gets which mobile ID. This can be done either by assigning new IDs to employees' mobile devices and tracking two IDs (RFID card and mobile device) in the system, or by allowing employees a form of self-registration: once employees have their registered RFID card at a (special) access point, there is an option to present a second ID (e.g. from the phone) and the system adds this second number to the user directory as a secondary authentication ID.

In a typical multi-user application such as access control to a building, the application provider would install a door lock and provide a key that opens the lock for each authorized person. To keep the system functional and secure throughout its lifespan, he would need to set up and maintain a database of users and associated keys. If a new person needs access, a new key is issued and a data record is added to the database. If a key is lost, its ID number is removed from the database to prevent unauthorized access.

If a new multi-user application, e.g. When added, such as secure printing, a new set of keys (in this case in the form of electronic cards) and a new user database are installed.

The number of databases and the administrative effort multiplies by the number of users with each new application. An attentive mind might come up with the idea of unifying the entire user management of the different systems by creating a common database and a common protocol API that can be reused by all systems. However, an even more attentive mind would notice that such a database and protocol already exist and are the de facto standard: Lightweight Directory Access Protocol, or LDAP for short.

What is problematic here, however, is easy-to-use, secure communication with the database in order to manage user accounts.

Presentation of the invention

The invention is based on the object of providing an improved identification system which can manage a larger number of users with reduced effort and enables simplified user account management.

This object is achieved by a device according to claim 1. Advantageous embodiments of the invention are specified in the subclaims.

The invention consists of the idea of how existing user/account management subsystems can be integrated into complete identification systems by retrieving and implementing user/account IDs in the identification, authentication and authorization workflows. The idea allows component providers to build complete systems by reusing existing account management subsystems.

Modern electronic systems that include user management are based on a database of users/accounts. Databases, in turn, use unique IDs for each record. Reusing the unique ID when deploying tokens (e.g. access cards, mobile credentials) for each user avoids the need to build a parallel token management system. The token and user management systems will be unified.

• - Die ID aus der bestehenden Benutzerdatenbank (LDAP) wiederverwenden,
• - sie in ein verschlüsseltes Token verpacken,
• - von jeder Anwendung entschlüsseln lassen und
• - die Authentifizierung an LDAP delegieren.

The invention includes the steps:

• - Reuse the ID from the existing user database (LDAP),
• - wrap them in an encrypted token,
• - have it decrypted by any application and
• - delegate authentication to LDAP.

The invention further includes a device for carrying out this invention.

This means that Single Database Authentication (or SSO, Single Sign-On) is implemented by pure software systems for hybrid systems with hybrid ID tokens.

The idea of building a secure system based on a non-secret ID/token is implemented by securing each step/element of the creation and application chain. The components of the system can be divided into three categories from an ID/token perspective: 1) packaging/conversion, 2) transportation, and 3) application/usage. If each component is secured in relation to the management of the badge/token, the entire system is secure, even if the underlying badge/token is insecure (not secret). A parallel can be drawn with personal biometric data, its storage in a passport and its use at automated passport checkpoints. The personal data is the non-secret ID card/token; storing them in a passport is 1) packaging/forming; the reading at the automated gate is 2) transport and the comparison with the camera image of the real person at the gate is 3) application/use.

In this idea, 1) wrapping/transforming is implemented securely by generating an encrypted token from the ID with a key known only in component 3; 2) the transport is implemented securely using a point-to-point encryption technology (e.g. SSL/TLS) and 3) the application/use is secured by retrieving the underlying ID with the key used in Component 1.

The login server has a configuration module that stores the configuration of the LDAP server (DNS address, directory schema). It is set up as a pass-through credential server for authentication (in LDAP terms, “binding”) to the LDAP server. After successful authentication, the user's UUID is retrieved.

The LDAP UUID is now used throughout the multi-user application as an ID, key, card number, or virtual credential ID. The advantage of this idea can be seen in the diagram: the backend systems are unified. You do not need any separate user administration. The same user can be authenticated and authorized in multiple systems, but user management only needs to be done once.

The definition of first-level authorization - which user is allowed to use which application - is implemented in the LDAP server through the concept of groups. A new group is defined for each application. The group identifier is stored in the application configuration module and used as a filter in the identification process. If the user's credentials identify them as a member of the group defined for the application, the authentication process is started. Otherwise, the user will be informed that he is not authorized to use the application.

The application can be deployed on a cloud PaaS (Platform-as-a-Service) or on-premises. On-site deployment can in turn take place on an existing server or on a dedicated server (e.g. Elatec TCPConv) that is connected to the existing network.

Reusing an existing ID from an existing user database/directory is new; Well-known applications add their own user management with their own IDs. The source of the ID is not limited to LDAP; any user database with an API can be used.

Retrieving the ID by authenticating the user with their pre-existing LDAP or other user directory server credentials is new.

The role of an existing ID within a single application as an identification token is new; well-known applications define their own numbers/IDs/tokens.

Sharing the existing ID among other applications is new; So far the applications are independent and define independent IDs.

The use of groups to map database attributes to applications is new; this enables automatic user authorization in any application by adding the user to a group in the directory.

Building a secure system with a non-secret ID/token, as described in 4.5, is new. Known/existing systems attempt to ensure security by keeping the ID secret. A secret ID is tied to only one system, meaning different IDs for the same person in different systems forced. This idea allows systems to be interoperable by reusing an ID in a secure way.

All of the above options can be combined with each other as desired.

Some important terms are explained in more detail below. Identification: Assignment of a physical person to a data record in a computer system via an identification feature, e.g. B. an ID number

Authentication: ensuring that the person submitting an identification token is actually the owner of the token; e.g. through a secret password

Authorization: Assignment of the authenticated person to a business role that is allowed to carry out an action, e.g. open a door, execute a print job

Description of the drawings

• 1 zeigt ein Blockdiagramm der Erfindung.
• 2 zeigt eine typische Software-Umgebung eines Computernetzes.
• 3 zeigt eine multifunktionale, hybride Umgebung mit mobilen Ids.
• 4 zeigt eine Lösung des Problems aus 3.
• 5 zeigt ein Diagramm eines ID-Abrufs.
• 6 zeigt einen ID/Ausweis-Fluss in der Anwendungsumgebung.
• 7 zeigt eine Implementierung der Autorisierung mit LDAP.
• 8 zeigt eine Bereitstellung bei einem Vor-Ort-Einsatz.
• 9 zeigt eine Bereitstellung bei einem Einsatz in der Cloud.

The invention is described below by way of example without restricting the general inventive concept using exemplary embodiments with reference to the drawings.

• 1 shows a block diagram of the invention.
• 2 shows a typical software environment of a computer network.
• 3 shows a multifunctional, hybrid environment with mobile IDs.
• 4 shows a solution to the problem 3 .
• 5 shows a diagram of an ID retrieval.
• 6 shows an ID/badge flow in the application environment.
• 7 shows an implementation of authorization with LDAP.
• 8th shows a deployment during an on-site deployment.
• 9 shows a deployment when used in the cloud.

1 shows a block diagram of the invention. The LDAP UUID is an immutable value or number that remains the same for each account throughout the life of the database. A second property of the UUID is that it is not secret. Any user with read access rights to the database can read other users' UUlDs. The use of the UUID therefore represents an additional problem for security-sensitive systems, for which this idea also offers a solution (see 4.5 Ensuring the secure use of the UUID).

Almost every modern electronic user management system uses or implements LDAP in the form of a database running on a physical server. An LDAP database record has a Universally Unique ID (UUID). The UUID of a record is guaranteed to be immutable. The protocol allows querying the UUID by authenticating to the server as the user to whom the record belongs.

2 shows a typical software environment of a computer network with multiple applications in which username and password are used, ie pure software identification tokens

3 shows a multifunctional, hybrid environment with mobile IDs, i.e. hybrid ID tokens (partly physical, partly software). Problem: Multiple databases duplicating nearly the same data, each creating their own IDs; multiplied administrative needs.

4 shows a realization of the invention and thus a solution to the problem 3 . Reuse the ID from the existing user database (LDAP), wrap it in an encrypted token, have any application decrypt it, and delegate authentication to LDAP. This means that Single Database Authentication (or SSO, Single Sign-On) is used by pure software systems ( ) implemented for hybrid systems with hybrid ID tokens.

5 shows a diagram of an ID retrieval application server - LDAP server authentication and communication. The login server has a configuration module that stores the configuration of the LDAP server (DNS address, directory schema). It is set up as a pass-through credential server for authentication (in LDAP terms, “binding”) to the LDAP server. After successful authentication, the user's UUID is retrieved.

6 shows an ID/credential flow in the application environment and the use of the ID in the application(s). The LDAP UUID is now used throughout the multi-user application as an ID, key, card number, or virtual credential ID. The advantage of this idea can be seen in the diagram: the backend systems are unified. You do not need any separate user administration. The same user can be authenticated in multiple systems and authorized, but user management only needs to be done once.

7 shows an implementation of authorization with LDAP. The definition of first-level authorization - which user is allowed to use which application - is implemented in the LDAP server through the concept of groups. A new group is defined for each application. The group identifier is set in the application configuration module (configuration module). 5 ) is stored and used as a filter in the identification process. If the user's credentials identify them as a member of the group defined for the application, the authentication process is started. Otherwise, the user will be informed that he is not authorized to use the application.

8th shows a deployment during an on-site deployment. 9 shows a deployment when used in the cloud. The application can be deployed on a cloud PaaS (Platform-as-a-Service) or on-premises. On-premises deployment can again be done on an existing server or on a dedicated server (e.g. Elatec TCPConv) connected to the existing network.

Claims (11)

Procedure for user/account management for identification systems comprising the steps: - reusing an ID from an existing user database (LDAP), - pack the ID into an encrypted token, - decrypt the ID of each application, and - delegate authentication to LDAP. Procedure according to Claim 1 , comprising the next step: - adding your own user management with your own IDs through well-known applications. Method according to one of the preceding claims, wherein the source of the ID is not limited to LDAP. Method according to one of the preceding claims, wherein each user database can be used with an API. Method according to one of the preceding claims, wherein the ID is retrieved by authenticating the user with his existing login data from the LDAP or another user directory server. Method according to one of the preceding claims, wherein an existing ID takes on the role within a single application as an identification token. Method according to one of the preceding claims, wherein known applications define their own numbers/IDs/tokens. Method according to one of the preceding claims, wherein the existing ID is shared by other applications. Method according to one of the preceding claims, wherein the use of groups for the assignment of database attributes to applications takes place by sharing the existing ID among other applications. Method according to one of the preceding claims, wherein the construction of a secure system takes place with a non-secret ID/a non-secret token. Device comprising a user database for carrying out the method according to at least one of the preceding claims.

Images