Patent Description:
In general terms, the term access control (AC) refers to the selective restriction of end-user access to a place or other resource, such as service or a device. Here, the actual act of accessing a place or other resource may mean entering a premises, consume, or retrieve, some data, or using, or configuring, some device, etc. Permission to access a resource is referred to as authorization. Locks and login credentials are two analogous mechanisms of access control.

Techniques for electronic access control (EAC) use computers to solve the limitations of mechanical locks and keys. A wide range of credentials can be used to replace mechanical keys. The electronic access control system grants access to an end-user based on the credential presented. When access is granted, a door can be unlocked for a predetermined time, or the end-user might access some requested data or a service. When access is refused, the door remains locked, or the end-user is prevented from accessing the requested data or service.

A credential is a physical/tangible object, a piece of knowledge, or a facet of a person's physical being that enables an individual access to a given physical facility or computer-based information system.

For local role-based electronic access control systems, a representation of the credentials is required to be directly installed on each individual device for which access is controlled. This is needed in order to make it possible to check the credentials presented by the end-user when access control is performed. For example, a value derived from the credentials using a one-way transformation function, such as a cryptographic hash function, is stored. Further, the limited number of different selectable roles does not allow for the access rights to be finetuned. Still further, the roles are not only limited in number, but they are fixed and unchangeable.

<CIT> discloses an OpenID Connect based authentication/ authorization system that involves an OpenID Connect proxy.

An object of embodiments herein is to address the above-noted shortcomings of role-based electronic access control systems.

According to a first aspect there is presented an electronic access control system for a device. The electronic access control system comprises an OACS client and an OACS gateway to an OIDC provider. The OACS gateway implements an OIDC client. The OACS gateway is configured to obtain, via the OACS client, a request for the OACS gateway to issue a service ticket for a user agent. The request comprises an indication that the user agent requests to access a service on the device. The service is associated with a permission. The OACS gateway is configured to retrieve, 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, responsive to having confirmed, by checking the access control list for the profile and the device, and by checking the profile itself, that the profile fulfils the permission to access the service on the device, generate a service ticket that validates the user agent for a one-time access to the service. The service ticket is a token that is signed by the OACS gateway. The OACS gateway is configured to provide, via the OACS client, the service ticket towards the user agent.

According to a second aspect there is presented a method for operating an electronic access control system for a device. The electronic access control system comprises an OACS client and an OACS gateway to an OIDC provider. The OACS gateway implements an OIDC client. The method is performed by the OACS gateway. The method comprises obtaining, via the OACS client, a request for the OACS gateway to issue a service ticket for a user agent. The request comprises an indication that the user agent requests to access a service on the device. The service is associated with a permission. The method comprises retrieving, 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 method comprises, responsive to having confirmed, by checking the access control list for the profile and the device, and by checking the profile itself, that the profile fulfils the permission to access the service on the device, generating a service ticket that validates the user agent for a one-time access to the service. The service ticket is a token that is signed by the OACS gateway. The method comprises providing, via the OACS client, the service ticket towards the user agent.

According to a third aspect there is presented a computer program for operating an electronic access control system for a device. The electronic access control system comprises an OACS client and an OACS gateway to an OIDC provider. The OACS gateway implements an OIDC client. The computer program comprises computer code which, when run on processing circuitry of the OACS gateway, causes the OACS gateway to perform actions. One action comprises the OACS gateway to obtain, via the OACS client, a request for the OACS gateway to issue a service ticket for a user agent. The request comprises an indication that the user agent requests to access a service on the device. The service is associated with a permission. One action comprises the OACS gateway to retrieve, 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. One action comprises the OACS gateway to, responsive to having confirmed, by checking the access control list for the profile and the device, and by checking the profile itself, that the profile fulfils the permission to access the service on the device, generate a service ticket that validates the user agent for a one-time access to the service. One action comprises the OACS gateway to provide, via the OACS client, the service ticket towards the user agent.

According to a fourth aspect there is presented a computer program product comprising a computer program according to the third aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium.

Advantageously, these aspects overcome the above-noted shortcomings of role-based electronic access control systems.

Advantageously, these aspects enable new roles to be created.

The following definitions (as alphabetically listed) will be useful in the following description.

Access Token: a token for authorization to a specific resource.

Claim: a statement about a scope. It can be dynamically asigned from an external source or be statically mapped.

