Electronic access control system and method for operating an electronic access control system

Abstract

The invention relates to an Open ID Connect electronic access control system. An electronic access control system for a device is provided. An OACS gateway is configured to obtain, via an OACS client, a request for the OACS gateway to issue a service ticket for a user agent. The OACS gateway is configured to obtain, via an OIDC client, a profile for the user agent from an OIDC provider and an access control list for the profile and the device. The OACS gateway is configured to generate a service ticket authenticating one-time access of the user agent to a service in response to having confirmed that the profile satisfies permissions to access the service on the device by checking the access control list for the profile and the device and by checking the profile itself. The OACS gateway is configured to provide the service ticket to the user agent via the OACS client.

Description

Technical Field

[0001] The embodiments presented herein relate to technologies for electronic access control systems for operating equipment. Background Technology

[0002] Generally speaking, the term Access Control (AC) refers to the selective restriction of end-user access to places or other resources, such as services or devices. Here, the actual act of accessing a place or other resource can mean entering a location, consuming or acquiring some data, or using or configuring some equipment, etc. The permission to access a resource can be called authorization. Lockout and login credentials are two similar access control mechanisms.

[0003] Technology used for Electronic Access Control (EAC) employs computers to overcome the limitations of mechanical locks and keys. A wide range of credentials can be used to replace mechanical keys. The EAC system grants access permissions to end users based on the presented credentials. When access is granted, the door may unlock within a predetermined time, or the end user may access some requested data or services. When access is denied, the door remains locked, or the end user is prevented from accessing the requested data or services.

[0004] Credentials are physical / tangible objects, knowledge, or aspects of a person that enable an individual to access a given physical facility or computer-based information system.

[0005] For local role-based electronic access control systems, it is required that the representation of credentials be directly installed on each individual device whose access is controlled. This is necessary so that the credentials presented by the end user can be checked when access control is implemented. For example, the value derived from the credentials using a one-way transformation function such as a cryptographic hash function is stored. Furthermore, a limited number of different selectable roles does not allow for fine-tuning of access permissions. Still further, roles are not only limited in number, but they are also fixed and immutable. Summary of the Invention

[0006] The purpose of the embodiments described herein is to address the aforementioned drawbacks of role-based electronic access control systems.

[0007] According to a first aspect, an electronic access control system for a device is proposed. The electronic access control system includes an OACS client and an OACS gateway to an OIDC provider. The OACS gateway implements the OIDC client. The OACS gateway is configured to obtain, via the OACS client, a request for the OACS gateway to issue a service ticket to a user agent. The request includes an indication that the user agent requests access to a service on the device. The service is associated with a license. The OACS gateway is configured to obtain, via the OIDC client, a profile for the user agent and an access control list for the profile and the device from the OIDC provider. The OACS gateway is configured to generate a service ticket verifying one-time access to the service by the user agent, in response to confirming by checking the access control list for the profile and the device and by checking the profile itself that the profile satisfies the license to access the service on the device. The service ticket is a token signed by the OACS gateway. The OACS gateway is configured to provide the service ticket to the user agent via the OACS client.

[0008] According to the second aspect, a method for an electronic access control system for operating equipment is proposed. The electronic access control system includes an OACS client and an OACS gateway to an OIDC provider. The OACS gateway implements the OIDC client. The method is performed by the OACS gateway. The method includes obtaining a request via the OACS client for the OACS gateway to issue a service ticket to a user agent. The request includes an indication that the user agent requests access to a service on the equipment. The service is associated with a license. The method includes obtaining a profile for the user agent and an access control list for the profile and the equipment from the OIDC provider via the OIDC client. The method includes generating a service ticket that verifies one-time access to the service by the user agent by checking the access control list for the profile and the equipment and by checking the profile itself. The service ticket is a token signed by the OACS gateway. The method includes providing the service ticket to the user agent via the OACS client.

[0009] According to a third aspect, a computer program for an electronic access control system for operating equipment is proposed. The electronic access control system includes an OACS client and an OACS gateway to an OIDC provider. The OACS gateway implements the OIDC client. The computer program includes computer code that, when executed on the processing circuitry of the OACS gateway, causes the OACS gateway to perform actions. One action includes the OACS gateway obtaining, via the OACS client, a request for the OACS gateway to issue a service ticket to a user agent. The request includes an indication that the user agent requests access to a service on the equipment. The service is associated with a license. Another action includes the OACS gateway obtaining, via the OIDC client, a profile for the user agent and an access control list for the profile and the equipment from the OIDC provider. An action includes the OACS gateway generating a service ticket verifying a one-time access to the service by checking the access control list for the profile and the equipment and by checking the profile itself to confirm that the profile satisfies the license for accessing the service on the equipment. An action includes the OACS gateway providing the service ticket to the user agent via the OACS client.

