Access control enforcement architecture for dynamic manufacturing systems

Abstract

Embodiments of the present disclosure relate to an access control enforcement architecture for dynamic manufacturing systems. A computer system comprising one or more resource servers (220) having resources (223), access to the resources (223) being controlled according to a control policy specified in a computer-readable access control language, and a centralized authorization server (240) that is common to the resource servers (220) and implements a second type policy decision point (240'). The computer system further comprises a first type policy decision point (241') and one or more second type policy decision points (241"), the first type policy decision point (241') being implemented by the authorization server and configured to decide on dynamic policy privileges, the second type policy decision points (241") being implemented by respective ones of the resource servers and configured to decide on static policy privileges.

Description

Technical Field

[0001] This disclosure relates to the field of cybersecurity mechanisms within Industrial Automation and Control Systems (IACS). Several access control implementation architectures are presented that can be practically used to dynamically modify access control scenarios. Furthermore, implementation examples demonstrate how specific policy expression models can be combined with recommended architectures that conform to specific industry standards. Background Technology

[0002] Access control is one of the primary security mechanisms in any modern information system. In industrial systems such as industrial control systems, logistics, and manufacturing, cybersecurity is an increasingly important attribute. Given recent cyberattacks and the technological evolution towards increasingly connected and digital manufacturing systems, it is clear that many cybersecurity practices must be modified. Access control is also becoming increasingly important at lower layers of control systems, as these layers are also suitable for more service-based approaches.

[0003] Among the emerging features of industrial manufacturing systems, adaptive manufacturing, as described in, for example, modular automation [1], [2], [3], means a constantly changing set of production equipment that is combined in different ways and follows different workflow schemes to meet the needs of rapid production transfer. This feature makes traditional methods for describing and implementing access control policies less useful in terms of, for example, management efforts and the possibility of following the principle of least privilege [4].

[0004] In a questionnaire survey study, partly as mentioned in [5], active cybersecurity professionals in the Swedish industry were asked about the technical and perceived challenges related to access control. Several of the challenges identified were directly related to the functionality of the implementation architecture, such as finding the right balance between availability and security, and the challenge of distributing policy data to devices. This disclosure aims to propose mechanisms to combat some of these perceived challenges.

[0005] To address the dynamic nature of future manufacturing systems, access control policies must provide flexibility and dynamism. Attribute-based access control (ABAC) is a policy model that can provide this increased flexibility [6], [7]. Equally important is that the mechanisms used to implement the policies can support timely and up-to-date policy decisions. The two most important functions of an access control implementation architecture are: 1) providing access decisions, and 2) granting or denying access to resources based on the access decisions.

[0006] Open Process Communications Unified Automation (OPC UA) is a communication protocol that is increasingly being used as an interoperable protocol in Operational Technology (OT) environments. The protocol is described in the IEC 62541[8] series of standards and includes descriptions on how to achieve advanced communication security. The authorization-related guidelines described essentially limit the interoperability portion to role-based access control (RBAC)[9], which may not be the best fit for dynamically changing systems

[10] .

[0007] Chandramouli et al.

[11] described how to use a service mesh for microservice-based applications to build an implementation architecture for attribute-based access control. This approach is based on “side-car” containers that exist on all cluster nodes and function as policy enforcement points (PEPs). This architecture supports full mediation because all access requests are routed through the “side-car” containers. This approach is designed for cloud-native microservices executed on containerized platforms. Furthermore, this invention relates to manufacturing systems, which typically include applications running on dedicated equipment that do not allow mediation in this manner. However, the concept of separating policy enforcement into a separate process is of interest and useful for multi-service equipment in manufacturing systems.

[0008] Martinelli et al.

[10] proposed an implementation architecture for OPC-UA that allows for the inclusion of variable attributes, as described in the Use Control (UCON) access control model (an extension of ABAC). However, this architecture does not utilize any of the standard components for authorization described in the OPC-UA standard. For example, the PDP is placed entirely on the “Use Control System,” which contains several components not described in the standard, and the PEP is extended to have components on the client and server, etc. This means that the solution is by no means interoperable with the current OPC-UA standard compared to the approach proposed in this paper, which in principle utilizes the available standardized approach.

[0009] Sudarsan et al.

[12] provide an investigation of available technologies for access control models, sub-authorization models, and authorization management in the context of IoT and CPS, particularly from the context of unrestricted devices. Their focus is on sub-authorization models, i.e., how authorization is delegated. OAuth is discussed in detail here, with references to several works describing the advantages and disadvantages of authorization delegation using OAuth tokens. Attribute-based access control (ABAC) and next-generation access control (NGAC) are discussed, with particular emphasis on the advantages of NGAC over XACML in terms of the complexity and time required for rule reasoning. This context aligns well with the use cases discussed in this disclosure, as interactive devices in manufacturing systems based on modular workflows are often relatively robust compared to simple sensors that may be part of the underlying module.

[0010] Dramé-Maigné et al.

[13] provided a broad existing research on implementation architectures for IoT systems, with a particular focus on available solutions for token-based implementations. They presented four main architectural concepts: centralized, hierarchical, federated, and distributed, as well as evaluations of several verticals. In principle, the approach follows a hybrid centralized / distributed approach, with centralized policy decisions for dynamic permissioning and role allocation, and local decisions for static role permissioning. Summary of the Invention

[0011] The purpose of this disclosure is to propose a method for constructing an access control implementation architecture that mitigates perceived challenges and is practically useful in Industrial Automation and Control Systems (IACS), particularly in manufacturing environments. The implementation architecture should preferably support the characteristics of dynamic and flexible manufacturing systems (and the control systems associated with them) and can be implemented using available industry standards. Another objective is to propose different strategies for using claim-based tokens as part of the enforcement mechanism, including how to use access tokens to formulate access control policies expressed using a standardized ABAC policy model.

[0012] At least some of these objectives are achieved by means of the invention as defined in the independent claims. The dependent claims relate to advantageous embodiments of the invention.

[0013] In a first aspect of the invention, a computer system having the technical features of claim 1 is provided.

[0014] This technical feature allows dynamic policy privileges and static policy privileges to be handled differently. The purpose of this distinction is to separate the parts of access control policies that change relatively more frequently (dynamically) or are expected to change from the relatively more stable rest. Performing all decisions locally on the resource server reduces the necessary communication within the computer system, but can also introduce the inconvenience of having to update all locally stored copies of the access control policy in case of changes. If decisions involving dynamic policy privileges are submitted to a centralized authorization server, this reduction is maintained, and the inconvenience is minimized. Frequent updates to those parts of the access control policy affecting dynamic policy privileges can be performed with limited effort because the centralized authorization server is public to the resource server. This advantage is even more pronounced if the second type of PDP is associated with a local policy data warehouse that stores only a portion of the access control policy, which is independent of dynamic policy privileges; therefore, unless the static policy privileges are changed, this portion of the access control policy does not need to be updated.