Client Key: a persistent private key used to sign tokens for client authentication. The public part of the client key is registered for the client by the OIDC provider. D-Bus: an inter-process communication protocol.

External Service: any service that can be accessed from outside the device.

JWT: a JSON (JavaScript Object Notation) Web Token.

OACS: short for OIDC Electronic access control system, implementing a profile-based access control solution using JWTs.

OACS Conf: a configuration file used by the OACS gateway to connect to the OIDC Provider and verify the access token.

OACS gateway: an entity configured to handle user authentication, profile authorization and service tickets.

OACS gateway key: A temporary symmetric key generated on runtime to sign service tickets.

OIDC: short for Open ID Connect, an identity layer on top of the OAuth <NUM> protocol for authentication and authorization.

OIDC Client: a registered entity (e.g., implemented in software) that is authorized to communicate with the provider on behalf of the end-user to handle end-user authentication and authorization.

OIDC Client ID: A unique user-defined name to identify the OIDC client registered on the provider.

OIDC Client key: A private key used (instead of a client secret) to sign single-use authentication tokens.

OIDC Client secret: A predefined secret used during client authentication.

OIDC Provider: an OpenID Connect <NUM> certified service provider.

Profile: a set of features defined as a scope in OAuth <NUM> with the targeted OACS version.

Refresh Token: a token for authorization to retrieve a new access token from the provider without user interaction. This allows providers to use short-lived access tokens without having to involve the end-user when the access tokens expire.

RoT: short for Root of Trust, a cryptographic entity, such as a Trusted Platform Module (TPM) or a Secure Element (SE), that can securely store keys and sign data.

Service Ticket: a data structures required by the OACS gateway to authorize a task. Could be provided as a base64 encoded JWT.

User Agent: any type of external front-end entity configured to handle end-user authentication, authorization and ticket retrieval by communicating through the OACS Client.

Zone: A group of regionally related devices.

The following resources (as alphabetically listed) as accessible to the following will be useful in the following description.

h: used by services to verify access rights using predefined authorization requirements.

h: an abstraction layer to handle communication with the OACS gateway service. Defines a communication handler function pointer, that is used by client functions to relay requests to the OACS gateway. The client functions crafts request objects that are than serialized for transfer over any inter process communication protocol using a corresponding communication handler function.

liboacs: a C library used by the OACS gateway to handle authentication of end-users and authorization of profiles. Also used by services to verify access rights and by external services to handle communication with the OACS gateway.

OACS gateway. h: comprises functions to initiate the internal OIDC Client and set parameters necessary for verification of access tokens. The OACS gateway functions use OAuth flows through HTTP API calls to handle user authentication and profile authorization. Additional functions exist for verification of access tokens, generation of service ticket and verification of service tickets.

permissions. h: provides a definition of the permission type and permission flags used by "OACS gateway. h" and "client. Services will use this flag to define authorization requirements for their APIs.

In <FIG> is illustrated a network architecture <NUM> where the herein disclosed embodiments readily apply. A local area network (LAN) <NUM> comprises devices <NUM>, such as cameras, a management entity <NUM> for an administration (adm) and access control system (ACS), and a forward proxy <NUM> to communicate with an OIDC provider <NUM>, end-users <NUM> and system administrators <NUM>. The entities in the LAN are operatively connected through a connection point <NUM>. Each device acts as its own OIDC client using the same OIDC client ID and OIDC client key. The client ID and client key need to be installed on the devices during setup before use, or else the 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. With devices as clients, the tokens will travel less over the LAN and also, there will not be a central server acting as a OIDC client back-end, that can become a potential single point of failure or a bottleneck that congests the traffic to the devices. Each device should be configured to apply encryption to external communication for protection and to prevent tokens from getting leaked.

A profile is defined as a set of features representing operations that the device can perform together with its authorized permissions. These features can be native features provided directly by a service, pseudo features defined by a specific use of another native feature, or composite features that are a combination of two or more features. A native feature in this case could be to play an audio resource in a network speaker or start recording video in a security camera. A pseudo feature can be for that network speaker to play the sound of a fire siren as a fire alarm feature. No combination of features should occur. If a procedure would require the use of two or more features, then a new composite feature should be defined. In this way, the service can allow access to single features without the concern of all the possible combinations. Each feature will have one or more of the following permissions, "run", "conf", "priv". If the end-user sends a request to perform a task, then the request must require the "run" permission, whilst the "conf" permission is used to configure the task. The "priv" permission can be used in combination with "run" and "conf" for elevated privilege requirements, such as privileged executions or configurations. The permissions can be represented as a JSON list of strings. An optional "target" field exists in the profile to determine the target platform of the profile, as different features exist for cameras and speakers. Alternatively, the same feature could have different uses depending on the target platform. Because of this ambiguity, the target field should be used in order to prevent malicious misuse, as a feature on a speaker could potentially result in elevated access on a camera. If features are deemed platform specific or unique enough, then this field can be opted out.