[0010] According to the fourth aspect, a computer program product is proposed, comprising the computer program according to the third aspect and a computer-readable storage medium storing the computer program. The computer-readable storage medium may be a non-transitory computer-readable storage medium.

[0011] Advantageously, these aspects overcome the aforementioned drawbacks of role-based electronic access control systems.

[0012] Advantageously, these aspects enable the creation of new roles.

[0013] Other objects, features and advantages of the appended embodiments will be apparent from the detailed disclosure below, from the appended dependent claims and from the drawings.

[0014] Generally, unless otherwise expressly defined herein, all terms used in the claims shall be interpreted according to their ordinary meaning in the art. Unless otherwise expressly stated, all references to “a / the element, device, component, method, module, step, etc.” shall be openly interpreted as referring to at least one instance of an element, device, component, method, module, step, etc. Unless expressly stated otherwise, the steps of any method disclosed herein need not be performed in the precise order disclosed. Attached Figure Description

[0015] The inventive concept will now be described by way of example with reference to the accompanying drawings, in which:

[0016] Figure 1 This is a schematic diagram illustrating a network architecture according to an embodiment;

[0017] Figure 2 An example of an operator configuration file according to an embodiment is illustrated schematically;

[0018] Figure 3 The illustration schematically depicts an example OACS architecture according to an embodiment;

[0019] Figure 4 An example of a service ticket according to an embodiment is illustrated schematically;

[0020] Figure 5 This is a flowchart of the method according to the embodiment;

[0021] Figure 6 , Figure 8 and Figure 11 This is a block diagram according to an embodiment;

[0022] Figure 7 , Figure 9 , Figure 10 and Figure 12 This is a signaling diagram of the method according to the embodiment;

[0023] Figure 13 This is a schematic diagram illustrating the functional units of an electronic access control system according to an embodiment;

[0024] Figure 14 An example of a computer program product including a computer-readable storage medium according to an embodiment is shown. Detailed Implementation

[0025] The inventive concept will now be described more fully below with reference to the accompanying drawings, in which certain embodiments of the inventive concept are illustrated. However, the inventive concept can be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Throughout the specification, the same numerals refer to the same elements. Any step or feature illustrated by dashed lines should be considered optional.

[0026] definition

[0027] The following definitions (listed alphabetically) will be useful in the description below.

[0028] Access token: A token used to authorize access to a specific resource.

[0029] A claim is a statement about the scope. It can be dynamically assigned or statically mapped from an external source.

[0030] Client key: A persistent private key used for signing tokens for client authentication. The public portion of the client key is registered by the OIDC provider for the client.

[0031] D-bus: Inter-process communication protocol.

[0032] External services: Any service that can be accessed from outside the device.

[0033] JWT: JSON (JavaScript Object Notation) Web Token.

[0034] OACS: An abbreviation for OIDC Electronic Access Control System, which uses JWT to implement a configuration file-based access control solution.

[0035] OACS Conf: The configuration file used by the OACS gateway to connect to the OIDC provider and verify access tokens.

[0036] OACS Gateway: An entity configured to handle user authentication, profile authorization, and service tickets.

[0037] OACS Gateway Key: A temporary symmetric key generated at runtime to sign service tickets.

[0038] OIDC: an abbreviation for Open ID Connection, is an identity layer used for authentication and authorization on top of the OAuth 2.0 protocol.

[0039] OIDC Client: A registered entity authorized to communicate with the provider on behalf of the end user to handle end user authentication and authorization (e.g., implemented in software).

[0040] OIDC Client ID: A unique, user-defined name used to identify an OIDC client registered with the provider.

[0041] OIDC Client Key: A private key (not the client secret) used to sign one-time authentication tokens.

[0042] OIDC Client Secret: A predefined secret used during the client authentication process.

[0043] OIDC Provider: Service provider for OpenID Connectivity 1.0 authentication.

[0044] Configuration file: A set of features defined as scopes in OAuth 2.0 with the target OACS version.

[0045] Refresh Token: A token used to authorize the acquisition of a new access token from the provider without user interaction. This allows the provider to use a short-lived access token when the original access token expires, without having to involve the end user.

[0046] RoT: an abbreviation for Root of Trust, is a cryptographic entity, such as a Trusted Platform Module (TPM) or Secure Element (SE), that can securely store keys and signature data.

[0047] Scope: A set of declarations.

[0048] Service Ticket: A data structure required for OACS gateway authorization tasks. It can be provided as a base64 encoded JWT.

[0049] User Agent: Any type of external front-end entity configured to handle end-user authentication, authorization, and ticket acquisition via communication with OACS clients.

[0050] Zone: A group of equipment related to a specific area.

[0051] resource

[0052] The following resources (listed in alphabetical order) are available and will be helpful in the descriptions below.

[0053] access.h: Used by the service to verify access permissions using predefined authorization requirements.

