Patent Application
20230053907
The present disclosure relates generally to systems and methods for managing the performance of operations on secure elements, and in particular for a system for managing such performance using an external identity management service.
It is beneficial in many circumstances to permit regulated access to particular resources via the Internet. Such systems typically verify the identity of those that request access to those resources and manage that access based on the verified identity and pre-defined but configurable rules. One example of such a system is a system used to sign data such as software code.
Data is sometimes provided to devices which have already been distributed to end users (e.g. fielded devices). Such data may be needed to update the device(s) to newer configurations or to perform additional functions, to ameliorate software “bugs” or other issues, or to simply replace data already resident in the device that may have been compromised. Such data may include software instructions (e.g. code) update fielded devices by providing data such as software code to those devices remotely.
One of the problems with the remote downloading of such data to fielded devices is that the data may be from an unauthorized source. An entity providing the data to the fielded devices may pose as a legitimate source of the data, yet provide data that is designed to compromise the security or functionality of the device. For example, the user of the device may be misled into believing that their device needs a software update in order to function properly, and may be provided a bogus uniform resource location (URL) from which to download the software update. If the user downloads and installs the software update from the bogus URL, the code that is actually downloaded may include a virus or other malware that negatively affects the operation of the device, perhaps compromising all of the data (including the user's private information) that was stored by the device before the infected.
To prevent the foregoing problems, code signing techniques can be used to digitally sign data such as executables and scripts. Such signatures confirm the identity of the author of the data and guarantee that the data has not been altered or otherwise corrupted since it was signed. Most code signing paradigms provide a digital signature mechanism to verify the identity of the author of the data or build system, and a checksum to verify that the data object has not been modified. Such code signing paradigms typically use authentication mechanisms such as public key technologies, which rely on data publishers securing their private keys against unauthorized access. The public key used to authenticate the data signature should be traceable back to a trusted root certificate authority (CA) or trusted root public key. If the data signature is traced to a CA or public key that the device user trusts, the user is presumed to be able to trust the legitimacy and authorship of the data that is signed with a key generated by that CA or signing authority.
Systems for data signing are known in the art. Such systems provide a framework that allows different organizations or companies to structure their data signing permission needs as they see fit or to safely permit data signing by other independent organizations. Such data signing systems typically use a fixed hierarchy of entities to manage the signing of data. For example, such a fixed hierarchy may include, in decreasing hierarchical order, a platform entity, a project entity, a model entity and a configuration that defines the signing of the data itself. There are three roles with rigid permission structure: (1) administrators, who can do anything, (2) model managers that can manage users for the configurations subordinate to the model, and (3) users that can use the configuration itself to sign data. Signing systems using this hierarchy are disclosed in U.S. Patent Publication. No.: US 2017/0257380, which is hereby incorporated by reference herein.
In some instances, a more flexible config and permission management is desirable. For example, it may be desirable in the hierarchy of entities to define different or parallel entities, or to assign more or fewer roles to those entities. Alteration of known data signing systems to permit such configurations can be costly and time consuming, and may have application limited to individual clients. What is needed is a system and method permitting more flexible hierarchical entity and role definitions to be used with existing resource access and control management systems to permit actions such as data signing. Such a system and method is described herein.
To address the requirements described above, this document discloses a system and method for performing an action on at least one resource node of a hierarchical organization of resource nodes. In one embodiment the method comprises: receiving a login request in secure server; redirecting the login request to an identity provider, the identity provider defining a hierarchical organization of node resources, each node resource having one or more scopes and one or more attributes, each one or more scope associated with a scope permission, wherein each node resource is either a management node resource for maintaining the hierarchical organization of the node resources or a configuration node resource for performing the action; receiving a second login request in the secure server, the second login request comprising client authorization credentials identifying a source of the second login request and permission information describing a permission to perform an action on a node resource, the client authorization credentials provided by the identity provider in response to the redirected login request; receiving a request to perform an action on the node resource; determining if the action is permitted according to the permission information of the client authorization credentials; and if the action is permitted, performing the action on the node resource.
Another embodiment is evidenced by an apparatus having a processor and a communicatively coupled memory storing processor instructions for performing the foregoing operations.
The features, functions, and advantages that have been discussed can be achieved independently in various embodiments of the present invention or may be combined in yet other embodiments, further details of which can be seen with reference to the following description and drawings.
Referring now to the drawings in which like reference numbers represent corresponding parts throughout:
In the following description, reference is made to the accompanying drawings which form a part hereof, and which is shown, by way of illustration, several embodiments. It is understood that other embodiments may be utilized and structural changes may be made without departing from the scope of the present disclosure.
The identity provider 106 comprises an authorization service module 108 that authenticates communications from the client device 104, and interfaces with the policy module 110 to request client authorization credentials and provide such credentials to the client device 104. In this context, client authorization credentials are essentially an authorization token that specifies permissions for resource nodes for a specific user. This is distinct from the notion of login credentials, such as usernames and passwords, which may also be provided to the identity provider 106.
The identity provider 106 implements a hierarchical organization of node resources that is predefined, for example, an administrator of the secure server 102, for example, using an API provided by the identity provider 106 for that purpose. In one embodiment, the policy management module 116 interfaces with the API of the identity provider 106 to define the hierarchical organization and accepts, interprets, and configures such input into a form suitable for the API of the identity provider 106.
In the hierarchical organization of node resources, each node resource has one or more scopes and one or more attributes. Further, each one or more scope is associated with a scope permission, and each node resource is either a management node resource for maintaining the hierarchical organization of the node resources or a configuration node resource for performing the action.
Users with the admin scope permission of a resource node can modify any scope permissions for that resource for other users. For example, a user with admin scope permission can assign other administrators, manager, and users to a resource node.
Users with the manage scope permission of a resource node can modify use scope permissions for that resource for other users. For example, a user having a manage scope permission for a resource node can assign users to that resource node (e.g. a configuration node).
Users with the view scope permission of a resource node can view information defined for that resource. For example, if the resource is a configuration node for signing data, such details could include information regarding which signing keys and parameters are used in the signing operations, and a user with a view scope permission can view those details with regard to that configuration node.
Users with the edit scope permission of a resource node can edit the attributes associated with that resource. For example, for a configuration resource that is used to sign data, a user with an edit scope permission can change the data signing parameters.
Users with the use scope permission of a resource node can use any configurations under that resource node, for an example, to perform an action on the resource associated with that resource node. Other scopes may also be defined in addition to those described above.
With regard to attributes, the parent attribute points to the parent resource node (the node immediately superior to the node having the parent attribute). A null parent attribute indicates that the node is superior to all other resource nodes in the hierarchical organization of resource nodes (e.g. it has no parent). The permission inheritance attribute specifies whether permissions associated with that node extend to any child nodes. The permission inheritance can extend to any descendant nodes if all nodes in the chain have permission inheritance attribute turned on.
The hierarchically topmost node is management resource node 402N for Company X. User A 402U, who is a system administrator, is given admin scope permission of this management node 402N. This means that user A has admin permission and can perform all admin actions on all resource nodes under resource node 402N (e.g. Nodes 404-412N).
Management resource node 404N is a child resource node of management resource node 402N and is hierarchically subordinate to management resource node 402N. This management resource node 404N is associated with an organization (Org Y) within Company X. User B 404U, who is an organization manager, is given manage scope permission of this management resource node 404N, and hence can manage the use permission of the users of all resource nodes under resource node 404N (e.g. resource nodes 406N-412N). In this example, if a use permission for a user is assigned to management resource node 404N, 406N or 408N, that user will have use access to configuration node (ConfigNode) 410N and ConfigNode 412N, as configuration nodes 410N and 412N are hierarchical subordinates (children, grandchildren, or great grandchildren) of management resource nodes 408N, 406N, or 404N, respectively. Also note that management resource node 405N (associated with Project W under Organization Y of Company X) is a child of management resource node 404N, and a parent of configuration node 411N. Hence, user B 404U is given manage scope permission of management resource node 405N and configuration node 411N, and can assign users to configuration node 411N. However, since management resource nodes 406N and 408N are not hierarchically superior to management resource node 405N, users C 406U1, D 406U2, and E 408U are not given manage scope permission of management resource node 405N or configuration node 411N.
Management resource node 406N is a child resource node of management resource node 404N and a grandchild of management resource node 402N and is hierarchically subordinate to both management resource node 402N and management resource node 404N. This management resource node 406N is associated with a project (Project Z) within Org Y and Company X. User C 406U1, who is a project manager, is given manage scope permission of this management resource node 404N, and user D 406U2, who is a user, is given user scope permission of management resource node 406N. This means that user D can use any of the configuration resource nodes under management resource node 406N (e.g. configuration nodes 410N and 412N). User C 406U1 can manage the use permission of users for all resource nodes that are children of management resource node 406N.
Management resource node 408N is a child resource node of management resource node 406N and is hierarchically subordinate to management resource nodes 402N-406N. This management resource node 408N is associated with a model (Model M, for example, a model of a device with boot code) within Project Z of Organization Y in Company X. User E 408U, who is a user, is given user scope permission of this management resource node 408N. This means that user E 408U can use any of the configuration resource nodes under management resource node 408N.
JTAG (Joint Test Action Group) is a common hardware interface that is used as the primary means of accessing sub-blocks of integrated circuits, making it an essential mechanism for debugging embedded systems which might not have any other debug-capable communications channel. The JTAG enabling token may include a protected unique secret JTAG key associated with the target device. A single JTAG token can be utilized to unlock JTAG interface of only one specific device.
Users 402U-416U can be human users (accessing the system using a graphical user interface (GUI) or a machine user. Machine users may include a high security machine to machine (M2M) client having a hardware credential such as a universal serial bus (USB) crypto token with login credentials. Alternatively, M2M client may be configured with a software credential such as a software key or digital certificate. One example of a M2M client with a software credential is an application with cloud-based client access via a Representational State Transfer (REST) API. Other user types can also be added.
Returning to
In block 218, the client device 104 receives the client authorization credentials, as shown in block 218. Now continuing in
In block 234, the secure server determines if the action is permitted. This is determined according to the permission information of the client authorization credentials provided in block 220. For example, if the client authorization credentials identify a particular user that wants to perform an action associated with a particular resource node, that action is permitted only if the client authorization credentials offered to the secure server 102 (which were generated by the identity provider 106 based on input defining the hierarchical organization of resource nodes, their scopes, and attributes) permit such an action. If the action is permitted, the action on the resource node(s) is performed and any results are provided back to the client 104, as shown in block 236. For example, if the requested action is a data signing operation using a particular configuration represented by a configuration resource node, the indicated signing operation is performed and the signature returned to the client device 104. If the action is not permitted, the secure server 102 may transmit a message to the client device 104 indicating that the action is not permitted. Continuing on
It is noted that it is possible for an administrator of the identity provider 106 to manage permissions, for example, by logging into the identity provider 106 to manage permissions directly, perhaps at the request of the administrator of the secure server 102 or the user of the client device 104. However, since the administrator of the identity provider 106 can change permissions for all users, more fine grained permission control is not achieved.
Instead, permissions may be managed via the secure server 102. In this instance, a user with administrative privileges logs into the secure server 102 and requests changes to the hierarchical network of resource nodes, for example, changing permissions associated with those nodes, adding, or removing users. The PEP 112 of the secure server 102 checks the ID token and access token to determine if the user's permissions permit the changes, and if so, causes the policy management module 116 to change the hierarchical network of resource nodes, scopes, attributes, and permissions to make the requested changes via the policy module 110 of the identity provider 106. This can be accomplished via an API of the identity provider 106 that is presented for this purpose. This permits finer grained permission control, because the permissions of the administrator of the secure server themselves are limited.
Sample Use Cases
For example, consider a case where a first user tries to grant permission for second user to use a resource node. The first user presents their access token to the secure server 102 which define that first user's permissions. The secure server 102 checks that access token to determine if the first user has permission to “manage scope” of that resource node or any of its superior (ancestor) nodes (e.g. parent nodes, grandparent nodes). If so, the first user's request to update permissions to provide the second user permission to use that resource node is granted using the policy management module 116 and policy module 110 on behalf of the first user. It should be noted that until new client authorization credentials are generated and provided to the second user, the second user will be unable to perform the permitted use of the resource node. Such new or updated client authorization credentials may be pushed to the client device 104 of the second user, or may be provided in response to a request by the client device 104 of the second user to use the node resource.
In another example, a first user attempts to perform an action on a configuration resource node. The first user presents their access token to the secure server 102 which define that first user's permissions. The secure server 102 checks that access token to determine if the first user has permission to use the configuration resource node or any of its superior (ancestor) nodes (e.g. parent nodes, grandparent nodes). If so, the requested action is performed without any interaction with the identity provider 106. If not, the requested action is denied. A user having admin scope permissions may request that the first user be given permission to use that configuration resource node by using the policy management module 116 and policy module 110 to modify the hierarchical organization of resource nodes, scopes, attributes, and permissions, and after the first user receives a new access token permitting the requested use of the configuration resource node, the first user will be able to perform the action.
In yet another example, a first user attempts to add a resource node. The first user presents their access token to the secure server 102 which define that first user's permissions. The secure server 102 checks that access token to determine if the first user has permission to “admin scope” of that resource node or any of its superior (ancestor) nodes (e.g. parent nodes, grandparent nodes). If so, the first user's request to the hierarchical organization of resource nodes to add the resource node and update any required permissions.
Generally, the computer 502 operates under control of an operating system 508 stored in the memory 506, and interfaces with the user to accept inputs and commands and to present results through a graphical user interface (GUI) module 518A. Although the GUI module 518B is depicted as a separate module, the instructions performing the GUI functions can be resident or distributed in the operating system 508, the computer program 510, or implemented with special purpose memory and processors. The computer 502 also implements a compiler 512 which allows an application program 510 written in a programming language such as COBOL, C++, FORTRAN, or other language to be translated into processor 504 readable code. After completion, the application 510 accesses and manipulates data stored in the memory 506 of the computer 502 using the relationships and logic that was generated using the compiler 512. The computer 502 also optionally comprises an external communication device such as a modem, satellite link, Ethernet card, or other device for communicating with other computers.
In one embodiment, instructions implementing the operating system 508, the computer program 510, and the compiler 512 are tangibly embodied in a computer-readable medium, e.g., data storage device 520, which could include one or more fixed or removable data storage devices, such as a zip drive, floppy disc drive 524, hard drive, CD-ROM drive, tape drive, etc. Further, the operating system 508 and the computer program 510 are comprised of instructions which, when read and executed by the computer 502, causes the computer 502 to perform the operations herein described. Computer program 510 and/or operating instructions may also be tangibly embodied in memory 506 and/or data communications devices 530, thereby making a computer program product or article of manufacture. As such, the terms “article of manufacture,” “program storage device” and “computer program product” as used herein are intended to encompass a computer program accessible from any computer readable device or media.
Those skilled in the art will recognize many modifications may be made to this configuration without departing from the scope of the present disclosure. For example, those skilled in the art will recognize that any combination of the above components, or any number of different components, peripherals, and other devices, may be used.
This concludes the description of the preferred embodiments of the present disclosure. The foregoing discloses a system and method for performing an action on at least one resource node of a hierarchical organization of resource nodes.
In one embodiment the method comprises: receiving a login request in secure server; redirecting the login request to an identity provider, the identity provider defining a hierarchical organization of node resources, each node resource having one or more scopes and one or more attributes, each one or more scope associated with a scope permission, wherein each node resource is either a management node resource for maintaining the hierarchical organization of the node resources or a configuration node resource for performing the action; receiving a second login request in the secure server, the second login request comprising client authorization credentials identifying a source of the second login request and permission information describing a permission to perform an action on a node resource, the client authorization credentials provided by the identity provider in response to the redirected login request; receiving a request to perform an action on the node resource; determining if the action is permitted according to the permission information of the client authorization credentials; and if the action is permitted, performing the action on the node resource.
Implementations may include one or more of the following features:
Any of the above methods, wherein the one or more scopes of the node resources each include: an admin scope having an admin scope permission permitting a user to modify any scope permission of a node resource associated with the admin scope; a manage scope having a manage scope permission permitting the user to modify a use scope permission of the node resource associated with the manage scope; the one or more scopes of the configuration node resource further include: a use scope having the use scope permission permitting the user to use any configuration of the configuration node resource associated with the use scope.
Any of the above methods, wherein the one or more scopes of the node resources each further include: an edit scope having an edit scope permission permitting the user to edit attributes of the node resource associated with the edit scope; and a view scope having a view scope permission permitting the user to view information defined for node resource associated with the view scope.
Any of the above methods, further including: determining, in the secure server, if the client authorization credentials are valid; and receiving the request in the secure server to perform the action on the resource node only if the client authorization credentials are valid, otherwise denying the request.
Any of the above methods, further including, if the action is not permitted: accepting, from an administrator of the secure server, a request to change the permission of the node resource to permit the action; determining if the requested change of permission is authorized; and if the requested change of permission is authorized, transmitting a request to change the permission of the node resource to the identity provider to permit the action.
Any of the above methods, further including: receiving a third login request in the secure server, the third login request including further client authorization credentials identifying the source of the third login request and updated permission information describing permission to perform the action on the resource node according to the request to change the permission of the node resource.
Any of the above methods, further including: accepting, from an administrator of the secure server, a request to change the permission of the node resource; determining if the requested change of permission is authorized; and if the requested change of permission is authorized, transmitting a request to change the permission of the node resource to the identity provider.
Any of the above methods, further including: receiving a third login request in the secure server, the third login request including further client authorization credentials identifying the source of the third login request and updated permission information describing permission to perform a second action on the resource node according to the request to change the permission of the node resource.
Any of the above methods, wherein the one or more attributes include: a parent attribute specifying a parent node; and a permission inheritance attribute specifying whether a scope permission of the node resource extends to subordinate node resources.
Any of the above methods, wherein the client authorization credentials include: an identifier (id) token identifying the source of the second login request; and an access token having permission information, the permission information describing permission to perform an action on the node resource.
Any of the above methods, wherein the secure server is a data signing server and the action is signing the data.
Another embodiment is evidenced by a system for performing an action on at least one resource node of a hierarchical organization of resource nodes, including: a processor; a memory, communicatively coupled to the processor, the memory storing processor instructions including processor instructions for: receiving a login request in secure server; redirecting the login request to an identity provider, the identity provider defining a hierarchical organization of node resources, each node resource having one or more scopes and one or more attributes, each one or more scope associated with a scope permission, wherein each node resource is either a management node resource for maintaining the hierarchical organization of the node resources or a configuration node resource for performing the action; receiving a second login request in the secure server, the second login request including: client authorization credentials identifying a source of the second login request and permission information describing a permission to perform an action on a node resource, the client authorization credentials provided by the identity provider in response to the redirected login request. The processor instructions also includes processor instructions for receiving a request to perform an action on the node resource, for determining if the action is permitted according to the permission information of the client authorization credentials, and if the action is permitted, performing the action on the node resource.
Implementations may include one or more of the following features:
Any system described above, wherein: the one or more scopes of the node resources each include: an admin scope having an admin scope permission permitting a user to modify any scope permission of a node resource associated with the admin scope; a manage scope having a manage scope permission permitting the user to modify a use scope permission of the node resource associated with the manage scope; and the one or more scopes of the configuration node resource further include: a use scope having the use scope permission permitting the user to use any configuration of the configuration node resource associated with the use scope.
Any system described above, wherein the one or more scopes of the node resources each further include: an edit scope having an edit scope permission permitting the user to edit attributes of the node resource associated with the edit scope; and a view scope having a view scope permission permitting the user to view information defined for node resource associated with the view scope.
Any system described above, wherein the processor instructions further include processor instructions for: determining, in the secure server, if the client authorization credentials are valid; and receiving the request in the secure server to perform the action on the resource node only if the client authorization credentials are valid, otherwise denying the request.
Any system described above, wherein the processor instructions further include processor instructions for: accepting, from an administrator of the secure server, a request to change the permission of the node resource to permit the action; determining if the requested change of permission is authorized; and if the requested change of permission is authorized, transmitting a request to change the permission of the node resource to the identity provider to permit the action.
Any system described above, wherein the processor instructions further include: receiving a third login request in the secure server, the third login request including further client authorization credentials identifying the source of the third login request and updated permission information describing permission to perform the action on the resource node according to the request to change the permission of the node resource.
Any system described above, wherein the one or more attributes include: a parent attribute specifying a parent node; and a permission inheritance attribute specifying whether a scope permission of the node resource extends to subordinate node resources.
The foregoing description of the preferred embodiment has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. Many modifications and variations are possible in light of the above teaching. It is intended that the scope of rights be limited not by this detailed description, but rather by the claims appended hereto.
| Number | Date | Country | |
|---|---|---|---|
| 63234953 | Aug 2021 | US |