Zones are definitions regarding a group of devices. It utilizes the "aud" claim defined by OAuth <NUM> to target a specific audience. The audience can be a specific application or service when used with cloud services. As used herein, the audience claim refers to a zone defined by the system admin. The "aud" option is added to the configuration when setting up the device. The system administrator can create a new zone by creating a new zone scope and then configuring a set of devices to accept that zone as the intended audience. When an end-user then logs in on a device in a particular zone, the device will insert its zone into the authorization request as a scope. After a successful authentication, a refresh token will be authorized with a profile intended for that audience. This refresh token will only be accepted in that zone, isolating different zones from each other.

An access control list (ACL) can be represented by a scope for a given profile on a given device. To add a profile to a device, such a scope can be created using the device's serial number and the profile scopes name, in order to bind the two of them together. The entries in these scopes can, for example, be the email address of the end-users, which correspond to the email claim in the default email scope. The entry values are expiration date-times for temporary access to a profile. In this way, an elevated access profile, such as "technician" can be assigned for a few hours to days and be inaccessible for the end-user when expired. An empty string can be used for persistent access to the profile. If a wildcard, represented by "*" is used on a profile, any user can use that profile on that device without being explicitly assigned. In that case, any user added to the list will instead get black-listed. An ACL can also be defined for a zone, in order to assign a profile and authorize users for a group of devices, instead of configuring individual ACLs. For instance, an "m_building" zone can be defined to include all the devices in that building. The devices would then be configured with "m_building" as audience during setup. The ACL would be bound to a profile that would then either individually authorize users for all the devices on that building or everyone using the wildcard user.

In <FIG> is illustrated three examples of operator profiles.

The first example illustrates an operator profile <NUM> targeting speakers, with an audio_playback feature set to "run" and "conf" permissions. This profile can thus be used to run and/or configure an audio playback task. The profile, however, cannot be employed to perform privileged task, as the "priv" permission is missing'. An ACL is also present for this profile defined on a device with "02428800863e" as serial number. An end-user with email address "john@doe. com" has been given access using an empty string, which implies persistent access, whilst an end-user with email address "jane@doe. com" has a temporary access until 30th of November <NUM>. This profile is thus explicitly assigned on that particular device. A default zone is defined and can be used by devices that are configured to accept "default" as the intended audience.

The second example illustrates an operator profile <NUM> in terms of a fire alarm profile with the "fire_alarm" pseudo feature set to "run" permission. Together with an ACL for the profile on a device with "02428800863e" as serial number, this ACL assigns an end-user with email address "john@doe. com" persistent access to the "fire_alarm" profile. This user can now use the "fire_alarm" profile to trigger the fire alarm.

The third example illustrates an alternative approach to the second example. In this case, an operator profile <NUM> representing the "fire_alarm" profile is assigned to the entire "m_building" zone without creating explicit ACL for each device. Together with the wildcard user, any authorized user can start the fire alarm on any device in that zone.

Scopes <NUM>, <NUM> comprise the "aud" claim. They are requested together with the profiles and access control lists, thus adding the "aud" claim into the resulting token. The zone name in an "aud" claim is then used by the OIDC client when the access token is verified. Tokens that do not belong to the devices zone are discarded before anything else is done. The "default" zone is configured by default.

In <FIG> is provided an example OACS architecture <NUM> according to which a device <NUM> is configured to communicate with an external client <NUM> over end-points. The OACS utilizes four different public end-points <NUM>, <NUM>, <NUM>, <NUM>, as provided in an OACS client <NUM>, to handle login (Authorization API, with request user authentication and authorize access profile), get access token (Token API, with request refresh token), authorize ticket (Ticket API, with request service ticket), and revocation of the refresh token (Revocation, with revoke refresh token). These end-points make use of the OACS library to communicate with the OACS gateway <NUM> over a D-Bus to serve requests. The OACS gateway further communicates with the RoT <NUM> to sign client authentication tokens as previously defined. The OACS gateway further has a connection to a network interface <NUM>. The RoT protects the private key used for client authentication. The OACS gateway communicates directly with the OIDC Provider. The end-points act as entry points and potentially translate, or in other way handle, responses from the OACS gateway. The OACS Client acts as a relying party for the external client to establish communication with the OACS gateway. The OACS gateway D-Bus service will only be allowed to be used by the "oacs" group on the host operating system. Thus, only external entry points in the system can process user access as intended, reducing the chances of exposure to a rogue service under the control of a malicious user.