[0054] client.h: An abstraction layer used to handle communication with the OACS gateway service. Defines pointers to communication handler functions used by client functions to relay requests to the OACS gateway. Client functions create request objects, which are then serialized for transmission over any inter-process communication protocol using the appropriate communication handler function.

[0055] liboacs: A C library used by the OACS gateway to handle end-user authentication and configuration file authorization. It is also used by services to verify access permissions and by external services to handle communication with the OACS gateway.

[0056] OACS gateway.h: Contains functions that initiate internal OIDC client access and set the necessary parameters for access token verification. OACS gateway functions use the OAuth stream via HTTP API calls to handle user authentication and profile authorization. Additional functions exist for access token verification, service ticket generation, and service ticket verification.

[0057] permissions.h: Provides definitions for the license types and license flags used by "OACS gateway.h" and "client.h". Services will use this flag to define the authorization requirements for their APIs.

[0058] Network architecture

[0059] exist Figure 1 The diagram illustrates a network architecture 100 that readily applies the embodiments disclosed herein. A local area network (LAN) 110 includes devices such as cameras 120, a management entity 130 for management and access control systems (ACS), and a forwarding agent 140 for communication with an OIDC provider 150, end users 160, and system administrators 170. Entities within the LAN are operatively connected via connection point 180. Each device acts as its own OIDC client using the same OIDC client ID and OIDC client key. The client ID and client key must be installed on the device during setup before use; otherwise, client authentication against the OIDC provider will fail. The client key needs to be stored in a tamper-proof device to establish a root of trust. Because the device acts as a client, tokens will be transmitted less across the LAN, and there will be no central server acting as the OIDC client back-end (which could become a potential single point of failure or a bottleneck for congested device traffic). Each device should be configured to apply encryption to external communications for protection and to prevent token leakage.

[0060] configuration file

[0061] A configuration file is defined as a set of features that represent the actions a device can perform along with its authorized permissions. These features can be native features directly provided by the service, pseudo features defined by a specific use of another native feature, or composite features combining two or more features. In this case, a native feature could be playing an audio resource in a network speaker or starting video recording in a security camera. A pseudo feature could be a network speaker playing a fire alarm sound as a fire alarm function. Combinations of features should not occur. If an application needs to use two or more features, a new composite feature should be defined. This allows the service to allow access to a single feature without considering all possible combinations. Each feature will have one or more of the following permissions: "run", "conf", and "privilege". If an end user sends a request to perform a task, the request must request the "run" permission, while the "conf" permission is used to configure the task. For privileged requests such as privileged execution or elevated configuration, the "privilege" permission can be used in combination with "run" and "conf". Permissions can be represented as a list of JSON strings. Because cameras and speakers have different features, an optional "target" field exists in the configuration file to determine the target platform of the configuration file. Alternatively, depending on the target platform, the same feature can have different uses. Due to this ambiguity, a target field should be used to prevent malicious misuse, as features on a speaker could potentially lead to enhanced camera access. This field can be selected if the feature is considered platform-specific or sufficiently unique.

[0062] district

[0063] A zone is a definition of a group of devices. It uses the "aud" claim defined by OAuth 2.0 to target a specific audience. When used with cloud services, the audience can be a specific application or service. As used in this article, the audience claim refers to a zone defined by the system administrator. The "aud" option is added to the configuration when setting up devices. A system administrator can create a new zone by creating a new zone scope and then configuring a group of devices to accept that zone as the target audience. When an end user subsequently logs in to a device in a specific zone, that device inserts its zone as the scope in the authorization request. After successful authentication, a refresh token is authorized with a profile for that audience. This refresh token will only be accepted within that zone, isolating different zones from each other.

[0064] Access Control List

[0065] Access Control Lists (ACLs) can be represented by a scope of a given profile on a given device. To add a profile to a device, such a scope is created using the device's serial number and the profile scope name, binding the two together. For example, entries in these scopes could be end-user email addresses, corresponding to email claims in the default email scope. The entry value is the expiration date and time of a temporary access profile. Thus, an elevated access profile, such as "Technician," could be assigned for hours to days, and become inaccessible to the end-user upon expiration. An empty string can be used for persistent access to a profile. If a wildcard, represented by "*", is used on a profile, any user can use that profile on that device without explicit assignment. In that case, any user added to the list will be blacklisted. ACLs can also be defined for zones to assign profiles and authorized users to a group of devices, instead of configuring separate ACLs. For example, the "m_building" zone could be defined to include all devices in a building. Devices would then be configured with "m_building" as an audience during setup. The ACL would be bound to a profile that would then individually authorize users for all devices in the building, or authorize each user using wildcards.

[0066] Operator configuration file example

[0067] exist Figure 2 The diagram illustrates three examples of operator configuration files.