[0015] It should be understood that the licensing server is distinct from (independent of) some or all of the resource servers. Preferably, both the licensing server and the resource server include input / output interfaces for communicating with other entities in the computer system, and these two input / output interfaces should be different. This allows for frequent reconfiguration of variable explicit licenses / restrictions without significantly increasing the number of calls to the resource server's input / output interfaces.

[0016] In some embodiments, a single centralized authorization server exists, which is therefore shared by all resource servers in the computer system. In other embodiments, the resource servers are clustered into multiple groups, each group sharing the authorization server, through which access control policies can be easily updated to affect the dynamic policy privileges determined therein.

[0017] In some embodiments, dynamic policy privileges are determined based on at least one explicit permission / restriction of a user for a resource, where the explicit permission / restriction directly references the resource. Additionally or alternatively, static policy privileges are determined based on at least one role associated with a user, where each role references the resource only indirectly via an access control policy. In this sense, a "role" can be functionally understood as an instruction to grant membership to a set of privileges or permissions specified in an access control policy. Roles do not need to be permanently associated with a user, but the association can be reconfigured. However, for effective management of policy privileges, the intended use is for roles to represent static or semi-static attributes of a user and rely on explicit permissions / restrictions for minor and / or short-term modifications.

[0018] In other embodiments of the first aspect of the invention, a first type of PDP is configured to generate (e.g., upon request from a user or user client) an access token indicating at least one role associated with the user and at least one explicit permission / restriction for accessing at least one resource, wherein each permission / restriction directly references at least one resource, and each role only indirectly references a resource via an access control policy. The content of the access token combines roles and explicit permissions / restrictions, where roles allow for a concise expression of the bundle of static policy privileges, and explicit permissions / restrictions increase the specificity and ease of reconfiguration of dynamic privileges. Additionally, the size of the access tokens generated by the authorization server can be controlled, which limits the sharing of internal communication capacity dedicated to access control transactions and / or helps to comply with predetermined size limits on access tokens. The dichotomy between static and dynamic policy privileges can be defined not only based on the factors discussed above (convenient central reconfiguration of dynamic privileges, local decision-making for static privileges) but also considering the need to control the size of access tokens. If the static category absorbs a larger share of policy privileges, the average size of the access tokens can be expected to decrease.

[0019] In another embodiment, the first type of PDP is also configured (e.g., upon request from a user or user client) to generate a single-operation access token indicating that the permission for accessing a resource is exercised only once. The single-operation access token can be used for isolated resource requests. It can also be used to open a new session between the user client and the resource server, or to refresh the current session. This allows for any level of dynamism in policy evaluation for sporadic resource requests, rather than issuing a sufficiently complete new access token to replace the currently valid one. For example, considering the inconvenience of having to instruct (for all open sessions) all potential actions, it allows the operator to act relative to all processed objects in a complex manufacturing environment with an alternative access token. Advantageously, the availability of single-operation access tokens allows policies to approach even closer to the principle of least privilege expressed and enforced in computer systems. Single-operation access tokens can also provide a useful shortcut for specifying policy privileges that are difficult or impossible to express in terms of roles and / or explicit permissions / restrictions from those roles.

[0020] Another envisioned use case for single-operation access tokens is implementing dual approval, where access control policies only allow access if a user receives supplementary approval from one or more other users. Dual approval can serve as a security measure to prevent unintentional use of expensive or dangerous resources in a computer system, such as stopping a machine during manufacturing or draining a large container of processing liquids. In a dual approval setup, each sub-approval can then be expressed and transmitted in the form of a single-operation access token.

[0021] The computer system according to the first aspect can be included in a distributed control network, a security network, a factory automation network, an industrial automation network (e.g., for supporting dynamic manufacturing systems), a mobile robot control system, or it can be used in similar industrial applications.

[0022] In a second aspect of the invention, an authorization server having the technical features of claim 9 is provided. The authorization server is configured to be included in a computer system, wherein decisions regarding dynamic and static policy privileges are assigned to different entities. More precisely, the authorization server has a first type of PDP that determines dynamic policy privileges in response to a request from a user client, but submits any decisions regarding static policy privileges to a second type of PDP in a resource server. The authorization server is common to all these resource servers, thus enabling convenient and centralized reconfiguration of dynamic policy privileges, as described above.

[0023] In a third aspect, a method is provided in a user client comprising the steps defined in claim 10. The method includes obtaining an access token indicating at least one explicit permission / restriction of at least one role associated with a user and at least one of access resources, and submitting the access token to a resource server (resource request) when the user client intends to access the resource. The content of the access token combines roles and explicit permissions / restrictions, where roles allow for a concise expression of bundles of static policy privileges, and explicit permissions / restrictions increase the specificity and ease of reconfiguration of dynamic privileges. Furthermore, the size of the access token generated by the authorization server can be controlled, which limits the sharing of internal communication capacity dedicated to access control transactions and / or helps to comply with predetermined size limits on access tokens.

[0024] In a fourth aspect, a method for generating access tokens in an authorization server having the steps of claim 12 is provided. As already explained, the content of the access token combines roles and explicit permissions / restrictions, where roles allow for a concise expression of the binding of static policy privileges, and explicit permissions / restrictions increase the specificity and ease of reconfiguring dynamic privileges. This also makes it possible to effectively control the size of the access token.

[0025] In embodiments where processing in the authorization server excludes any decisions regarding policy privileges based on one or more user roles (e.g., permissions / restrictions associated with user roles), the method is suitable for execution in computer systems where decisions regarding dynamic and static policy privileges are assigned to different entities. In practice, decisions regarding policy privileges flowing from user roles can be submitted to a second type of PDP in a resource server within the computer system.

[0026] In a fifth aspect of the invention, a method is provided in a resource server having the steps of claim 14, wherein an access token is processed, and at least in part based on granting access to resources in the resource server. The result of the policy decision can be described as permissions associated with a user role (such as those determined by evaluating access control policies) and explicit permissions indicated by the access token after deducting any explicit restrictions indicated by the access token. The content of the access token combines roles and explicit permissions / restrictions, where roles allow for a concise expression of a set of static policy privileges, and explicit permissions / restrictions increase the specificity and ease of reconfiguring dynamic privileges. Furthermore, the size of the access token to be sent to the resource server can be limited.

