Computer-implemented role management procedure and associated system

Abstract

Computer-implemented role management procedure for at least one service (S1, S2, S3), in particular a microservice, in a distributed system environment, wherein this procedure comprises the following process steps: - Providing, by an entity providing an authentication service (AS), a look-up table (LUT0, LUT1) for the at least one service over a predefinable usage period, wherein the look-up table includes role names and their respective associated bit numbers, wherein the roles express one or more authorizations to use the at least one service by at least one user, and the bit number refers to a defined bit in the payload of an authentication token, which is used to identify the service authorization of the at least one user. - Sending a request to subscribe to one or more such services for a subscription period, wherein the request includes such an authentication token, - Comparison, by the aforementioned body, using the look-up table, to determine whether at least one bit set in the user data of the authentication token corresponds to a role that permits at least one service and whether the subscription period falls within or corresponds to the usage period. - the look-up table is updated when at least one additional bit number relating to such a defined bit has been added or removed, - Allowing the requested subscription if the matching is successful, and - otherwise, the requested subscription will be rejected.

Description

[0001] The invention relates to a computer-implemented role management method and associated system as well as an associated computer program (product).

[0002] Virtually all microservice architectures, such as those used in industrial environments as part of digitalization, employ role-based access methods. Microservices are a type of application architecture in which a collection of independent services communicates with each other via lean application programming interfaces (APLs). These access methods can utilize an external authentication service that provides the functionalities permitted for a specific or definable user group. A common way to define or grant users rights or access to resources or services is to categorize users into user groups. Roles are then assigned to these groups, and rights or permissions are granted to these roles. Authentication tokens are frequently used for authentication in such scenarios.If the user is logged in, each subsequent request will contain the token that allows the user to access services authorized by that token.

[0003] As the number of roles held by a user increases, a problem arises: the number of authentication tokens also grows. One example of an authentication token is a JWT (JSON Web Token), which is described in RFC 7519 (RFC 7519: JSON Web Token (JWT) (rfc-editor.org)).

[0004] According to Wikipedia, JWT enables the exchange of verifiable claims. A claim has a claim name and a value.

[0005] It is typically used to exchange a user's identity between an authentication server / service and a service provider in a system with a third-party provider.

[0006] A JWT consists of three parts: a header, payload, and a signature: Header: The header typically consists of two parts: the token type (JWT) and the algorithm used, e.g., HMAC SHA256 or RSA SHA256. The header is Base64 encoded to form the first part of the JWT. According to Wikipedia, Base64 is a method for encoding 8-bit binary data (e.g., executable programs, ZIP files, or images) into a string. A variation of Base64 is Base64Url, which is used, for example, to encode URLs and filenames. Payload: The payload contains the so-called claims. There is a group of registered claims, such as iss (issuer), exp (expiration time), sub (subject), and aud (target audience). These claims are not mandatory but are recommended to provide a set of useful, interoperable claims. The payload can also contain additional attributes that define customized claims, such as an employee role. The "subject" claim is frequently used. The payload is Base64 encoded to form the second part of the JWT. Top: To create the signature section, the encoded header and the encoded payload are signed using the signature algorithm from the header. The signature is used to verify that the issuer of the JWT is the correct person and to ensure that the message has not been altered in transit.