[0068] The first example illustrates operator profile 210 targeting a speaker, where the audio_playback feature is set to "run" and "conf" permissions. This profile can therefore be used to run and / or configure audio playback tasks. However, due to the lack of "private" permissions, the profile cannot be used to perform privileged tasks. This profile, defined on the device with serial number "02428800863e", also has an ACL. The end user with email address "john@doe.com" has been granted access using an empty string, implying persistent access, while the end user with email address "jane@doe.com" has temporary access until November 30, 2022. Therefore, this profile is explicitly assigned to that specific device. A default zone is defined and can be used by devices configured to accept "default" as their target audience.

[0069] The second example illustrates operator profile 220 with the "fire_alarm" pseudo-feature set to "run" permission for a fire alarm profile. Along with the ACL on the profile on the device with serial number "02428800863e", this ACL assigns persistent access to the "fire_alarm" profile to the end user with the email address "john@doe.com". This user can now use the "fire_alarm" profile to trigger fire alarms.

[0070] The third example illustrates an alternative approach to the second example. In this case, operator profile 230, representing the "fire_alarm" profile, is assigned to the entire "m_building" zone instead of creating an explicit ACL for each device. Along with wildcard users, any authorized user can activate a fire alarm on any device within that zone.

[0071] Scopes 240 and 250 include an "aud" declaration. These are requested along with the configuration file and access control list, thus adding the "aud" declaration to the resulting token. The OIDC client then uses the zone name from the "aud" declaration when verifying the access token. Tokens not belonging to a device zone are discarded before further processing. The "default" zone is configured by default.

[0072] OACS Architecture

[0073] exist Figure 3The example OACS architecture 300 is provided. According to OACS architecture 300, device 320 is configured to communicate with external client 310 via endpoints. OACS utilizes four different public endpoints 362, 364, 366, and 368, as provided in OACS client 360, to handle login (authorization API, requesting user authentication and authorizing access profiles), obtaining access tokens (token API, requesting refresh tokens), authorizing tickets (ticket API, requesting service tickets), and revocation of refresh tokens. These endpoints communicate with OACS gateway 340 via the D-bus using the OACS library to service requests. The OACS gateway further communicates with RoT 350 to sign client authentication tokens as previously defined. The OACS gateway further has a connection to network interface 330. RoT protects the private key used for client authentication. The OACS gateway communicates directly with the OIDC provider. The endpoints act as entry points and potentially translate or otherwise process responses from the OACS gateway. The OACS client acts as a relying party for external clients to establish communication with the OACS gateway. The OACS gateway D-bus service will only be accessible to the "OACS" group on the host operating system. Therefore, only external entry points within the system can handle user access as expected, reducing the chance of exposure to rogue services under malicious user control.

[0074] In further detail, the OACS gateway is configured to read the profile (see below) and generate a temporary symmetric key. This key is used to bind a service ticket to a specific device, restricting the use of the authorized ticket to the device that authorized it. Because the key is randomly generated on each device, a leaked key will not affect other devices. In some examples, the key is a 256-bit secret that is updated every six hours. This ensures perfect forward confidentiality. Since tickets generated before key updates are used, a more frequent update rate may increase the likelihood of race condition variations. End users will be able to use the external ticketing API to request service tickets to use device features with authorized permissions. Processes belonging to the "oacs" group will be allowed to request tickets from the OACS gateway on behalf of the end user using the user's refresh token, the requested feature, and the permissions of the requested feature. The refresh token will be used to request a new access token with the authorized access profile. Access to the profile will be verified by confirming that the end user is present in the access control list of the authorized profile on the target device. If the end user is authorized to use the requested features with the expected license, the device will issue a new service ticket signed with the OACS gateway's symmetric key along with a new refresh token rotated using the refresh token.

[0075] Service Ticket

[0076] exist Figure 4 An example of a service ticket 400 is provided. As illustrated, a service ticket consists of a header section 410, a payload section 420, and a signature section 430. The service ticket authorizes the OACS gateway to perform tasks if the end user has the correct permissions. The "id" key is a string used to identify the ticket and ensure it is used only once. The "version" key is used to assess the compatibility of the defined profile with the device services. The "feature" key is the requested feature defined in the target feature set. The "permissions" key is used to determine the authorized permissions for the requested feature. If the end user is authorized to perform a task, a new, ephemeral service ticket is generated. The ticket is bound by the serial number of the authorized device, given by the "iss," "azp," and "aud" declarations along with the expiration time. The ticket is then signed by the device, which binds the ticket and restricts its use to a single feature on a single device.

[0077] Next, we will refer to Figure 5 The flowchart discloses a method for operating an electronic access control system 920 for device 910. The electronic access control system 920 includes an OACS client 922 and an OACS gateway 924 to an OIDC provider 940. The OACS gateway 924 implements the OIDC client 926. The electronic access control system 920 may be provided in device 910. The method is performed by the OACS gateway 924. The method is advantageously provided as a computer program. Note here that end-user throughput will be represented by user agent 950, as user agent 950 is the entity with which end users directly interact.