[0027] In some embodiments of the fifth aspect, a decision regarding permission / restriction is performed when a user client makes a resource request. In other embodiments, the decision is performed in advance, for example, upon receiving an access token, in which case the result can be temporarily stored for later use.

[0028] Other aspects of the invention provide a user client configured to perform the methods of the third aspect, an authorization server configured to perform the methods of the fourth aspect, and a resource server configured to perform the methods of the fifth aspect. These additional aspects are expected to have the same technical effects and advantages as the methods, and they can be implemented with corresponding variations.

[0029] The present invention also relates to a computer program containing instructions for causing a computer, or particularly an apparatus and system, to perform the methods described above. The computer program may be stored or distributed on a data carrier. As used herein, "data carrier" can be a transient data carrier such as modulated electromagnetic waves or light waves, or a non-transient data carrier. Non-transient data carriers include volatile and non-volatile memories, such as permanent and non-permanent storage media of the magnetic, optical, or solid-state type. Still within the scope of "data carrier," such a memory may be fixedly mounted or portable.

[0030] In some embodiments, access control policies can be specified, for example, in an attribute-based access control (ABAC) language. Currently, there are general-purpose AC languages ​​that richly express fine-grained conditions and conditions dependent on external data. A concrete example of an ABAC language is the Extensible Access Control Markup Language (XACML), the subject of standardization work in the Technical Committee on the Organization for Promoting Structured Information Standards (OASIS, www.oasis-open.org). Policies encoded in XACML define access control permissions based on attributes of the subject, the resource, and the action (e.g., read, write) the subject wants to perform on the resource. The policy consists of a function expression in the attribute values, and the return value (decision) of the policy is one of: permitted, denied, inapplicable, or uncertain. In these embodiments, the user's role is represented as the value of the attribute in the access control policy. A potential improvement to the basic ABAC concept of this invention is the addition of functionality for querying the complete set of permissions regarding the relationship between a client (user client) and a resource.

[0031] In the terminology of this disclosure, the term "user" should be interpreted broadly. It can refer to a human user, a network processor, a server, a machine or part thereof, a software process, or any other entity that may be assigned access rights according to access control policies. In this sense, "user" may be equivalent to "subject" in NGAC and other standardized terms.

[0032] The term "user client" refers to the hardware or software that enables users to interact with a computer system in general and with resources specifically.

[0033] A "server" or host computer is understood as a device or computer subsystem capable of providing specific facilities to other devices (clients) attached to a network. A server can be characterized as a network-connected processor or memory such that its capabilities are at least partially and at least temporarily handled by the client.

[0034] "Resource" can be, for example, a portion of a personal storage quota, a business unit storage quota, an information retrieval system, a portion of a database, an online service, a protected webpage, or a physical device. In the specific context of an industrial access control system, a resource can be input / output signals connected to an industrial process and application code controlling that process. The term "resource" can be used interchangeably with "object." In the sense of the claims, a resource server positioned below (i.e., away from) the resource with which the user client interacts is also a "resource." This type of hierarchical topology can be used to implement the invention in conventional systems where, if the PEP of the internal resource server has this capability, the external resource server does not need to be equipped with a PEP capable of enforcing explicit permission / restriction in the access token according to the invention.

[0035] "Attributes" are characteristics of elements that can be referenced in expressions within ABAC strategies, particularly in predicates, conditions, and rules.

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

[0037] Aspects and embodiments will now be described by way of example with reference to the accompanying drawings, in which:

[0038] Figure 1 The components of the authorized implementation architecture are shown;

[0039] exist Figure 2A-2D Four licensing architectures are shown in the diagram;

[0040] Figure 3 This is an architecture overview diagram of the example use case (ice cream factory);

[0041] Figure 4 Includes illustrations of when initializing a session, reading signals, and executing commands. Figure 3 The sequence diagram depicting the information exchange between entities; and

[0042] Figures 5 to 7This is a flowchart illustrating different aspects of the process by which a user interface requests and obtains access to resources on a resource server, with the assistance of an authorization server. Figure 5 Methods involving the user client, Figure 6 Methods involving the authorization server, and Figure 7 Methods involving resource servers. Detailed Implementation

[0043] Various aspects of this disclosure will now be described more fully below with reference to the accompanying drawings, in which certain embodiments of the invention are illustrated. However, these aspects may be implemented in many different forms and should not be construed as limiting; 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 all aspects of the invention to those skilled in the art. Throughout the specification, the same reference numerals denote the same elements.

[0044] Implementation Architecture – Recommended Design

[0045] In order to effectively enforce policy rule sets in a system, the design of the implementation architecture is crucial. This section introduces the basic components of an access control implementation architecture, as well as four different architectural patterns for implementing an implementation architecture that supports dynamic access control.

[0046] Elements of an attribute-based access control implementation architecture

[0047] Based on the distributed access control mechanism model provided by Hu et al.

[14] , Figure 1 The basic components of the implementation architecture are described in the document. The terminology is also found in IETF RFC 2904. This architecture includes a Policy Management Point (PAP) 150, which provides administrative functions input by the administrator 101, namely, updating policy data; a Policy Information Point (PIP) 160, which provides an interface for querying policy data; a Policy Decision Point (PDP) 141, which contains logic for deciding whether to allow or deny resource requests from a topic; and a Policy Enforcement Point (PEP) 122, which executes policy decisions regarding resource 123.

[0048] Complete conformity with Hu's model is not necessary for this invention. It is important how critical steps are allocated among entities identified as PAP, PIP, etc., while optional or less critical steps can be allocated as needed in specific use cases.

[0049] This structure is particularly effective if all resource requests are mediated by the PEP. Before allowing an object to access a resource, the resource request must be evaluated against available policy data prepared by the PDP, which reads the policy data from the PIP.

[0050] Architectural patterns for dynamic access control

[0051] Many architectural patterns are possible using the components defined above. This disclosure focuses on policy decision-making and implementation; therefore, PAP and PIP are omitted below, assuming that the PDP has access to the policy data it needs and that secure and effective management of the policy data is possible.

[0052] In the context of dynamic manufacturing systems, one type of resource server (RS) serves as a digital interaction point for physical manufacturing modules, for example, displaying signal values ​​for supervision and methods for high-level control of the modules. Clients act as operators monitoring the process, digital orchestrators performing high-level control operations, data history services, sibling modules, etc. In other words, clients representing both human users and purely digital entities are possible. For the interaction between clients, PDPs, PEPs, and RSs, consider the following four architectural patterns:

[0053] (a) Client (or user client) 210 provides credentials in some form, and all logic used to infer permission resides in RS 220, namely PDP 241 and PEP 222, along with resource 223. RS 220 is configured with this information by any suitable method, such as through reference policy 230. See Figure 2A .