In further detail, the OACS gateway is configured to read a configuration file (see below) and generate a temporary symmetric key. This key is used to bind a service ticket to a specific device, limiting the use of an authorized ticket to the device that authorized it. As the keys are randomly generated on each device, a compromised key will not affect other devices. In some examples, the key is a <NUM>-bit secret that is updated once every six hours. This can ensure perfect forward secrecy. A more frequent update rate could increase the changes of a race condition due to use of tickets generated before key update. The end-user will be able to use the external Ticket API to request a service ticket to use a device feature with authorized permissions. A process belonging to the "oacs" group will be allowed to request the ticket from the OACS gateway, on behalf of the end-user, with the user's refresh token, the requested feature, and permissions for that requested feature. The refresh token will be used to request a new access token with the authorized access profile. The access rights to a profile will be verified by confirming that the end-user exists in the access control list for the authorized profile, on the target device. If the end-user is authorized to use the requested feature with the expected permissions, a new service ticket will be issued by the device signed using the symmetric key of the OACS gateway together with a new refresh token using refresh token rotation.

In <FIG> is provided an example of a service ticket <NUM>. As illustrated, the service ticket is composed of a header part <NUM>, a payload part <NUM>, and a signature part <NUM>. A service ticket is an authorization by the OACS gateway to perform a task given that the end-user has the right permissions. The "id" key is a string used to identify the ticket and ensure that the ticket is used only once. The "version" key is used to assess the compatibility of the defined profile with device services. The "feature" key is the request feature defined in the target feature set. The "permissions" key is used to determine the authorized permission for the requested feature. If the end-user is authorized to perform the task, a new short-lived service ticket is generated. The ticket will be bound by the serial number of the device that authorized the use, given by the "iss", "azp" and "aud" claims together with an expiration time. The ticket is then signed by the device, binding it and limiting its use to a single feature on a single device.

A method for operating an electronic access control system <NUM> for a device <NUM> will be disclosed next with reference to the flowchart of <FIG>. The electronic access control system <NUM> comprises an OACS client <NUM> and an OACS gateway <NUM> to an OIDC provider <NUM>. The OACS gateway <NUM> implements an OIDC client <NUM>. The electronic access control system <NUM> might be provided in the device <NUM>. The methods are performed by the OACS gateway <NUM>. The methods are advantageously provided as computer programs. It is here noted that the end-user throughput will be represented by the user agent <NUM> since the user agent <NUM> is the entity with which the end-user directly interacts with.

S116: The OACS gateway <NUM> obtains, via the OACS client <NUM>, a request for the OACS gateway <NUM> to issue a service ticket for a user agent <NUM>. The request comprises an indication that the user agent <NUM> requests to access a service on the device <NUM>. The service is associated with a permission.

S118: The OACS gateway <NUM> retrieves, via the OIDC client <NUM>, a profile for the user agent <NUM> and an access control list for the profile and the device <NUM> from the OIDC provider <NUM>.

S120: The OACS gateway <NUM>, responsive to having confirmed, by checking the access control list for the profile and the device <NUM>, and by checking the profile itself, that the profile fulfils the permission to access the service on the device <NUM>, generates a service ticket that validates the user agent <NUM> for a one-time access to the service. The service ticket is a token that is signed by the OACS gateway <NUM>.

The service tickets might be signed by a temporary symmetric key generated by the OACS Gateway during runtime and kept in work memory. It can be regularly updated for perfect forward secrecy (if an old key is leaked, it cannot be used to forge new service tickets). The temporary nature and access limitations to the key solves a fundamental issue with symmetric keys, where sharing the symmetric key between two parties might cause the key to be obtained by an unauthorized third party. However, as the key is temporary and never shared with the client (but instead used by the OACS gateway for signing and validation purposes), the speed and low storage requirements of symmetric encryption can be utilized without any security implications.