[0078] S116: OACS gateway 924 receives a request via OACS client 922 for OACS gateway 922 to issue a service ticket to user agent 950. This request includes an instruction from user agent 950 requesting access to a service on device 910. Services are associated with licenses.

[0079] S118: OACS gateway 924 obtains the configuration file for user agent 950 and the access control list for configuration file and device 910 from OIDC provider 940 via OIDC client 926.

[0080] S120: In response to verifying that the configuration file satisfies the permission for accessing the service on device 910 by checking the configuration file and the access control list used for device 910, and by checking the configuration file itself, OACS gateway 924 generates a service ticket that verifies one-time access to the service for user agent 950. The service ticket is a token signed by OACS gateway 924.

[0081] Service tickets can be signed using a temporary symmetric key generated by the OACS gateway during operation and stored in its working memory. It can be updated periodically to achieve perfect forward secrecy (if the old key is compromised, it cannot be used to forge new service tickets). The temporary nature of the key and access restrictions solve the fundamental problem of symmetric keys, namely that sharing a symmetric key between two parties can lead to its acquisition by unauthorized third parties. However, because the key is temporary and never shared with the client (but is used by the OACS gateway for signing and verification purposes), the speed and low storage requirements of symmetric encryption can be utilized without any security implications.

[0082] S122: OACS gateway 924 provides service tickets to user agent 950 via OACS client 922.

[0083] We will continue to refer to this. Figure 5 This document discloses embodiments relating to the operation of the electronic access control system 920, providing further details.

[0084] Next, we will disclose information about logged-in users.

[0085] S102: OACS gateway 924 responds to user agent 950's request to log in to device 910 and obtains the authorization request for user agent 950 via OACS client 922.

[0086] S104: OACS gateway 924 authenticates OIDC client 926 to OIDC provider 940 by providing a signed token to OIDC provider 940 via OIDC client 926.

[0087] S106: The OACS gateway 924 obtains the device code and verification URL for device 910 via the OIDC client 926 and from the OIDC provider 940. The verification URL includes an embedded user agent code paired with the device code.

[0088] S108: OACS gateway 924 provides the authentication URL and device code to the user client via OACS client 922 for use in authenticating user agent 950.

[0089] S110: OACS gateway 924 obtains a request for a refresh token from user agent 950 via OACS client 922. The request includes a device code.

[0090] S112: The OACS gateway 924 obtains the access token and refresh token for the user agent 950 from the OIDC provider 940 via the OIDC client 926 by providing the device code to the OIDC provider 940.

[0091] S114: OACS gateway 924 provides refresh tokens to user clients via OACS client 922.

[0092] Further details regarding the processing of service tickets will be disclosed next.

[0093] In some aspects, the request used by OACS gateway 924 to issue service tickets includes a refresh token.

[0094] In some respects, the new refresh token is obtained from the OIDC provider 940 along with a profile via the OIDC client 926. The new refresh token, along with the service ticket, is provided to the user agent 950 via the OACS client 922.

[0095] In some cases, a new refresh token is obtained after the user agent 950's profile on the access control list has been verified.

[0096] Next, we will publicly disclose the process of deregistering users (thereby revoking refresh tokens).

[0097] S124: In response to the user agent 950's request to deregister from device 910, OACS gateway 924 obtains a token revocation request for user agent 950 via OACS client 922. The token revocation request includes a refresh token.

[0098] S126: OACS gateway 924 authenticates OIDC client 926 to OIDC provider 940 by providing a signed token to OIDC provider 940 via OIDC client 926.

[0099] S128: OACS gateway 924 provides refresh token and signature token to OIDC provider 940 via OIDC client 926.

[0100] S130: The OACS gateway 924 receives a response from the OIDC client 926 and the OIDC provider 940 indicating that the refresh token has been revoked.

[0101] S132: The OACS gateway 924 provides the user client via the OACS client 922 with a response that the refresh token has been revoked and the user agent 950 has been deregistered.

[0102] Next, we will disclose other aspects related to logged-in users, processing service tickets, and logging out users.

[0103] User login process

[0104] refer to Figure 6 block diagram 600 and Figure 7 The signaling diagram is shown in Figure 700. Device 610 includes an electronic access control system 620. The OACS gateway 624 implements the OIDC client 626.

[0105] S201, Login Request Profile: User Agent 650 requests the end user to log in using a specific profile from the authorized endpoint.

[0106] S202, Request for Authorization: OACS client 622 requests OACS gateway 624 to initiate end-user login by sending an authorization request to the device authorization endpoint, containing the requested configuration file, the device's corresponding configuration file ACL, the configured zone, and the zone's configuration file ACL as the scope. The client authentication token header and payload are previously constructed and defined.

[0107] S203. Signing the JWT: The OACS client 622 generates a base64 encoded representation of the header and payload, which is then signed by RoT 628.