[0054] (b) Client 210 provides credentials to RS 220 in some form, and all logic used to infer licenses resides in the Authorization Server (AS) 240. That is, RS 220 requests each resource from external PDP 241. See Figure 2B .

[0055] (c) When client 210 makes a resource request, the request itself contains all the logic required to infer permission, encoded in a token issued by trusted AS 240. RS 220 requires no additional configuration to infer permission from the token. All PDP logic resides in the AS.

[0056] Furthermore, all PEP functions reside in RS 220. See Figure 2C .

[0057] (d) The client's resource request contains information for inference, but RS 220 requires additional logic to infer permission. The provided token may, for example, contain the set of roles the client possesses relative to the resource. RS 220 knows how to infer permission from the token data.

[0058] The PDP is divided into two sub-PDPs, 241' and 241', between AS and RS. These access policy data come from their respective repositories, 230' and 231'. See Figure 2D .

[0059] User client 210, resource server 220, and authorization server 240 can form part of a computer system. Besides Figure 2A-2D In addition to the components explicitly shown, user client 210, resource server 220, and authorization server 240 may each include memory, processing circuitry, and input / output interfaces. Furthermore, it is assumed that these entities include mutually synchronized clocks.

[0060] Inferences regarding the suggested method

[0061] In architecture (a), the responsibility for inferring resource permissions rests with the resource server, which needs access to policy data and knows how to use it. Even if the server endpoint is not severely resource-constrained in terms of computing power or storage availability, storing the complete set of possible users and the complete set of policy data required to infer permissions for a specific user is impractical. Furthermore, for dynamic components, the policy data must also be up-to-date.

[0062] In architecture (b), the RS is the active entity associated with the PDP and is responsible for initiating the communication channel for policy decisions. Therefore, this pattern forces the RS to be an active client relative to the AS in order to protect its resources, which seems impractical. It may also result in long response times due to communication chain and scalability issues.

[0063] In architecture (c), the client is responsible for attaching the information required for RS to enforce policies. This is done through a delegation by the AS, which issues a security token containing information about the validity of a specific resource request and a guarantee. In this architecture, the access token must contain explicit permissions because the resource server only contains PEPs. This requires the AS to have very detailed knowledge of RS operations and may require a token containing a large amount of information to convey the permissions.

[0064] Structure (d) allows portions of the PDP and policy data to be available to the resource server, and these portions are passed in the access token, as described in structure (c). In this architecture, the PDP' placed in the AS can determine dynamic policy privileges, while the PDP' placed in the RS determines static policy privileges, allowing for separation between dynamic and static permissions.

[0065] The following premises are derived from inference:

[0066] - Centralized dynamism: For a strategy decision point to make the correct decision, it needs access to the strategy and related data. For dynamic strategy data, it is impractical to require all Resource Servers (RSs) to save or retrieve the latest copy of this dynamic information. Therefore, the dynamic part of strategy decision-making should be centralized.

[0067] - Localized implementation: The implementation of strategic decisions must be close to the requested resources in order to be efficient.

[0068] - An active client: The client is the active party in the access token request. If possible (using secure methods), it should also be an active entity associated with other entities in the system.

[0069] Reviewing the presented architectural patterns, using these premises, we can draw the following conclusions: Architecture (a) allows for localized implementation and active clients, but contradicts the premise of centralized dynamism. Architecture (b) allows for localized implementation and centralized dynamism, but contradicts the premise of active clients. Architecture (c) adheres to the expressed premises, but may be infeasible in complex scenarios. Architecture (d) adheres to all expressed premises while potentially keeping the amount of information contained in the access token manageable.

[0070] The inference shows that architectures (c) and (d) can achieve these premises. Both alternatives use access tokens to pass privileges, and are further examined in the following sections.

[0071] As described above, in the variant of architecture (d), the external resource server can be deployed as a resource of the internal resource server. It should be understood that the user client interacts with the internal resource server (aggregated resource server), and the user client can only access the external resource server if the internal resource server permits it. The internal resource server does not need to have any resources of its own; it merely acts as an intermediary. This type of hierarchical topology can be used to implement the invention in legacy systems, whereby the external resource server does not need to be equipped with a PEP capable of implementing explicit permission / restriction in the access token according to the invention, if the internal resource server's PEP has such capability.

[0072] If the external resource server is unable to enforce explicit permissions / restrictions in the access token, the internal resource server can be configured to apply these explicit permissions / restrictions to selectively forward any resource requests that would be permitted under the explicit permissions / restrictions and to block any resource requests that would be denied under the explicit permissions / restrictions. The inability of the external resource server to enforce explicit permissions / restrictions may be due, for example, to the use of novel syntax elements that its PEP cannot handle or due to other incompatibilities. Providing an (aggregated) resource server between the user client and the external resource server may be a more convenient option than upgrading all local PEPs in the existing computer system 200.

[0073] Use access tokens for dynamic access control

[0074] This section explores different ways of expressing claims in access tokens. A major issue with using access tokens is knowing what information will reside in the token and what logic is needed to infer permission from that information. Access tokens are typically used to activate a session between a client and a server, and therefore must contain information that is effective for policy enforcement throughout the session.

[0075] A typical way to express privileges in access tokens is through role declarations, such as the OPC UA standard which describes a list of well-known roles that AS and RS are expected to use. This is a logical approach for cases where the privilege set is static, but to allow for dynamic cases, such as workflow-based scenarios, the content passed in the token must be more specific.

[0076] Explicit license

[0077] One option is to provide an explicit permission statement, where the RS does not need to execute additional logic to determine what the client is allowed to do, which is related to architecture (c). The AS must have detailed knowledge of the resources protected by the resource server and express the current permissions for a particular client. As mentioned above, this leads to an increase in the size of the access token, especially for complex resource servers.

[0078] Dynamic character configuration

[0079] Another alternative is to allow dynamic behavior through dynamically configured Resource Servers (RSs), enabling fine-grained permission inference based on local policy data. In this case, tokens can still contain simple data about static roles, but the resource server can provide dynamic transfer of resource permissions based on variations of architectural pattern (d). This approach somewhat conflicts with the premise of centralized dynamism and would be impractical in systems with frequent permission shifts, but it may be a good alternative for systems where active permissions are static most of the time.

[0080] Static roles and explicit licenses

[0081] The third alternative is to combine roles and explicit licenses, using static roles known to the resource server for unchanging licenses, while explicit licenses can be used for privileges that change over time. This is also a variation of structure (d).