S122: The OACS gateway <NUM> provides, via the OACS client <NUM>, the service ticket towards the user agent <NUM>.

Embodiments relating to further details of operating the electronic access control system <NUM> will now be disclosed with continued reference to <FIG>.

Aspects of logging in the user will be disclosed next.

S102: The OACS gateway <NUM> obtains, via the OACS client <NUM>, an authorization request for the user agent <NUM> responsive to the user agent <NUM> requesting to log in to the device <NUM>.

S104: The OACS gateway <NUM> authenticates the OICD client <NUM> towards the OIDC provider <NUM> by providing, via the OIDC client <NUM>, a signed token to the OIDC provider <NUM>.

S106: The OACS gateway <NUM> obtains, via the OIDC client <NUM> and from the OIDC provider <NUM>, a device code and a verification URL for the device <NUM>. The verification URL comprises an embedded user agent code that is paired with the device code.

S108: The OACS gateway <NUM> provides, via the OACS client <NUM>, the verification URL and the device code towards the user client for authenticating the user agent <NUM>.

S110: The OACS gateway <NUM> obtains, via the OACS client <NUM>, a request for a refresh token from the user agent <NUM>. The request comprises the device code.

S112: The OACS gateway <NUM> retrieves, via the OIDC client <NUM>, an access token and the refresh token for the user agent <NUM> from the OIDC provider <NUM> by providing the device code to the OIDC provider <NUM>.

S114: The OACS gateway <NUM> provides, via the OACS client <NUM>, the refresh token towards the user client.

Further aspects of handling service tickets will be disclosed next.

In some aspects, the request for the OACS gateway <NUM> to issue the service ticket comprises the refresh token.

In some aspects, a new refresh token is retrieved, via the OIDC client <NUM>, from the OIDC provider <NUM> together with the profile. The new refresh token is provided, via the OACS client <NUM>, together with the service ticket towards the user agent <NUM>.

In some aspects, the new refresh token is retrieved upon having verified the profile of the user agent <NUM> on the access control list.

Aspects of logging out the user (whereby the refresh token is revoked) will be disclosed next.

S124: The OACS gateway <NUM> obtains, via the OACS client <NUM>, a token revocation request for the user agent <NUM> responsive to the user agent <NUM> requesting to log out from the device <NUM>. The token revocation request comprises the refresh token.

S126: The OACS gateway <NUM> authenticates the OIDC client <NUM> towards the OIDC provider <NUM> by providing, via the OIDC client <NUM>, a signed token to the OIDC provider <NUM>.

S128: The OACS gateway <NUM> provides, via the OIDC client <NUM>, the refresh token and the signed token to the OIDC provider <NUM>.

S130: The OACS gateway <NUM> obtains, via the OIDC client <NUM> and from the OIDC provider <NUM>, a response indicating that the refresh token has been revoked.

S132: The OACS gateway <NUM> provides, via the OACS client <NUM>, a response towards the user client that the refresh token has been revoked and that the user agent <NUM> is logged out.

Further aspects relating to logging in the user, handling service tickets, and logging out the user will be disclosed next.

Reference is made to the block diagram <NUM> of <FIG> and the signaling diagram <NUM> of <FIG>. The device <NUM> comprises an electronic access control system <NUM>. The OACS gateway <NUM> implements an OIDC client <NUM>.

Login requesting a profile: The user agent <NUM> requests the end-user to be logged in with a specific profile from the authorization endpoint.

Request Authorization: The OACS Client <NUM> requests the OACS gateway <NUM> to initiate the login of the end-user by sending an authorization request to the device authorization endpoint with the requested profile, the devices corresponding profile ACL, the configured zone and the profile ACL of that zone, as scopes. The client authentication tokens header and payload are constructed and defined previously.

Sign JWT: The OACS Client <NUM> generates a base64 encoded representation of the header and payload which is then signed by the RoT <NUM>.

Signature: The signature is returned and the signed JWT is assembled. This token can now be used to authenticate the OIDC client towards the OIDC provider <NUM> via network interface <NUM>.

Retrieve device_code and verification_url: If the OIDC client <NUM> is successfully authenticated, the OIDC provider's response will contain a device_code and verification_url. The verification_url has an embedded user_code which is paired with the device_code connects to the same session.

Forward device_code and verification_url: The verification_url is forwarded to the user agent <NUM> for authentication of the user together with the device_code which will later be used to retrieve the issued refresh token.