[0108] S204, Signature: The signature is returned and the signed JWT is assembled. This token can now be used to authenticate OIDC clients to the OIDC provider 640 via network interface 630.

[0109] S205. Retrieve device_code and verification_url: If OIDC client 626 is successfully authenticated, the OIDC provider's response will include device_code and verification_url. The verification_url has an embedded user_code that pairs with the device_code connected to the same session.

[0110] S206, Forwarding device_code and verification_url: The verification_url is forwarded to user agent 650 for use in authenticating the user together with the device_code, which will be used later to obtain the issued refresh token.

[0111] S207, Login and Authorization Scope: User agent 650 is used to communicate the verification_url that can be opened in a browser to the user. This provides single sign-on for headless devices because the user remains logged in via a cookie set on the device used for authentication. The user_code and device_code are only valid for a short period of time.

[0112] S208. Retrieve New Token: After successful user authentication, User Agent 650 will use device_code to request a refresh token for the requested profile.

[0113] S209, Request Tokens: The access_token and refresh_token are requested by device 610 from OIDC provider 640 using the device_code provided by the user agent. Repeat steps S202 and S203 to generate client authentication tokens.

[0114] S210, Obtain refresh_token: Obtain access_token and refresh_token from OIDC provider 640. Verify user access permissions to the requested configuration file by checking (in OACS gateway 624) the device and zone ACLs of the configuration file. If the user has a valid entry in at least one of them, the configuration file is permitted and refresh_token is returned. Otherwise, an error message is returned.

[0115] S211, Relay refresh token: The response is relayed to user agent 650.

[0116] Ticket processing procedure

[0117] refer to Figure 8 block diagram 800 and Figure 9 Signaling diagram 900 and Figure 10 Signaling diagram 1000. Device 810 includes an electronic access control system 820. OACS gateway 824 implements OIDC client 826.

[0118] S301, Request a new service ticket: User agent 850 uses its refresh token to request a new ticket for specific features and permissions.

[0119] S302, Request a new service ticket: OACS client 822 requests OACS gateway 824 to issue a service ticket. First, it needs to obtain the configuration file and ACL.

[0120] S303. Signing the JWT: The OIDC client 826 generates a base64 encoded representation of the header and payload, which is then signed by the RoT 828.

[0121] S304, Signature: The signature is returned and the signed JWT is assembled. This token can now be used to authenticate the OIDC client 826 to the OIDC provider 840 via network interface 830.

[0122] S305, Obtaining Service Ticket and Refresh Token: If the refresh token was originally intended for the target device (authorized by the user during login), the service ticket will contain the device's profile ACL. In that case, a new access token is requested from the OIDC provider 840 and feature permissions are verified. If authorized, the new service ticket is signed using the refresh token rotation and returned along with the new refresh token. If the device is not the originally expected target device, the OACS gateway 824 will use the client credentials process to obtain the target device's profile ACL. If the user is authorized to use the authorized profile on the target device, the process continues as before, and ticket authorization is performed. If the user is not explicitly blacklisted on the device, the district profile ACL is checked as a fallback. If successful, a new service ticket is generated and issued.

[0123] S306, Forwarding Service Tickets and Refresh Tokens: Tickets and refresh tokens are forwarded to user agent 850. If the authorized profile ACL does not belong to the target device, a Client Credential Grant is used to request the ACL for the authorized profile on behalf of user agent 850. Client Credential Grants are only authorized to access device ACLs. Authorized profiles require user authentication because they are enforced to use the user identity in the ACL.

[0124] User cancellation process

[0125] refer to Figure 11 Block diagram 1100 and Figure 12 Signaling diagram 1200. Device 1110 includes an electronic access control system 1120. OACS gateway 1124 implements OIDC client 1126.

[0126] S401, Cancellation: The end user is cancelled via user agent 1150.

[0127] S402, Revoke refresh_token: OACS client 1122 requests OACS gateway 1124 to initiate token revocation using the refresh token provided by user agent 1150.

[0128] S403. Signing the JWT: The OIDC client 1126 generates a base64 encoded representation of the header and payload, which is then signed by RoT 1128.

[0129] S404, Signature: The signature is returned and the signed JWT is assembled. This token can now be used to authenticate the OIDC client 1126 to the OIDC provider 1140 via network interface 1130.

[0130] S405, HTTP Response Code: OIDC provider 1140 responds with HTTP response code 200 to indicate success, and any other response is considered a failure and the token is not revoked.

[0131] S406, Response: Return a response message to notify of the result. The revoked token can no longer be used to obtain a new access_token, and therefore the user is considered to have been logged out.

[0132] Ticket usage process

[0133] When an external service API is invoked, the process of using a service ticket begins. The service ticket is passed along with the request. The service ticket is forwarded as a string to the next service. Each service performs a permission check at the start of the service API call, expecting one of a set of approved features and licenses required to use the API. The version of each OACS feature set is checked.