[0082] There exists a set of permissions that can be quite easily bound to a role and may not change significantly over time. One such example is a role observer, which grants read access permissions to most data. Using static roles along with explicit permissions (e.g., permissions associated with the current active workflow) will give a more balanced set of statements to be expressed in the access token compared to using only explicit permissions.

[0083] Single operation flag

[0084] Another variation of architecture (d) uses roles for static licenses and single-action tokens for licenses that change over time. For licenses not covered by static roles, the client will specifically request a single-action token, including an identifier of the action. The AS will evaluate the access token request and, if authorized, issue a token containing a statement that can only be used to exercise the license once. The token is used to open a new session or refresh the current session. This scheme will allow for any level of dynamism in policy evaluation for sporadic resource requests, as any such interaction will require the issuance of a new token. Single-action tokens are not currently part of the JWT standard

[15] .

[0085] Single-operation tokens are a specialization of the third alternative mentioned above, allowing policies to approach even closer to the principle of least privilege expressed and enforced within the system. For some types of interactions, single-operation tokens are a more practical concept—considering, for example, all the potential actions an operator could take relative to all process objects in a complex manufacturing environment, it would be wasteful to pre-compute them all and cram them into access tokens for all open sessions. Instead, timely and on-demand evaluation and granting of permissions is preferable.

[0086] accomplish

[0087] The preceding sections provided recommendations on an architecture for flexible access control, and detailed ways to implement such an architecture using access tokens. This section describes how to implement such an implementation architecture. The approach followed in this disclosure is to use policies expressed in Next Generation Access Control (NGAC) delivered as claims in JSON Web Tokens (JWTs), which leverages available standardized mechanisms also supported by the OPC UA standard.

[0088] Among the proposed approaches, the most balanced and flexible solution follows architectural pattern (d), with static roles for privileges that are constant over time and explicit permissions for privileges that change over time. An implementation architecture following this approach is also outlined. The purpose of this implementation is primarily to demonstrate the feasibility of the proposed approach.

[0089] In .NET Core, C# uses the OPC Foundation.NET OPC UA stack for communication and interaction, the Microsoft.IdentityModel function for JWT creation, and the Policy Machine (https: / / github.com / PM-Master / policy-machine-core) for NGAC policy model representation.

[0090] Use Cases

[0091] Consider based on Figure 3 The modular automated system design strategy shown describes the ice cream production process. This specific implementation of the production process includes five independent modules (collectively referred to as 350) for mixing 351, pasteurization 352, homogenization 353, dynamic freezing and flavoring 354, and packaging and static freezing 355. The arrangement of different production methods 312 is accomplished by the arranger unit 330. The method configuration and arrangement follow the method described in

[16] . Figure 3 Engineering interface 310, engineering storage 311, operation interface 320, and authorization service 340 are also shown. All units communicate via a data network.

[0092] Figure 4 This is a sequence diagram illustrating the communications exchanged between orchestrator 330, one of the associated modules 350, and authorization service 340 in three example flows: session creation, reading signals, and executing commands. The second and third flows terminate at one of two alternative sub-flows, depending on whether permission is granted.

[0093] Combining JWT with NGAC

[0094] NGAC

[17] ,

[18] is a policy representation model standardized by the National Institute of Standards and Technology (NIST). In NGAC, a graph representation is used to describe policies, where licenses are evaluated through graphs, which can be done with low computational complexity. NGAC provides the ability to compute the full set of licenses held by an object relative to the computing power of the subject.

[0095] JSON Web Token (JWT) is a container for encoding a claim in a JSON Web Signature (JWS)

[19] or JSON Web Encryption (JWE)

[20] structure, i.e., a payload with a signature and / or encryption. It is a standardized messaging format for providing claims from an AS to a resource. It is a standardized messaging format for providing claims from an AS to a resource. Authorization using JWT is part of the OAuth2 framework

[21] , whose use and claims are described in

[15] . A claim C is defined as C = (n, v), where the first component n is the name and the second component v is the value. The value can be a scalar, an array, or a more complex data type.

[0096] Here is a simple example of the declaration section of JWT:

[0097] {

[0098] "sub":"client_id","aud":"resource_id",

[0099] "name":"readable client name""iat":1516239022,

[0100] "exp":1516241022,

[0101] "roles":["observer","operator"],"entitlements":["method1","method2"], ...

[0103] }

[0104] The Audience (aud) field uniquely identifies the resource, the Sub field identifies the client, the IAT field is the publication time, and the Exp field is the expiration time. The Roles array lists the roles the client has, while the Entitlements list the additional method licenses granted to the client.

[0105] Using these provided declaration classes, JWTs can effectively express static license groups for roles or class roles, as well as more specific rights. If this information can be extracted from the NGAC graph database, the conversion from a list of authorized actions to a set of JWT declarations is possible.

[0106] If using the architecture-based (c) approach, where the AS grants an explicit license, the license can be directly inferred from the NGAC diagram and placed into the token. The NGAC diagram would need to include all possible read, write, and execute operations associated with the RS. This approach eliminates the need for role declarations, placing the license directly within the rights declaration, for example,

[0107] "entitlements":["valve.read","lvl.read","openValve.execute",...]

[0108] If the static role alternative is used, leveraging the dynamic logic in the Resource Server (RS), the token layout and NGAC diagram content can be very simple, such as a flat combination of roles and topics. Rights declarations will not be required. In the NGAC diagram, the association between clients and resource attributes can be the role name rather than the action, because the Action Server (AS) is unaware of the actual permissions. However, when permissions associated with static roles are changed, management of RS reconfiguration is required. This is not covered by the execution architecture.

[0109] Combining static roles and explicit permissions allows for access tokens of reasonable size and complexity, balancing the amount of configuration and logic required in the RS. In this case, rights and role declarations are used. For this to be possible, it must be possible to infer explicit permissions and static roles from the NGAC diagram. However, in NGAC, all permissions are described in the same way. A very simple alternative is to have separate NGAC diagrams for static roles and explicit permissions, respectively. Of course, there are ways to allow explicit permissions and roles to exist in the same diagram, such as through naming conventions or by using attributes.

[0110] If single-operation tokens are used, the client can open separate sessions for these operations, which implicitly requires issuing new tokens. The design of the NGAC diagram does not need to change from the previous example, but the flow for requesting and using access tokens needs to be modified so that the client can issue different types of access token requests to the AS, distinguishing single-operation access token requests from regular access token requests.

[0111] Implementation details

[0112] This section describes the implementation details related to the implementation architecture pattern (d) that uses a combination of static roles and explicit permissions.