Login and authorize scopes: The user agent <NUM> is used to convey the verification_url to the user, which can be opened in a browser. This provides single-sign-on capabilities for headless devices, as the user is kept logged in via cookies set on the device used for authentication. The user_code and device_code are only valid for a short time period.

Fetch fresh token: After successful user authentication the user agent <NUM> will request a refresh token authorizing the requested profile, using the device_code.

Request token: The access_token and refresh_token are requested from the OIDC provider <NUM>, by the device <NUM>, using the device_code provided by the user agent. Steps S202 and S203 are repeated to generate the client authentication token.

Retrieve the refresh_token: An access_token and refresh_token are retrieved from the OIDC provider <NUM>. The user access right to the requested profile is confirmed by checking (in the OACS gateway <NUM>) the device and zone ACLs of the profile. If the user has a valid entry in at least one of them, then the profile is permitted and the refresh_token is returned. Otherwise, an error message is returned.

Relay the refresh token: The response is relayed to the user agent <NUM>.

Reference is made to the block diagram <NUM> of <FIG> and the signaling diagrams <NUM>, <NUM> of <FIG> and <FIG>. The device <NUM> comprises an electronic access control system <NUM>. The OACS gateway <NUM> implements an OIDC client <NUM>.

Request new service ticket: The user-agent <NUM> requests a new ticket for a specific feature and permission, using its refresh token.

Request new service ticket: The OACS client <NUM> requests the OACS gateway <NUM> to issue the service ticket. First, the profile and ACLs need to be retrieved.

Sign JWT: The OIDC client <NUM> generates a base64 encoded representation of the header and payload which is then signed by the RoT <NUM>.

Signature: The signature is returned and the signed JWT is assembled. This token can now be used to authenticate the OIDC client <NUM> towards the OIDC provider <NUM> via network interface <NUM>.

Retrieve service ticket and refresh_token: If the refresh token was originally intended for the target device (authorized by user during login), then the service ticket will contain the profile ACL of the device. In that case, a new access token is requested from the OIDC provider <NUM> and the feature permissions are verified. If authorized, the new service ticket is signed and returned together with a new refresh token using refresh token rotation. If the device is not the originally intended target, device, the OACS gateway <NUM> will use the client credential procedure to fetch the profile ACL of the target device. If the user has right to use the authorized profile on the target device, the process precedes as in the previous case and the ticket authorization is performed. If the user is not explicitly blacklisted on the device, the zones profile ACL is checked as a fallback. If successful, a new service ticket is generated and issued.

Forward service ticket and refresh_token: The ticket and refresh token are forwarded to the user-agent <NUM>. 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 the behalf of the user agent <NUM>. The Client Credential Grant is only authorized to access device ACLs. User authentication is needed to authorize profiles, as they are enforced using the user identity in ACLs.

Logout: The end-user, via the user agent <NUM> requests to be logged out.

Revoke refresh_token: The OACS client <NUM> requests the OACS gateway <NUM> to initiate the token revocation, using the refresh token provided by the user agent <NUM>.

Sign JWT: The OIDC client <NUM> generates a base64 encoded representation of the header and payload which is then signed by the RoT <NUM>.

Signature: The signature is returned and the signed JWT is assembled. This token can now be used to authenticate the OIDC client <NUM> towards the OIDC provider <NUM> via network interface <NUM>.

HTTP response code: The OIDC provider <NUM> responds with a HTTP response code <NUM> for success and any other response is considered a failure and the token is not revoked.

Response: A response message is returned to inform about the result. The now revoked token cannot be used to get a new access_token and thus the user is considered to be logged out.

The process of using a service ticket starts when an external service API is called. The service ticket is passed with the request. The service ticket is forwarded to the next service as a string. Each service does a permission check at the beginning of a serving API call, expecting one of a set of approved features and permissions required to use that API. Every OACS feature set version is checked.

The integrity of the service ticket is confirmed by verifying the signature of the token and the expiration time. The service can verify the signature of the service ticket by sending it to OACS gateway over the D-Bus. In this case, if the service ticket is valid, the OACS gateway will return a confirmation that the service ticket is valid. If the service ticket has the right permissions, then the API call will resume, and the service ticket will be passed to the next service. Otherwise, it will result in an error being issued.