[0007] The JWT standard does not define the format (i.e., the claim) in which group information expressed as roles can be stored. An example role definition looks like this (https: / / entwickler.de / java / enterprisetales-autorisierung-mit-dem-json-web-token-in-enterprisejava):"realm_access": { "roles": [ "customer", "power-user" ]

[0008] If an authentication server wants to store this information in the token, it is free to choose how it does so. Since there is no standard for storing user groups, every service that wants to use this information must be adapted to the structure of the respective authentication server.

[0009] The size of JWT tokens increases with the encoding of roles within the JWT. Alternatively, roles can be implemented in a translation layer, which a service must query to obtain the roles. This generates significant overhead and a distributed state that requires continuous updating. The JWT can be transmitted in a URL or in the HTTP header. However, some (micro)services typically only allow tokens in the kilobyte range. If each role is encoded in the JWT, the size can quickly reach several megabytes. This can then become problematic in an HTTP header.

[0010] Document WO 2021 / 045727 A1 describes a method for managing user roles in a distributed system. Role information is encoded in a token and used to authorize access to services. However, the solution described therein has limitations regarding flexibility and scalability when dealing with a large number of roles and diverse services.

[0011] The object of the present invention is to improve a method and a device compared to the above-mentioned prior art, particularly in an industrial environment, in such a way that the effort or overhead associated with authentication tokens is kept as low as possible.

[0012] The problem is solved by the features specified in the independent claims. Advantageous embodiments of the invention are described in the dependent claims.

[0013] The invention relates to a role management method for at least one service, in particular a microservice, in a distributed system environment, wherein this method comprises the following process steps: - Providing, by an entity providing an authentication service, preferably a server, a look-up table for the at least one service over a predefinable usage period, wherein the look-up table includes role names and their respective associated bit numbers, wherein the roles express one or more authorizations to use the at least one service by at least one user and the bit number refers to a defined bit in the payload of an authentication token, which is used to identify the service authorization of the at least one user, - Sending a request to subscribe to one or more such services for a subscription period, wherein the request includes such an authentication token, - Comparison, by the aforementioned body, using the look-up table, to determine whether at least one bit set in the user data of the authentication token corresponds to a role that permits at least one service and whether the subscription period falls within or corresponds to the usage period. - the look-up table is updated when at least one additional bit number relating to such a defined bit has been added or removed, - Allowing the requested subscription if the matching is successful, and - otherwise, the requested subscription will be rejected.

[0014] The look-up table is preferably updated once more before the start of a subscription period.

[0015] The aforementioned process steps are preferably performed server-side. Sending the request is preferably performed client-side. According to the invention, a lookup table (LUT) or append table for the role names is used, the content of which is managed by the respective service. This LUT is provided by a (central) authentication service. This LUT is only appended during subscription periods, also called epochs. A service that does not change its roles does not need to update its LUT configuration. Only services that change their role management / allocation incur additional communication overhead with the authentication service.

[0016] Another aspect of the invention is a role management system for at least one service, in particular a microservice, in a distributed system environment, comprising components controllable and / or executable by one or more processors, which are designed for the following operations: - Providing, by an entity providing an authentication service, a look-up table for the at least one service over a predefinable usage period, wherein the look-up table includes role names and their respective associated bit numbers, wherein the roles express one or more authorizations to use the at least one service by at least one user and the bit number refers to a defined bit in the payload of an authentication token, which is used to identify the service authorization of the at least one user, - Sending a request to subscribe to one or more such services for a subscription period, wherein the request includes such an authentication token, - Comparison, by the aforementioned body, using the look-up table, to determine whether at least one bit set in the user data of the authentication token corresponds to a role that permits at least one service and whether the subscription period falls within or corresponds to the usage period. - the look-up table is updated when at least one additional bit number relating to such a defined bit has been added or removed, - Allowing the requested subscription if the matching is successful, and - otherwise, the requested subscription will be rejected.

[0017] The components can be hardware, firmware and / or software components, units or modules.

[0018] The system or device and the computer program (product) can be designed or further developed according to the procedure described above or the further developments / implementations of the present procedure.

[0019] Advantages of the invention are: - It is not necessary to constantly query an API unless the service's role management has changed. - Instead of adding each role as a string, each bit represents a role, reducing the size by 8 times the average size of the role names. - A service cannot implement all of the user's roles because it does not have access to the entire LUT, but only to the relevant part.

[0020] Furthermore, a computer program (product) comprises program code that can be executed by at least one processor and that causes the at least one processor to execute the operating method and its embodiments according to the invention. The computer program can run on a computer, e.g., in the cloud, on a server, and / or on a PC, or be stored as a computer program product on a computer-readable medium. The computer program then initiates the execution of the runtime environment.

[0021] Additionally, a variant of the computer program (product) can include program commands for configuring a production device, for example a 3D printer, a computer system, or a manufacturing machine suitable for creating processors and / or devices.

[0022] Unless otherwise specified in the following description, the terms "perform," "calculate," "computer-aided," "compute," "determine," "generate," "configure," "reconstruct," and the like preferably refer to actions and / or processes and / or processing steps that modify and / or generate data and / or convert data into other data, wherein the data may be represented or exist as physical quantities, for example, as electrical impulses. In particular, the term "computer" should be interpreted as broadly as possible to encompass all electronic devices with data processing capabilities.Computers can therefore be, for example, personal computers, servers, programmable logic controllers (PLCs), handheld computer systems, pocket PC devices, mobile phones and other communication devices that can process data using a computer, processors and other electronic devices for data processing.

[0023] In the context of the invention, "computer-aided" or "computer-implemented" can, for example, be understood to mean an implementation of the method in which, in particular, a processor performs at least one process step of the method.

[0024] Provisioning can be understood as making the application and / or capability packages themselves available to the aforementioned means, e.g., in the form of a processing unit (CPU) or a control unit. Provisioning can also be understood as providing an operation to the processing unit, where the operation can be the provisioned application itself and / or the capability packages used to control and / or execute the configuration.

[0025] The properties, features, and advantages of this invention described above, as well as the manner in which they are achieved, will become clearer and more readily understandable in connection with the following description of the exemplary embodiments, which are explained in more detail in conjunction with the figures. These show: The figure shows an example scenario for the procedure according to the invention.

[0026] The figure shows an example scenario in a distributed system environment, which characteristically includes client and server or cloud.

[0027] In this example, user U uses services S1, S2, and S3, using the same token for each service. The token is then passed to an authentication service AS.

[0028] The core of the invention is the use of a so-called Look-Up Table (LUT) for role names.

[0029] The roles are then bitwise encoded. Based on the example mentioned at the beginning, access to a LUT is defined: "lut_access" : { epoch: 1, "roles": "wA=="} and the LUT is stored in or for the authentication service, which then assigns the roles as follows: bit 0 => customer, bit 1 => power-user

[0030] The diagram illustrates two consecutive epochs, labeled Epoch 0 and Epoch 1, along with another example of the mapping between role names and bit numbers. The corresponding mappings for Epoch 0 are found in the depicted lookup table LUT0, and those for Epoch 1 are found in the lookup table LUT1. Each service learns which bit number corresponds to which role. When changes occur in the role management, the corresponding service subscribes to an epoch. This LUT is only provided during epochs, such as Epoch 0 and 1 (periods starting from a predefined system / start time), when changes occur in the role management. Only services that modify their role management incur additional communication overhead with the authentication service.

[0031] Therefore, a service that does not change its roles does not need to update its configuration. Only services that change their role management incur additional communication overhead with the authentication service.

[0032] When a user requests a service subscription on the client side, the user's roles are compared with the roles permitted for the service. The LUT (Layout Note Type) is used for this comparison.

[0033] If the verification is successful, the subscription will be approved. Otherwise, the subscription will be rejected.

[0034] If we take an example with many roles, see below with 40 roles, then the token grows enormously: "realm_access": { "roles": [ role-0, role-1, role-2, role-3, role-4, role-5, role-6, role-7, role-8, role-9, role-10, role-11, role-12, role-13, role-14, role-15, role-16, role-17, role-18, role-19, role-20, role-21, role-22, role-23, role-24, role-25, role-26, role-27, role-28, role-29, role-30, role-31, role-32, role-33, role-34, role-35, role-36, role-37, role-38, role-39 ]

[0035] These 40 rolls can be coded with just a few characters according to the invention.

[0036] If all roles are to be applied, e.g.: "lut_access" : { epoch: 1, "roles": " / / / / / / 8="

[0037] If only a few roles are to be applied, e.g.: "lut_access" : { epoch: 1, "roles": " / 3 / / 9 / 8="

[0038] This allows the token size to be kept small. Therefore, sending all roles within the token involves less operational effort.

[0039] Although the invention has been illustrated and described in detail by the preferred embodiment, the invention is not limited by the disclosed examples and other variations can be derived by the person skilled in the art without leaving the scope of protection of the invention.

[0040] The implementation of the procedures described above can be carried out using instructions stored on computer-readable storage media or in volatile computer memory (hereinafter collectively referred to as computer-readable memory). Examples of computer-readable memory include volatile memory such as caches, buffers, or RAM, as well as non-volatile memory such as removable media, hard drives, etc.

[0041] The functions or process steps described above can be represented in the form of at least one instruction set in / on computer-readable memory. These functions or steps are not bound to a specific instruction set, a specific form of instruction sets, a specific storage medium, a specific processor, or specific execution schemes, and can be executed by software, firmware, microcode, hardware, processors, integrated circuits, etc., either independently or in any combination. Various processing strategies can be employed, such as serial processing by a single processor, multiprocessing, multitasking, or parallel processing, etc.

[0042] The instructions can be stored in local or central storage, but it is also possible to store the instructions on a remote system and access them via a network.

[0043] The terms "processor," "central signal processing unit," "computing unit," "control unit," or "data processing device," as used here, encompass processing devices in the broadest sense, including, for example, servers, general-purpose processors, graphics processors, digital signal processors, application-specific integrated circuits (ASICs), programmable logic circuits such as FPGAs, discrete analog or digital circuits, and any combination thereof, including all other processing devices known to those skilled in the art or which may be developed in the future. Processors can consist of one or more units or devices, which may be integrated into a single device. If a processor consists of multiple units, these can be designed or configured for parallel or sequential processing or execution of instructions.

Claims

[1] Computer-implemented role management procedure for at least one service (S1, S2, S3), in particular a microservice, in a distributed system environment, wherein this procedure comprises the following process steps: - Providing, by an entity providing an authentication service (AS), a look-up table (LUT0, LUT1) for the at least one service over a predefinable usage period, wherein the look-up table includes role names and their respective associated bit numbers, wherein the roles express one or more authorizations to use the at least one service by at least one user, and the bit number refers to a defined bit in the payload of an authentication token, which is used to identify the service authorization of the at least one user. - Sending a request to subscribe to one or more such services for a subscription period, wherein the request includes such an authentication token, - Comparison, by the aforementioned body, using the look-up table, to determine whether at least one bit set in the user data of the authentication token corresponds to a role that permits at least one service and whether the subscription period falls within or corresponds to the usage period. - the look-up table is updated when at least one additional bit number relating to such a defined bit has been added or removed, - Allowing the requested subscription if the matching is successful, and - otherwise, the requested subscription will be rejected. [2] Method according to the preceding claim, characterized by, that the look-up table is updated once more before the start of a subscription period. [3] A role management system for at least one service (S1, S2, S3), in particular a microservice, in a distributed system environment, comprising components controllable and / or executable by one or more processors, designed to perform the following operations: - Providing, by an entity providing an authentication service (AS), a look-up table (LUT0, LUT1) for the at least one service over a predefinable usage period, wherein the look-up table includes role names and their respective associated bit numbers, wherein the roles express one or more authorizations to use the at least one service by at least one user, and the bit number refers to a defined bit in the payload of an authentication token, which is used to identify the service authorization of the at least one user. - Sending a request to subscribe to one or more such services for a subscription period, wherein the request includes such an authentication token, - Comparison, by the aforementioned body, using the look-up table, to determine whether at least one bit set in the user data of the authentication token corresponds to a role that permits at least one service and whether the subscription period falls within or corresponds to the usage period. - the look-up table is updated when at least one additional bit number relating to such a defined bit has been added or removed, - Allowing the requested subscription if the matching is successful, and - otherwise, the requested subscription will be rejected. [4] System according to the preceding claim, characterized by , that the look-up table is updated once more before the start of a subscription period. [5] Computer program that can be loaded into a memory of a computer, in particular the system according to one of the preceding system claims, comprising program code parts designed to execute the method according to one of the preceding method claims.

Images