[0113] The focus of this implementation is on the components and mechanisms of the execution architecture. Details regarding high-level control, rule execution, real-time characteristics, etc., are omitted. Furthermore, it is assumed that the identification and authentication of different entities are performed securely according to the methods available in the OPC UA standard. We describe the implementation of the interaction between the organizer (as a client) and the module server (as the RS); however, the described architecture and mechanisms are useful throughout the system.

[0114] The approach to creating policies from active rules is to use the algorithm proposed by Leander et al. [4], which maintains privilege updates in the NGAC graph to allow only active rules to be executed. An extension of this algorithm is for monitoring data read operations that are collected under a common observer role that will be assigned to the orchestrator. It is assumed that the module knows the local permissions granted to that particular role. However, for high-level commands, explicit permissions are required.

[0115] All interactions between entities in the system use OPC UA client / server communication. Access token issuance follows an indirect authorization flow as defined in OPC UA Standard 2. Some example sequences of interactions between the orchestrator, modules, and AS are shown in... Figure 4 The sequence diagram is shown.

[0116] Two of these interactions must be further elaborated because the available standards do not describe the logic behind how the AS populates the token and what steps the module takes to verify it. These two interactions detail the policy decision-making and implementation, respectively.

[0117] 1) Token Population: In order for the orchestrator to activate a session, it needs an access token issued by an AS trusted by the module. The orchestrator uses its credentials in calls to the AS, including information about the module's identity. The AS must create the access token, populate it with valid privileges, sign it, and return it to the orchestrator.

[0118] In this implementation, AS queries the NGAC graph database to request all privileges held by the orchestrator on a specific module. Privileges marked as roles are added to the list of role declarations. Any additional explicit permissions are added to the list of rights declarations. For privileges on the pasteurizer module during process execution, the specific access token issued to the orchestrator may contain declarations based on the following:

[0119] {

[0120] "sub":"Orchestrator_id",

[0121] "aud":"Pasteurizer_id","roles":["observer"],

[0122] "entitlements":["StartPasteurize","EmptyTank","FillTank"]

[0123] }

[0124] Thus, the privileges expressed by the NGAC database are expressed in the access token used to activate or refresh an orchestrator session to a specific module. The token contains all the information required for the module to act as a policy enforcement point.

[0125] 2) Request Authentication: When the orchestrator requests resources from a module in the form of data reading or command execution, the module must verify the request against the permission granted by the access token associated with the current session.

[0126] Basic token verification is completed upon session activation; for example, the signature is valid, the issuer is the intended issuer, the audit equals the module's ID, and the token has not expired. Permissions granted by role claims can also be evaluated at this stage.

[0127] However, in this implementation, the correlation between resource requests and licenses is verified at the time of the resource request. Verification is performed as follows:

[0128] - Check the token's expiration time - If it has expired, deny access.

[0129] - Compare resource requests with an explicit list of licenses as part of the rights statement.

[0130] Access is granted if the requested resource matches an explicit license.

[0131] Otherwise, for each role in the role declaration, the resource request is compared with the static licenses granted for that role. If the requested resource matches the role's permissions, access is granted.

[0132] Otherwise, access is denied.

[0133] method

[0134] Figure 5 This is a flowchart of method 500, which can be executed, for example, in a user client 210 associated with a human or non-human user.

[0135] In the first step 510, an access token request is submitted to the authorization server 240, wherein the access token identifies the user of the user client and is associated with the resource. It should be understood that in this disclosure, data exchange operations such as "submit" and "receive" should be broadly interpreted to include data transmission initiated by a sender through a local or wide area communication network, data transmission through an internal data bus, uploading or downloading data to or from shared memory, the receiver polling the sender's data, asynchronous data exchange using a publish / subscribe method, etc.

[0136] In the second step 512, in response to the access request, an access token is received from the authorization server 240. The access token indicates at least one explicit permission / restriction for at least one role associated with the user and at least one resource among the access resources, wherein each permission / restriction directly references the at least one resource, and each role only indirectly references the resource via an access control policy.

[0137] In step 514, the received access token is submitted to the resource server.

[0138] In step 516, a resource request is submitted to resource server 220 to access resource 223.

[0139] Access token request 510 and resource request 516 can be submitted at independent points in time. For example, user client 210 can initiate execution of method 500 to prepare for the establishment of a new session with resource server 220 (e.g., a persistent session with a non-zero duration). Since it is not necessary to synchronize access token request 510 and resource request 516, the acquired access token can be temporarily stored until a new session is requested. Similarly, if user client 210 uses the access token for multiple isolated resource requests instead of a persistent session, the access token can be temporarily stored between these resource requests. For this purpose, after resource server 220 first receives the access token, the access token can be temporarily stored in the memory of resource server 220 or in the memory of user client 210.

[0140] Figure 6 Method 600, which can be executed in the authorization server 240, is shown.

[0141] In the first step 610 of method 600, an access token request is received from user client 210, wherein the access token request identifies the user of the user client and is associated with the resource.

[0142] In the second step 612, at least one role associated with the user is determined. Roles can be determined by querying policy information point 160. The second step 612 may further include an authentication sub-step, i.e., determining the user's identity with the required certainty and possibly by referring to credentials provided in the access token request. Roles are not the basis for decision-making within the context of this method 600, but will be provided within the access token for later use by the second type PDP 241 in resource server 220.

[0143] In the third step 614, based on the access control policy, the authorization server 240 determines the user's dynamic policy privileges to obtain at least one explicit permission / restriction. The obtained permission / restriction is explicit in the sense that it directly references (e.g., uniquely identifies) the resource 223 it relates to.

[0144] In the third step 616 of method 600, an access token is provided. The access token indicates the user's at least one defined role and at least one explicit permission / restriction for at least one of the resources, wherein each permission / restriction directly references the at least one resource, and each role only indirectly references the resource via an access control policy.

[0145] Figure 7 This is a flowchart of method 700 that can be executed in resource server 220.

[0146] In the first step 710, an access token is received from the user client 210. It should be understood that the access token indicates at least one explicit permission / restriction for at least one role associated with the user of the user client 210 and for at least one resource in at least one of the resources 223 in the resource server 220, wherein each permission / restriction directly references the at least one resource, and each role only indirectly references the resource via an access control policy.

[0147] In the second step 712, a policy decision is provided by evaluating the access token against the access control policy. This includes sub-step 712.1, which determines permission / restriction for accessing resources by the user's at least one role based on the access control policy. It also includes sub-step 712.2, which adds these permissions / restrictions to the at least one explicit permission / restriction received in the access token.

[0148] In another sub-step 712.3, the result of decision 712.1 may optionally be temporarily stored until it depends on permission / restriction. For example, such temporary storage may be useful if the second step 712 is performed in advance (e.g., without delay after the access token 710 has been received) to reduce response time when user client 210 submits a resource request.