Task authorization can be used to provide backwards compatibility with existing access systems. The OACS gateway is then provided with static legacy profiles. These could be JSON files that represent the traditional user roles through OACS access profiles. In this case, a user logs in as usual. The user is authenticated using a local user database. Once the user is authenticated and user roles have been determined, the OACS gateway can be used to authorize a task object. The request will have to be evaluated on a Common Gateway Interface (CGI) or application programming interface (API) end-point in order to determine the required feature and permission. A task object can then be authorized by requesting authorization for the feature and its permission using the established roles. If a legacy profile exists for the role and the task is authorized by it, a task object is generated and returned. It none of the roles assigned to the user permits the requested task, authorization fails.

<FIG> schematically illustrates, in terms of a number of functional units, the components of an electronic access control system <NUM> according to an embodiment. Processing circuitry <NUM> is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product <NUM> (as in <FIG>), e.g. in the form of a storage medium <NUM>. The processing circuitry <NUM> may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

Particularly, the processing circuitry <NUM> is configured to cause the electronic access control system <NUM> to perform a set of operations, or steps, as disclosed above. For example, the storage medium <NUM> may store the set of operations, and the processing circuitry <NUM> may be configured to retrieve the set of operations from the storage medium <NUM> to cause the electronic access control system <NUM> to perform the set of operations.

Thus the processing circuitry <NUM> is thereby arranged to execute methods as herein disclosed. The electronic access control system <NUM> may further comprise a communications (comm. ) interface <NUM> at least configured for communications with other entities, functions, nodes, and devices. As such the communications interface <NUM> may comprise one or more transmitters and receivers, comprising analogue and digital components. The processing circuitry <NUM> controls the general operation of the electronic access control system <NUM> e.g. by sending data and control signals to the communications interface <NUM> and the storage medium <NUM>, by receiving data and reports from the communications interface <NUM>, and by retrieving data and instructions from the storage medium <NUM>. Other components, as well as the related functionality, of the electronic access control system <NUM> are omitted in order not to obscure the concepts presented herein.

The electronic access control system <NUM> may be provided as a standalone device or as a part of at least one further device. Thus, a first portion of the instructions performed by the electronic access control system <NUM> may be executed in a first device, and a second portion of the of the instructions performed by the electronic access control system <NUM> may be executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the electronic access control system <NUM> may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by an electronic access control system <NUM> residing in a cloud computational environment. Therefore, although a single processing circuitry <NUM> is illustrated in <FIG> the processing circuitry <NUM> may be distributed among a plurality of devices, or nodes. The same applies to the computer program <NUM> of <FIG>.

Claim 1:
An electronic access control system (<NUM>, <NUM>, <NUM>, <NUM>) for a device (<NUM>, <NUM>, <NUM>), wherein the electronic access control system (<NUM>, <NUM>, <NUM>, <NUM>) comprises an OIDC Electronic access control system, OACS, client (<NUM>, <NUM>, <NUM>) and an OACS gateway (<NUM>, <NUM>, <NUM>) to an OIDC provider (<NUM>, <NUM>, <NUM>), wherein the OACS gateway (<NUM>, <NUM>, <NUM>) implements an OIDC client (<NUM>, <NUM>, <NUM>), and wherein the OACS gateway (<NUM>, <NUM>, <NUM>) is configured to:
obtain, via the OACS client (<NUM>, <NUM>, <NUM>), a request for the OACS gateway (<NUM>, <NUM>, <NUM>) to issue a service ticket for a user agent (<NUM>, <NUM>, <NUM>), the request comprising an indication that the user agent (<NUM>, <NUM>, <NUM>) requests to access a service on the device (<NUM>, <NUM>, <NUM>), wherein the service is associated with a permission;
retrieve, via the OIDC client (<NUM>, <NUM>, <NUM>), a profile for the user agent (<NUM>, <NUM>, <NUM>) and an access control list for the profile and the device (<NUM>, <NUM>, <NUM>) from the OIDC provider (<NUM>, <NUM>, <NUM>);
responsive to having confirmed, by checking the access control list for the profile and the device (<NUM>, <NUM>, <NUM>), and by checking the profile itself, that the profile fulfils the permission to access the service on the device (<NUM>, <NUM>, <NUM>):
generate a service ticket that validates the user agent (<NUM>, <NUM>, <NUM>) for a one-time access to the service, wherein the service ticket is a token that is signed by the OACS gateway (<NUM>, <NUM>, <NUM>); and
provide, via the OACS client (<NUM>, <NUM>, <NUM>), the service ticket towards the user agent (<NUM>, <NUM>, <NUM>).