[0134] The integrity of the service ticket is verified by confirming the token's signature and expiration time. The service can verify the service ticket's signature by sending it to the OACS gateway on the D-bus. In this case, if the service ticket is valid, the OACS gateway will return an acknowledgment of its validity. If the service ticket has the correct permissions, the API call will be resumed, and the service ticket will be passed to the next service. Otherwise, an issuance error will occur.

[0135] Task authorization (legacy) process

[0136] Task authorization can be used to provide backward compatibility with existing access systems. The OACS gateway is then provided with static legacy profiles. These files can be JSON files representing traditional user roles via OACS access profiles. In this case, the user logs in as usual. The user is authenticated using a local user database. Once the user is authenticated and the user roles are determined, the OACS gateway can be used to authorize task objects. The request must be evaluated on a Common Gateway Interface (CGI) or Application Programming Interface (API) endpoint to determine the required characteristics and permissions. The task object can then be authorized by requesting authorization for the characteristics and their permissions using established roles. If a legacy profile for a role exists and the task is authorized by it, the task object is generated and returned. If none of the roles assigned to the user permits the requested task, authorization fails.

[0137] Figure 13 The components of an electronic access control system 1300 according to an embodiment are schematically illustrated in the form of a number of functional units. Processing circuitry 1310 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., to execute (e.g., in the form of storage medium 1330) a computer program product 1410 (such as in...). Figure 14 The software instructions in the (in Chinese). The processing circuit 1310 may further be provided as at least one application-specific integrated circuit (ASIC) or field-programmable gate array (FPGA).

[0138] Specifically, the processing circuit 1310 is configured to cause the electronic access control system 1300 to perform the set of operations or steps disclosed above. For example, the storage medium 1330 may store the set of operations, and the processing circuit 1310 may be configured to retrieve the set of operations from the storage medium 1330 to cause the electronic access control system 1300 to perform the set of operations. The set of operations may be provided as a set of executable instructions.

[0139] Therefore, the processing circuitry 1310 is thus arranged to perform the methods disclosed herein. The storage medium 1330 may also include persistent memory, such as any single or combination of magnetic storage, optical storage, solid-state storage, or even remotely mounted memory. The electronic access control system 1300 may further include a communication interface 1320 configured at least for communicating with other entities, functions, nodes, and devices. Thus, the communication interface 1320 may include one or more transmitters and receivers comprising analog and digital components. The processing circuitry 1310 controls the routine operation of the electronic access control system 1300, for example, by sending data and control signals to the communication interface 1320 and the storage medium 1330, by receiving data and reports from the communication interface 1320, and by acquiring data and instructions from the storage medium 1330. Other components and related functions of the electronic access control system 1300 are omitted to avoid obscuring the concepts presented herein.

[0140] The electronic access control system 1300 can be provided as a standalone device or as part of at least one further device. Therefore, a first portion of the instructions executed by the electronic access control system 1300 can be executed in a first device, and a second portion of the instructions executed by the electronic access control system 1300 can be executed in a second device; the embodiments disclosed herein are not limited to any specific number of devices on which the instructions executed by the electronic access control system 1300 can be executed. Therefore, the methods according to the embodiments disclosed herein are suitable for execution by the electronic access control system 1300 residing in a cloud computing environment. Thus, although... Figure 13 The diagram illustrates a single processing circuit 1310, but processing circuits 1310 can be distributed across multiple devices or nodes. This also applies to... Figure 14 Computer program 1420.

[0141] Figure 14 An example of a computer program product 1410 including a computer-readable storage medium 1430 is shown. On this computer-readable storage medium 1430, a computer program 1420 may be stored, which can cause processing circuitry 1310 and entities and devices operatively coupled thereto (such as communication interface 1320 and storage medium 1330) to perform the methods according to the embodiments described herein. Therefore, computer program 1420 and / or computer program product 1410 can provide means for performing any of the steps disclosed herein.

[0142] exist Figure 14In the example, computer program product 1410 is illustrated as an optical disc such as a CD (optical disc), DVD (digital versatile optical disc), or Blu-ray disc. Computer program product 1410 may also be embodied as a memory such as random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or electrically erasable programmable read-only memory (EEPROM), and more specifically as a non-volatile storage medium of a device in external memory such as USB (Universal Serial Bus) memory or flash memory such as compact flash memory. Therefore, although computer program 1420 is schematically shown herein as a track on the depicted optical disc, computer program 1420 may be stored in any manner suitable for computer program product 1410.

[0143] The concept of the present invention has been described above primarily with reference to several embodiments. However, as will be readily understood by those skilled in the art, other embodiments besides those disclosed above are equally possible within the scope of the present invention as defined by the appended claims.

Claims