[0149] In the next step 714, resource server 220 receives a resource request for a user client to access at least one of the resources.

[0150] In the fourth step 716 of method 600, the policy decision provided in the second step 712 is executed, such that the user client is selectively granted access to all, some, or no of the resources it requests.

[0151] discuss

[0152] Interoperability of the proposed methods

[0153] The architecture, workflow, and token content proposed in this disclosure are all within the scope of available standardizations regarding OPC UA and JWT. However, these standards are quite flexible wrt, which is possible. This means that, for example, the concept of using a single operation token can be accomplished using the described routines for session activation with a JWT as the user identity token, but the client, RS, and AS must be aware of the scheme. Typically, the logic used to infer permission from the issued token is not described in detail in the OPC UA standard, and is therefore something that the client and server must agree to use some other type of contract.

[0154] However, the proposed solution provides interoperability, allowing the RS to be configured to require clients to request access tokens from the AS. The AS will then issue a token type that the RS can verify, which the client can then use. As long as the authorization service issues a valid token, there is no risk of privilege escalation attacks, regardless of the client application being used.

[0155] Client-side strategy component

[0156] In the described architectural pattern, no functionality related to policy enforcement and decision-making is placed on the client side. From a security perspective, this decision is easy to understand. Resources should not need to be protected by logic placed on the client—in the case of a malicious client, those checks could be easily bypassed. However, from a usability perspective, clients typically rely on knowledge of active permissions to hide / disable parts of the user interface related to prohibited functionality.

[0157] The OPC UA information model contains information about the activity permissions of an open session, which can be used by the HMI to adapt to dynamically changing policies. Permissions granted by a single operation token are not easily supported—because these permissions are not evaluated until the client attempts to perform the operation.

[0158] Experimental conclusions

[0159] This disclosure presents a method for implementing an access control architecture that is practically useful in a manufacturing environment in conjunction with OPC UA. The proposed method uses client-mediated access tokens issued by an authorization server and mitigates several perceptible challenges identified by practitioners in a questionnaire study.

[0160] The proposed architectural pattern supports features such as a modular, automated design strategy, characteristic of evolving manufacturing systems with a dynamic set of themes, resources, and workflows. Strategies for implementing the architecture with declarative composition are provided, including a description of the use of single-operation tokens, an extension of the current JWT standard.

[0161] To demonstrate its feasibility, an implementation of the method is presented and described, providing details on how the authorization server can use the NGAC policy expression model to populate access tokens and how the client can use available claims to validate resource requests, covering policy decision-making and execution mechanisms.

[0162] Although the implemented solution is simple, it contains the main components of a manufacturing system and uses available standardized solutions.

[0163] Even though the proposed methods and outlined implementations conform to the OPC UA standard, this does not imply that any third-party OPC UA server will be able to use the privileges described in this disclosure. Typically, the logic used to translate privileges into permissions is implementation-specific. As mentioned above, the mechanisms currently described in the OPC UA standard describe role-based access control. Explicit permission claims, represented as rights, are supported by the JWT standard but not by the OPC UA standard.

[0164] The aspects of this disclosure have 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 also possible within the scope of the invention as defined by the appended claims.

[0165] References

[0166] 1.ZVEI—German Electrical and Electronic Manufacturers'

[0167] Association,—Process INDUSTRIE 4.0: the age of modular production,” White Paper, Frankfurt, 2019.

[0168] 2. J. Ladiges, A. Fay, T. Holm, U. Hempen, L. Urbas, M. Obst, and T.

[0169] Albers, “Integration of modular process units into process control systems,” IEEE Transactions on Industry Applications, vol.54, pp.

[0170] 1870–1880, March 2018.

[0171] 3.T.Seifert, S.Sievers, C.Bramsiepe, and G.Schembecker,―Smallscale, modular and continuous: A new approach in plant design,”

[0172] Chemical Engineering and Processing:Process Intensification,vol.52,

[0173] pp.140–150,2012.

[0174] 4.B.Leander,A.Causevic,H.Hansson,and T. ―Towardan idealaccess control strategy for industry 4.0manufacturingsystems,”IEEE Access,vol.9,pp.114037–114050,2021.

[0175] 5.B.Leander,A.Causevic,T. and H.Hansson,―Aquestionnairestudy on the use of access control in industrialsystems,”in 2021 26th IEEEInternational Conference on EmergingTechnologies and Factory Automation(ETFA),2021.

[0176] 6.B.Leander,A.Causevic,H.Hansson,and T. ―Accesscontrolfor smart manufacturing systems,”in Software Architecture,

[0177] pp.463–476,Springer Intl.Publishing,2020.

[0178] 7.V.Watson,J.Sassmannshausen,and K.Waedt,―Securegranularinteroperability with OPC UA,”in INFORMATIK 2019:50JahreGesellschaftfür Informatik–Informatik für Gesellschaft

[0179] (Bonn),pp.309–320,Gesellschaft fürInformatike.V.,2019.

[0180] 8.“IEC 62541 OPC unified architecture,rev 1.05,”standard,

[0181] Internation Electrotechnical Commission,Geneva,CH.

[0182] 9.R.S.Sandhu,E.J.Coyne,H.L.Feinstein,and C.E.Youman,

[0183] ―Computer role-based access control models,”Computer,vol.29,no.

[0184] 2,pp.38–47,1996.

[0185] 10.F.Martinelli,O.Osliak,P.Mori,and A.Saracino,―Improvingsecurity inindustry 4.0 by extending OPC-UA with usage control,”in

[0186] 15th Intl.Conference on Availability,Reliability and Security,ACM,2020.

[0187] 11.R.Chandramouli,Z.Butcher,and A.Chetal,―Attribute-basedAccessControl for Microservices-based Applications Using a ServiceMesh,”tech.rep.,National Institute of Standards and Technology,

[0188] Gaithersburg,MD,Aug.2021.

[0189] 12.S.V.Sudarsan,O.Schelen,and U.Bodin,―Survey on Delegatedand Self-Contained Authorization Techniques in CPS and IoT,”IEEEAccess,vol.9,pp.98169–98184,2021.

[0190] 13.S.Dramé-Maigné,M.Laurent,L.Castillo,and H.Ganem,

[0191] ―Centralized,Distributed,and Everything in between:ReviewingAccessControl Solutions for the IoT,”ACM Computing Surveys,vol.

[0192] 54,no.7,2021.

[0193] 14.V.C.Hu,D.Ferraiolo,R.Kuhn,A.Schnitzer,K.Sandlin,R.Miller,andK.Scarfone,―Guide to Attribute Based Access Control(ABAC)