1. An electronic access control system for a device, wherein the electronic access control system includes an OIDC Electronic Access Control System (OACS) client and an OACS gateway to an OIDC provider, wherein the OACS gateway implements the OIDC client, and wherein the OACS gateway is configured to: The OACS client receives a request for the OACS gateway to issue a service ticket to the user agent, the request including an indication that the user agent requests access to a service on the device, wherein the service is associated with a license; The OIDC client obtains a configuration file for the user agent and an access control list for the configuration file and the device from the OIDC provider. In response to the confirmation by checking the access control list for the configuration file and the device, and by checking the configuration file itself, that the configuration file satisfies the permission to access the services on the device: Generate a service ticket to verify the user agent's one-time access to the service, wherein the service ticket is a token signed by the OACS gateway; and The service ticket is provided to the user agent via the OACS client.

2. The electronic access control system according to claim 1, wherein the OACS gateway is configured as follows: In response to the user agent's request to log in to the device, an authorization request for the user agent is obtained via the OACS client; and The OIDC client authenticates itself to the OIDC provider by providing a signed token to the OIDC provider via the OIDC client.

3. The electronic access control system according to claim 2, wherein the OACS gateway is configured as follows: The device code and verification URL for the device are obtained via the OIDC client and from the OIDC provider, wherein the verification URL includes an embedded user agent code paired with the device code; and The verification URL and the device code are provided to the user client via the OACS client for authenticating the user agent.

4. The electronic access control system according to claim 3, wherein the OACS gateway is configured as follows: The OACS client obtains a request for a refresh token from the user agent, wherein the request includes the device code; By providing the device code to the OIDC provider, the user agent obtains an access token and a refresh token from the OIDC provider via the OIDC client; and The refresh token is provided to the user client via the OACS client.

5. The electronic access control system of claim 4, wherein the request for the OACS gateway to issue the service ticket includes the refresh token.

6. The electronic access control system of claim 5, wherein a new refresh token is obtained from the OIDC provider via the OIDC client, together with the configuration file, and wherein the new refresh token is provided to the user agent via the OACS client, together with the service ticket.

7. The electronic access control system according to claim 6, wherein, After verifying the user agent's profile on the access control list, the new refresh token is obtained.

8. The electronic access control system according to claim 4, wherein the OACS gateway is configured as follows: In response to the user agent's request to deregister from the device, a token revocation request for the user agent is obtained via the OACS client, wherein the token revocation request includes the refresh token.

9. The electronic access control system according to claim 8, wherein the OACS gateway is configured as follows: The OIDC client authenticates itself to the OIDC provider by providing a signed token to the OIDC provider via the OIDC client; and The refresh token and the signed token are provided to the OIDC provider via the OIDC client.

10. The electronic access control system according to claim 9, wherein the OACS gateway is configured to: A response indicating that the refresh token has been revoked is obtained via the OIDC client and from the OIDC provider.

11. The electronic access control system of claim 10, wherein the OACS gateway is configured to: The OACS client provides the user client with a response that the refresh token has been revoked and the user agent has been deregistered.

12. An apparatus comprising the electronic access control system according to claim 1.

13. A method for operating an electronic access control system for a device, wherein the electronic access control system includes an OIDC Electronic Access Control System (OACS) client and an OACS gateway to an OIDC provider, wherein the OACS gateway implements the OIDC client, wherein the method is performed by the OACS gateway, and wherein the method includes: The OACS client receives a request for the OACS gateway to issue a service ticket to the user agent, the request including an indication that the user agent requests access to a service on the device, wherein the service is associated with a license; The OIDC client obtains a configuration file for the user agent and an access control list for the configuration file and the device from the OIDC provider. In response to the confirmation by checking the access control list for the configuration file and the device, and by checking the configuration file itself, that the configuration file satisfies the permission to access the services on the device: Generate a service ticket to verify the user agent's one-time access to the service, wherein the service ticket is a token signed by the OACS gateway; and The service ticket is provided to the user agent via the OACS client.

14. A computer program product for an electronic access control system for operating equipment, wherein the electronic access control system includes an OIDC electronic access control system OACS client and an OACS gateway to an OIDC provider, wherein the OACS gateway implements the OIDC client, and the computer program product includes computer code that, when run on the processing circuitry of the electronic access control system, causes the OACS gateway to: The OACS client receives a request for the OACS gateway to issue a service ticket to the user agent, the request including an indication that the user agent requests access to a service on the device, wherein the service is associated with a license; The OIDC client obtains a configuration file for the user agent and an access control list for the configuration file and the device from the OIDC provider. In response to the confirmation by checking the access control list for the configuration file and the device, and by checking the configuration file itself, that the configuration file satisfies the permission to access the services on the device: Generate a service ticket to verify the user agent's one-time access to the service, wherein the service ticket is a token signed by the OACS gateway; and The service ticket is provided to the user agent via the OACS client.

15. A computer-readable storage medium for storing a computer program that, when run on processing circuitry, causes the processing circuitry to perform the method according to claim 13.

Images