[0194] Definition and Considerations,”technical report.,NIST,2014.

[0195] 15.M.Jones,J.Bradley,and N.Sakimura,―JSON Web Token(JWT).”

[0196] RFC 7519,May 2015.

[0197] 16.B.Leander,A.Causevic,and H.Hansson,―A recipe-basedalgorithm foraccess control in modular automation systems,”

[0198] technical report,September 2020.

[0199] 17.D.Ferraiolo,S.Gavrila,and W.Janse,―Policy Machine:Features,

[0200] Architecture and Specification,”white paper,NIST,October2015.18.D.Ferraiolo,R.Chandramouli,R.Kuhn,and V.Hu,―ExtensibleAccess ControlMarkup Language(XACML)and Next GenerationAccess Control(NGAC),”pp.13–24,2016.

[0201] 19.M.Jones,J.Bradley,and N.Sakimura,―JSON Web Signature

[0202] (JWS).”RFC 7515,May 2015.

[0203] 20.M.Jones and J.Hildebrand,―JSON Web Encryption(JWE).”RFC

[0204] 7516,May 2015.

[0205] 21.D.Hardt,―The OAuth 2.0 Authorization Framework.”RFC 6749,October2012.

Claims

1. A computer system, comprising: One or more resource servers (220) having resources (223) have access to said resources (223) controlled according to access control policies specified in a computer-readable access control language; as well as A centralized authorization server (240) is public to the resource server (220). The computer system is characterized by: The first type of policy decision point (PDP) (241') is implemented by the centralized authorization server and configured to determine dynamic policy privileges based on the access control policy; and One or more second-type PDPs (241'') are implemented by the corresponding resource servers in the resource servers and configured to determine static policy privileges according to the access control policy.

2. The computer system of claim 1, wherein the dynamic policy privilege is determined based on at least one explicit permission / restriction of the user.

3. The computer system according to claim 1 or 2, wherein the static policy privilege is determined based on at least one role associated with the user.

4. The computer system of claim 1 or 2, wherein the first type PDP is configured to generate an access token indicating at least one role associated with a user and at least one explicit permission / restriction for accessing at least one of the resources, wherein each explicit permission / restriction directly references the at least one resource, and each role only indirectly references the resource via the access control policy.

5. The computer system of claim 4, wherein the first type PDP is configured to generate the access token in response to an access token request from a user client (210), the access token request identifying a user associated with the user client.

6. The computer system of claim 1 or 2, wherein the first type PDP is further configured to generate a single-operation access token, the single-operation access token indicating an access claim that allows permission to access a resource to be exercised only once.

7. The computer system of claim 6, wherein the first type PDP is configured to generate the single-operation access token in response to a specific request from a user client (210), the specific request identifying a user associated with the user client and the resource.

8. The computer system of claim 1 or 2, wherein each second type PDP is associated with a local policy data store (230''), the local policy data store (230'') storing a portion of the access control policy independent of the dynamic policy privileges.

9. An authorization server (240) for use in a computer system (200) according to any one of claims 1 to 8, the computer system (200) further comprising one or more resource servers (220) having resources (223), access to said resources (223) being controlled according to an access control policy specified in a computer-readable access control language. The authorization server is characterized in that it implements a first type of policy decision point (PDP) (241'), wherein the PDP (241') is configured as follows: Dynamic policy privileges are determined based on the access control policy, and According to the access control policy, the decision regarding static policy privileges is submitted to the second type PDP (241'') implemented by one of the resource servers.

10. A method (500) for accessing resources (223) in a resource server (220) of a computer system according to any one of claims 1 to 8, wherein access to the resources is controlled according to an access control policy specified in a computer-readable access control language. The method is implemented in the user client (210) of the computer system and includes: Submit (510) an access token request to the authorization server (240) of the computer system, the access token request identifying the user of the user client and being associated with the resource; Receive (512) access token from the authorization server; Submit the received access token (514) to the resource server; as well as Submit a resource request (516) to the resource server to access the resource. The access token is characterized in that it indicates at least one role associated with the user and at least one explicit permission / restriction for accessing at least a first resource in the resource, wherein each explicit permission / restriction directly references the at least first resource in the resource, and each role only indirectly references the at least second resource in the resource via the access control policy.

11. The method of claim 10, wherein the access token is submitted together with the resource request.

12. A method (600) for generating an access token for enabling access to a resource (223) in a resource server (220) of a computer system according to any one of claims 1 to 8, wherein access to the resource is controlled according to an access control policy specified in a computer-readable access control language. The method is implemented in the authorization server (240) of the computer system and includes: Receive (610) an access token request from the user client (210), wherein the access token request identifies the user of the user client and is associated with the resource; Determine (612) at least one role associated with the user; Based on the access control policy, determine (614) at least the user's dynamic policy privileges to obtain at least one explicit permission / restriction; and Provide (616) access tokens, The access token is characterized in that the access token indicates the user’s at least one defined role and at least one explicit permission / restriction for accessing at least a first resource in the resource, wherein each explicit permission / restriction directly references the first resource in the resource, and each role only indirectly references at least a second resource in the resource via the access control policy.

13. The method of claim 12, wherein the user's role is excluded from the decision (614) based on the access control policy.

14. A method (700) for processing an access token associated with a resource (223) in a resource server (220) of a computer system according to any one of claims 1 to 8, wherein access to the resource is controlled according to an access control policy specified in a computer-readable access control language. The method is implemented in a resource server (220) and includes: Receive (710) access token from user client (210); (712) Policy decision is provided by evaluating the access token against the access control policy; Receive (714) a resource request for the user client to access at least one of the resources; and Implement the strategy decision described in (716), The access token is characterized in that it indicates at least one role associated with the user and at least one explicit permission / restriction for accessing at least a first resource in the resource, wherein each explicit permission / restriction directly references the at least first resource in the resource, and each role only indirectly references the at least second resource in the resource via the access control policy. Furthermore, it is characterized in that the strategy decision is provided through the following operation (712): Based on the access control policy, determine (712.1) the permission / restriction for access to resources that follow at least one of the user's roles, and Add the license / restriction (712.2) to the at least one explicit license / restriction received in the access token.

15. The method of claim 14, wherein the decision (712.1) on permission / restriction is performed upon receiving (710) the access token, and the result is temporarily stored (712.3).

16. The method of claim 14, wherein the decision (712.1) on the permission / restriction is performed upon receiving the resource request (714).

17. An apparatus (210, 220, 240) comprising a memory, an input / output interface, and a processing circuitry system configured to perform the method (500, 600, 700) according to any one of claims 10 to 16.

Images