Maintaining confidentiality across multiple decentralized policies (Method, system, and computer program for maintaining confidentiality of metadata across multiple decentralized policies)
By encrypting token metadata using homomorphic encryption and JWT, the solution addresses the trust issues in decentralized policy management, ensuring confidentiality and compliance by securing sensitive metadata across multiple policies.
Patent Information
- Application Number
- JP2022053661
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2021-03-30
- Filing Date
- 2022-03-29
- Publication Date
- 2025-10-30
- Estimated Expiration
- 2042-03-29
AI Technical Summary
In decentralized policy management configurations, there is a lack of trust in control planes managed by third-party companies, leading to potential unauthorized access and exposure of sensitive policy holder metadata, which needs to be addressed to ensure confidentiality and compliance.
Implementing encryption techniques, such as homomorphic encryption, to generate and encrypt token metadata, ensuring only trusted parties can access and evaluate policy decisions, maintaining confidentiality through methods like JSON Web Tokens (JWT) to secure metadata across multiple decentralized policies.
Ensures the confidentiality and anonymity of policy holders' metadata, protecting sensitive information and adhering to compliance requirements by encrypting and securely managing metadata within decentralized systems.
Smart Images

Figure 0007762473000001 
Figure 0007762473000002 
Figure 0007762473000003
Abstract
Description
[Technical Field]
[0001] The present disclosure relates generally to the field of decentralized policies, and more particularly to methods and techniques for maintaining privacy and ensuring confidentiality of information of users associated with multiple decentralized policies. [Background technology]
[0002] Data privacy has become a growing concern over the last decade because technological advances in data mining have made it possible to collect large amounts of personal data. In many cases, with multiple decentralized policies, data that is irrelevant to performing a particular policy function (e.g., the identity of the policy holder) may be shared with actors that do not have the same level of trust as the policy issuer. Summary of the Invention [Problem to be solved by the invention]
[0003] Therefore, methods and techniques are desirable to ensure that an individual's private information remains confidential. [Means for solving the problem]
[0004] Embodiments of the present disclosure include methods, computer program products, and systems for maintaining metadata confidentiality across multiple decentralized policies. A processor may generate one or more encryption policies associated with a policy creator. The processor may generate token metadata associated with a user utilizing the one or more encryption policies. The processor may encrypt the token metadata to form encrypted token metadata. The processor may send the one or more encryption policies and the encrypted token metadata to a policy evaluator. The policy evaluator may evaluate the one or more encryption policies and the encrypted token metadata. The processor may return a response. The response may be based on the evaluation by the policy evaluator.
[0005] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure. [Brief explanation of the drawings]
[0006] The drawings included in this disclosure are incorporated in and constitute a part of this specification. They illustrate embodiments of the disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of particular embodiments and are not intended to limit the disclosure.
[0007] [Figure 1] FIG. 1 is a block diagram of a system for maintaining metadata confidentiality across multiple decentralized policies according to an embodiment of the present disclosure.
[0008] [Figure 2] 1 is a flowchart of a method for maintaining metadata confidentiality across multiple decentralized policies, according to an embodiment of the present disclosure.
[0009] [Figure 3A] FIG. 1 illustrates a cloud computing environment according to an embodiment of the present disclosure.
[0010] [Figure 3B] FIG. 1 illustrates abstraction model layers according to an embodiment of the present disclosure.
[0011] [Figure 4] FIG. 1 is a high-level block diagram of an exemplary computer system that may be used to implement one or more of the methods, tools, and modules described herein, and any associated functionality, according to an embodiment of the present disclosure.
[0012] While the embodiments described herein are susceptible to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the particular embodiments described are not to be construed in a limiting sense. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION
[0013] The present disclosure relates generally to the field of decentralized policies, and more particularly to methods and techniques for maintaining privacy and ensuring confidentiality of information of users associated with multiple decentralized policies. The present disclosure is not necessarily limited to such applications, and various aspects of the present disclosure may be understood through the discussion of various examples using this context.
[0014] In many cases, a control plane or third-party cloud provider may manage policy services for various policy holders in a decentralized policy management configuration. In such a configuration, the control plane managing the services cannot be fully trusted. Typically, the control plane is managed by third-party companies and their employees. These third parties, or anyone with access to the policy service, may be able to view the orchestration components and the metadata of their policies. In many cases, these third parties are not authorized to access this data / information and may lack specific compliance requirements. As a result, there is only a certain level of trust that can be assigned to the control plane. For example, software-as-a-service authorization is usually based on a token that describes a person or service. When a policy holder (e.g., a user or administrator) calls or queries the control plane about a particular policy, the policy holder must provide some private details / data or attributes (e.g., metadata) that describe and verify the policy holder's identity to ensure that they are authorized to access the policy. These private details / data may include, but are not limited to, the policy holder's address, customer identification number, and company or product name.
[0015] Because these private details are not widely known, they can be checked against information listed in the policy to prevent unauthorized parties from accessing data or secrets configured in the policy. Depending on how the policy is structured, the private details / data needed to verify an authorized user / policy holder to access specific information or objects in the policy may be tightly tied to specific identity private details or attributes. In policy-based decision-making, the control plane may be processing various private details or attributes that may be of a sensitive nature (e.g., the policy holder may want to keep confidential). If these private details / attributes are encrypted for the duration that the control plane has access to them (e.g., during the decision-making process), such private details / attributes can remain confidential and secure. This can be particularly beneficial during the authorization process, where private details / attributes are checked against information provided in the policy. For example, the authorization process may be managed by a provider that may lack compliance requirements (e.g., requirements that may be imposed by a government agency such as the National Institute of Standards and Technology) or that may not be authenticated to view the private details / attributes associated with a policy holder's policy queries (e.g., external authentication). Thus, there is a need for methods and techniques that provide policy issuers with the ability to have more granular control over this data to ensure that private details / attributes remain confidential or private.
[0016]
[0003] In the embodiments discussed herein, solutions are provided in the form of methods, systems, and computer program products for maintaining confidentiality of metadata across multiple decentralized policies. The embodiments contemplated herein maintain confidentiality of policyholder metadata (e.g., private details / attributes) across multiple decentralized policies. Maintaining confidentiality of policyholders can ensure the anonymity of the policyholders' customers and protect subscription details associated with the policyholders or their customers, or any other information that may be associated with a particular policy.
[0017] In an embodiment, the processor may be configured to generate one or more encrypted policies (e.g., policies encrypted using homomorphic encryption) associated with a policy creator. A policy creator may include any person or entity (e.g., a policy issuer) that configures or defines policies. In an embodiment, a policy creator may have access to one or more policies and associated metadata (e.g., private details / attributes) associated with a policy holder (e.g., a user, an administrator, an application / application software, etc.). In an embodiment, a policy creator is considered to be a fully trusted party within a decentralized policy management configuration.
[0018] In an embodiment, a processor may generate token metadata for metadata associated with a user / application utilizing one or more encryption policies. By tokenizing the metadata, private details / attributes found within the metadata may be converted into a random string (e.g., a token). While this random string may reference the original data, the random string often cannot be reverse engineered.
[0019] In embodiments, the processor may encrypt the token metadata to form encrypted token metadata. Encrypting the token metadata may prevent any third party or unauthorized person / process from reading the metadata. While any type of encryption process may be used, in some embodiments, homomorphic encryption may be used to encrypt the token metadata. In some embodiments, the processor may compose the encrypted token metadata into a JSON Web Token (JWT token). A JWT token is a way of encapsulating information that is often easily readable but cannot be tampered with. A JWT token typically includes public key information and a payload. For example, if the token's payload is altered, it will not match the signature.
[0020] In some embodiments, the processor may send one or more encryption policies and encrypted token metadata directly to the policy evaluator, while in other embodiments, a resource server (e.g., a server serving a specific purpose) may pass one or more encryption policies and encrypted token metadata to the policy evaluator. A resource server may be configured to manage one or more different resources, including but not limited to storage, CPU, memory, containers, networking, or any combination thereof. In some embodiments, to provision a resource in an optimal manner, the service may need to request some additional information about the application of this resource. This information may include certain metadata that must be encrypted.
[0021] In embodiments, a policy evaluator (e.g., an engine) may determine policy actions associated with one or more encryption policies. The policy evaluator may be any party in a decentralized policy management configuration that lacks full trust (e.g., lacks a confidentiality certificate). In some embodiments, the policy evaluator and other parties that lack trust may not have access to metadata associated with the user / application. In some embodiments, the policy evaluator may obtain a JWT token. In some embodiments, the policy evaluator may be configured to store one or more encryption policies generated by a policy creator.
[0022] In embodiments, the policy evaluator may evaluate one or more encryption policies and encrypted token metadata. In some embodiments, the policy evaluator may determine an evaluation result. In these embodiments, the evaluation result may be based on the policy evaluator's evaluation of the one or more encryption policies and encrypted token metadata. In these embodiments, the policy evaluator may perform a decision based on the evaluation result.
[0023] In embodiments, in response to evaluating the one or more encryption policies and encrypted token metadata, a response (which may be as simple as a true / false response, for example) may be generated / returned based on the evaluation result determination. For example, the processor may determine whether resource Y having attributes A, B, C, and D accesses resource X (e.g., the evaluation result) and generate a yes or no response. In these embodiments, the evaluation result may be based, at least in part, on the evaluation of the one or more encryption policies and encrypted token metadata by the policy evaluator. In embodiments, the policy evaluator may make a decision based, at least in part, on the evaluation result. In these embodiments, the processor may forward the evaluation result to a resource server. In these embodiments, the resource server may generate a response and return the response to the user / application.
[0024] In one example embodiment, medical application software (e.g., an application) may require resources to render a medical simulation, which are provided by a resource server. The configuration of the resource server, or the size of the resources (e.g., CPU, memory, storage, or multiple containers, or a combination thereof), and the duration required to render the simulation (e.g., process data) may depend on the number of test cases for a particular group of patients in a particular county. In this example, regulations in that particular county require all patient data to be processed within a data center in that particular county. In this example, a request to the policy evaluator may include whether a subsequent simulation can be rendered given subsequent patient data, and if so, how many resources are required given a subsequent set of policies. In this example, the response to the above request may be that resources A, B, and C are available for the next two hours.
[0025] Referring now to Figure 1, a block diagram 100 of a system for maintaining metadata confidentiality across multiple decentralized policies is illustrated in accordance with an embodiment of the present disclosure. Figure 1 is intended to provide an illustration of only one implementation and is not intended to suggest any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made by one of ordinary skill in the art without departing from the scope of the present invention as defined by the claims.
[0026] In embodiments, a system (e.g., system 100) for maintaining metadata confidentiality across multiple decentralized policies may include an operating entity, a policy creator 102, an application / user 104, a resource server 106, and a policy evaluator 108. In some embodiments, system 100 may be separated into a bootstrap 110 section and an authorization 112 section, while in other embodiments, some or all of the components contemplated herein may be configured within the bootstrap 110 section, or alternatively, some or all of the components may be configured within the authorization 112 section.
[0027] In embodiments, the bootstrap 110 may include a policy creator 102 that generates one or more encryption policies. The one or more policies may be encrypted using any available encryption (e.g., homomorphic encryption). In these embodiments, the policy creator 102 may generate an encryptor key 118. The encryptor key 118 may consist of any form of key or function that may be utilized in the system 100. In some embodiments, the policy creator 102 may define one or more policies to be encrypted. In these embodiments, the policy creator 102 may be configured to have access to metadata (e.g., user / application private details / attributes) associated with the one or more encryption policies.
[0028] In embodiments, the bootstrap 110 may pass the encryptor key 118 to the key encryptor store 120. In some embodiments, the user / application 104 may be configured to store the encryptor key 118 associated with one or more of the user / application's 104 policies (e.g., parties providing private details / attributes such as identities). In embodiments, one or more encryption policies generated by the policy creator 104 may be stored in the encryption policy store 116. In these embodiments, the encryption policy store 116 may be managed by the policy evaluator 108.
[0029] In embodiments, the system 100 may include an authorization 112 section. In the authorization 112 section, a user / application may generate token metadata, which is metadata associated with one or more encryption policies for the user / application 104. In these embodiments, the metadata may include identity information or any other information that the user / application 104 may desire to be confidential (e.g., private details / attributes). In embodiments, the user / application 104 may encrypt the token metadata using an encryptor to form encrypted token metadata 124. In some embodiments, the user / application may delegate this role to another component (e.g., a Yubikey®) to demonstrate trust of the user / application 104 to that component. For example, the user / application may not be able to perform certain operations due to one or more restrictions. For example, to comply with certain security requirements, hardware encryption that can only be performed on dedicated hardware may be required. For example, a trusted platform module (TPM) or other hardware that can be configured to store encryption keys used for encryption may be used. In some embodiments, a security device such as a hardware security module may be added to manage, generate, and securely store cryptographic keys.
[0030] In embodiments, the user / application 104 may pass the encrypted token metadata 124 to the resource server 106. The resource server 106 may be any server associated with a particular purpose. In embodiments, the resource server 106 may pass the encrypted token metadata 124 to the policy evaluator 108 (e.g., may forward the token to the policy evaluator 126). In some embodiments, the policy evaluator 108 may obtain the encrypted token metadata 124 using the JWT token (e.g., may obtain the JWT token 128 using the encrypted metadata). In embodiments, the policy evaluator 108 may evaluate the encrypted token metadata against an encryption policy stored in the encryption policy store 116 (e.g., may evaluate the encrypted metadata using the encryption policy 130) and generate an evaluation result. In embodiments, the policy evaluator 108 may perform / decide a policy decision based at least in part on the evaluation result (e.g., may perform a decision based on the evaluation result 132). In embodiments, policy evaluator 108 may forward its decision to resource server 106. In these embodiments, resource server 106 may determine a response. In these embodiments, after a response is determined by resource server 106, the resource server may return a response to user / application 105 based on the policy (e.g., may return a response based on the policy).
[0031] 2, a flowchart illustrating an example method 200 for maintaining metadata confidentiality across multiple decentralized policies is shown in accordance with an embodiment of the present disclosure. In some embodiments, method 200 begins with operation 202, in which a processor generates one or more encryption policies associated with a policy creator. In some embodiments, operation 202 may be a process included in a bootstrap process, such as bootstrap process 110 in FIG. 1.
[0032] In some embodiments, method 200 proceeds to operation 204. At operation 204, a processor may generate token metadata associated with the user utilizing one or more encryption policies. In some embodiments, method 200 proceeds to operation 206. At operation 206, the processor encrypts the token metadata to form encrypted token metadata.
[0033] In some embodiments, method 200 proceeds to operation 208. At operation 208, the processor may send one or more encryption policies and encrypted token metadata to a policy evaluator. In some embodiments, the one or more encryption policies and encrypted token metadata are sent to the policy evaluator simultaneously, while in other embodiments, the one or more encryption policies and encrypted token metadata are sent to the policy evaluator at different times. In embodiments, the policy evaluator may evaluate the one or more encryption policies and encrypted token metadata.
[0034] In some embodiments, method 200 proceeds to operation 210. In operation 210, the processor may return a response. In embodiments, the response is based on an evaluation by the policy evaluator. In some embodiments, method 200 may end after operation 210, as shown in FIG. 2. In embodiments, operations 204-210 may be processes included in an authorization process, such as authorization process 112 in FIG. 1.
[0035] As discussed in more detail herein, it is contemplated that some or all of the operations of method 200 may be performed in an alternative order or not at all, and further, multiple operations may occur simultaneously or as part of a larger process.
[0036] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present disclosure can be implemented in conjunction with any other type of computing environment now known or later developed.
[0037] Cloud computing is a model of service delivery that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.
[0038] The characteristics are as follows:
[0039] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time and network storage, automatically as needed, without requiring human interaction with the service provider.
[0040] Wide network access: The capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (eg, cell phones, laptops, and PDAs).
[0041] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge over the exact portion of the resources provided, but there is some independence of portions in that it may be possible to specify portions at a higher level of abstraction (e.g., country, state, or data center).
[0042] Rapid Elasticity: This capacity can be rapidly and elastically provisioned, sometimes automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capacity available for provisioning often appears unlimited, and can be purchased in any quantity at any time.
[0043] Measured Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services utilized.
[0044] The service model is as follows:
[0045] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
[0046] Platform as a Service (PaaS): The ability offered to consumers is to deploy applications they create or acquire, written using programming languages and tools supported by the provider, on a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but does control the deployed applications and, in some cases, the application hosting environment configuration.
[0047] Infrastructure as a Service (IaaS): The ability offered to consumers is to provision processing, storage, network, and other basic computing resources, on which they can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but does control the operating systems, storage, deployed applications, and possibly limited control over selected networking components (e.g., host firewalls).
[0048] The deployment model is as follows:
[0049] Private Cloud: Cloud infrastructure operates solely for an organization. This cloud infrastructure may be managed by that organization or a third party and may exist on-premise or off-premise.
[0050] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with shared interests (e.g., mission, security requirements, policies and compliance considerations). The community cloud may be managed by those organizations or a third party and may exist on-premises or off-premises.
[0051] Public Cloud: Cloud infrastructure is made available to the general public or large industry organizations and is owned by an organization that sells cloud services.
[0052] Hybrid Cloud: A cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain distinct entities but are bound together by standard or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).
[0053] Cloud computing environments are service-oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.
[0054] 3A , an exemplary cloud computing environment 310 is shown. As shown, the cloud computing environment 310 includes one or more cloud computing nodes 300 with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or cellular phone 300A, a desktop computer 300B, a laptop computer 300C, or an automobile computer system 300N, or combinations thereof, may communicate. The nodes 300 may communicate with each other. The nodes may be physically or virtually grouped (not shown) in one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described above. This enables the cloud computing environment 310 to provide infrastructure, a platform, or software, or combinations thereof, as a service without the cloud consumer having to maintain resources on their local computing device. It will be understood that the types of computing devices 300A-N shown in FIG. 3A are intended to be illustrative only, and that computing node 300 and cloud computing environment 310 can communicate with any type of computerized device via any type of network or network-addressable connection, or both (e.g., using a web browser).
[0055] Referring now to Figure 3B, a set of functional abstraction layers provided by the cloud computing environment 310 (Figure 3A) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 3B are intended to be illustrative only, and embodiments of the present disclosure are not limited thereto. The following layers and corresponding functions are provided as follows:
[0056] Hardware and software layer 313 includes hardware and software components. Examples of hardware components include mainframe 302, RISC (reduced instruction set computer) architecture-based server 304, server 306, blade server 308, storage device 311, and network and networking components 312. In some embodiments, software components include network application server software 314 and database software 316.
[0057] The virtualization layer 320 provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers 322, virtual storage 324, virtual networks including virtual private networks 326, virtual applications and operating systems 328, and virtual clients 330.
[0058] In one example, management layer 340 may provide the functions described below. Resource provisioning 342 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 344 provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection of data and other resources. User portal 346 provides access to the cloud computing environment for consumers and system administrators. Service level management 348 provides allocation and management of cloud computing resources to ensure required service levels are met. Service level agreement (SLA) planning and fulfillment 350 provides pre-configuration and procurement of cloud computing resources to anticipate future requirements according to SLAs.
[0059] Workload tier 360 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include mapping and navigation 362, software development and lifecycle management 364, virtual classroom instructional delivery 366, data analytics processing 368, transaction processing 370, and maintaining metadata confidentiality across multiple decentralized policies 372.
[0060] 4 illustrates a high-level block diagram of an exemplary computer system 401 that may be used to implement one or more of the methods, tools, and modules described herein (e.g., using one or more processor circuits of a computer or computer processor), and any associated functionality, according to embodiments of the present invention. In some embodiments, major components of computer system 401 may include one or more processors 402, a memory subsystem 404, a terminal interface 412, a storage interface 416, an I / O (input / output) device interface 414, and a network interface 418, all of which may be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 403, an I / O bus 408, and an I / O bus interface unit 410.
[0061] Computer system 401 may include one or more general-purpose programmable central processing units (CPUs) 402A, 402B, 402C, and 402D, collectively referred to herein as CPUs 402. In some embodiments, computer system 401 may include multiple processors, as is typical for relatively large systems. However, in other embodiments, computer system 401 may alternatively be a single-CPU system. Each CPU 402 may execute instructions stored in memory subsystem 404 and may include one or more levels of on-board cache.
[0062] The system memory 404 may include computer system-readable media in the form of volatile memory, such as random access memory (RAM) 422 or cache memory 424. The computer system 401 may further include other removable / non-removable volatile / non-volatile computer system storage media. By way of example only, the storage system 426 may be provided to read from and write to a non-removable, non-volatile magnetic medium, such as a “hard drive.” Although not shown, a magnetic disk drive may be provided to read from or write to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), or an optical disk drive may be provided to read from and write to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical medium. Additionally, the memory 404 may include flash memory, such as a flash memory stick drive or flash drive. Memory devices may be connected to the memory bus 403 by one or more data medium interfaces. The memory 404 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of various embodiments.
[0063] One or more programs / utilities 428, each having at least one set of program modules 430, may be stored in memory 404. The programs / utilities 428 may include a hypervisor (also referred to as a virtual machine monitor), one or more operating systems, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may include an implementation of a networking environment. The programs 428 and / or program modules 430 generally perform the functions or methodologies of the various embodiments.
[0064] 4 as a single bus structure providing a direct communication path between CPU 402, memory subsystem 404, and I / O bus interface 410, memory bus 403, in some embodiments, may include multiple different buses or communication paths that may be configured in any of a variety of forms, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Additionally, while I / O bus interface 410 and I / O bus 408 are shown as single respective units, computer system 401, in some embodiments, may include multiple I / O bus interface units 410, multiple I / O buses 408, or both. Additionally, while multiple I / O interface units are shown isolating I / O bus 408 from the various communication paths extending to the various I / O devices, in other embodiments, some or all of the I / O devices may be directly connected to one or more system I / O buses.
[0065] In some embodiments, computer system 401 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 401 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a network switch or router, or any other suitable type of electronic device.
[0066] It should be noted that Figure 4 is intended to illustrate representative major components of an exemplary computer system 401. However, in some embodiments, individual components may be of greater or less complexity than depicted in Figure 4, components other than or in addition to those depicted in Figure 4 may be present, and the number, type, and configuration of such components may vary.
[0067] As discussed in more detail herein, it is contemplated that some or all of the operations of some of the method embodiments described herein may be performed in an alternative order or not at all, and further, multiple operations may occur simultaneously or as part of a larger process.
[0068] The present invention may be a system, method, or computer program product, or combination thereof, at any possible level of technical detail of integration. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform aspects of the present invention.
[0069] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves that record instructions, and any suitable combination of the foregoing. Computer-readable storage medium, as used herein, should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted through a wire.
[0070] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in each computing / processing device for storage.
[0071] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk®, C++, etc., and procedural programming languages such as the “C” programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer readable program instructions to personalize the electronic circuitry by utilizing state information of the computer readable program instructions to perform aspects of the present invention.
[0072] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.
[0073] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to produce a machine, whereby the instructions, executed by the computer processor or other programmable data processing apparatus, create means for implementing the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or both. These computer-readable program instructions may also be stored on a computer-readable storage medium, whereby the instructions can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium having the instructions stored thereon comprises an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts or block diagrams, or combination thereof.
[0074] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device implement the functions / operations specified in one or more blocks of the flowcharts or block diagrams, or a combination thereof.
[0075] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions, that implement the specified logical function(s). In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be implemented as a single step, or may be executed concurrently, substantially concurrently, partially, or fully overlapping in time, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware and computer instructions.
[0076] The description of various embodiments of the present invention has been presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used in this specification has been selected so as to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.
[0077] While the present invention has been described with respect to specific embodiments, it is anticipated that variations and modifications thereto will become apparent to those skilled in the art. It is therefore intended that the following claims be interpreted to cover all such variations and modifications as fall within the true spirit and scope of the present disclosure.
Claims
1. 1. A method for maintaining confidentiality of metadata across multiple decentralized policies, comprising: generating, via a processor, one or more encryption policies associated with a policy creator; generating token metadata associated with a user utilizing the one or more encryption policies; encrypting the token metadata to form encrypted token metadata; sending the one or more encryption policies and the encrypted token metadata to a policy evaluator, wherein the policy evaluator evaluates the one or more encryption policies and the encrypted token metadata; returning a response, the response being based on the evaluation by the policy evaluator; A method comprising:
2. 2. The method of claim 1, wherein encrypting token metadata to form the encrypted token metadata further comprises: configuring the encrypted token metadata into a JSON Web Token (JWT token).
3. The method of claim 2 , further comprising the policy evaluator obtaining the JWT token.
4. The policy evaluator evaluating the one or more encryption policies and the encrypted token metadata includes: determining an evaluation result, the evaluation result being based on the evaluation of the one or more encryption policies and the encrypted token metadata by the policy evaluator; performing a determination based on the evaluation results; 4. The method according to claim 1, wherein the
5. The method of claim 1 , wherein the policy evaluator stores the one or more encryption policies.
6. 6. The method of claim 1, wherein transmitting the one or more encryption policies and the encrypted token metadata to the policy evaluator comprises a resource server passing the one or more encryption policies and the encrypted token metadata to the policy evaluator.
7. determining an evaluation result, the evaluation result being based on the evaluation of the one or more encryption policies and the encrypted token metadata by the policy evaluator; performing a determination based on the evaluation result, wherein the policy evaluator performs the determination; transferring the evaluation result to the resource server; generating the response via the resource server, the response being returned by the resource server to the user; The method of claim 6 further comprising:
8. 1. A system for maintaining metadata confidentiality across multiple decentralized policies, comprising: Memory and a processor in communication with the memory; wherein the processor: generating, via a processor, one or more encryption policies associated with a policy creator; generating token metadata associated with a user utilizing the one or more encryption policies; encrypting the token metadata to form encrypted token metadata; an act of transmitting the one or more encryption policies and the encrypted token metadata to a policy evaluator, the policy evaluator evaluating the one or more encryption policies and the encrypted token metadata; an action that returns a response, the response being based on the evaluation by the policy evaluator; 12. A system configured to perform operations comprising:
9. 10. The system of claim 8, wherein the act of encrypting token metadata to form the encrypted token metadata further comprises an act of configuring the encrypted token metadata into a JSON Web Token (JWT token).
10. The system of claim 9 , further comprising an operation of the policy evaluator obtaining the JWT token.
11. The policy evaluator evaluating the one or more encryption policies and the encrypted token metadata includes: determining an evaluation result, the evaluation result being based on the evaluation of the one or more encryption policies and the encrypted token metadata by the policy evaluator; performing a determination based on the evaluation result; 11. The system according to claim 8, wherein:
12. The system of claim 8 , wherein the policy evaluator stores the one or more encryption policies.
13. 13. The system of claim 8, wherein the act of sending the one or more encryption policies and the encrypted token metadata to the policy evaluator comprises an act of a resource server passing the one or more encryption policies and the encrypted token metadata to the policy evaluator.
14. determining an evaluation result, the evaluation result being based on the evaluation of the one or more encryption policies and the encrypted token metadata by the policy evaluator; an operation of making a determination based on the evaluation result, the policy evaluator making the determination; and transferring the evaluation result to the resource server; generating the response via the resource server, the response being returned by the resource server to the user; The system of claim 13 further comprising:
15. 1. A computer program for maintaining confidentiality of metadata across multiple decentralized policies, the computer program comprising: generating one or more encryption policies associated with the policy creator; generating token metadata associated with a user utilizing the one or more encryption policies; encrypting the token metadata to form encrypted token metadata; sending the one or more encryption policies and the encrypted token metadata to a policy evaluator, wherein the policy evaluator evaluates the one or more encryption policies and the encrypted token metadata; returning a response, the response being based on the evaluation by the policy evaluator; A computer program for executing
16. 16. The computer program product of claim 15, wherein encrypting token metadata to form the encrypted token metadata further comprises: configuring the encrypted token metadata into a JSON Web Token (JWT token).
17. 17. The computer program product of claim 16, further causing the processor to perform the procedure of: the policy evaluator obtaining the JWT token.
18. The policy evaluator evaluating the one or more encryption policies and the encrypted token metadata includes: determining an evaluation result, the evaluation result being based on the evaluation of the one or more encryption policies and the encrypted token metadata by the policy evaluator; a step of making a judgment based on the evaluation result; 18. A computer program according to any one of claims 15 to 17, comprising:
19. 19. The computer program product of claim 15, wherein the policy evaluator stores the one or more encryption policies.
20. 20. The computer program product of claim 15, wherein transmitting the one or more encryption policies and the encrypted token metadata to the policy evaluator comprises a resource server passing the one or more encryption policies and the encrypted token metadata to the policy evaluator.
Citation Information
Patent Citations
Identity authentication method in cloud computing network
CN104935608A
Session management method and device, computer device and storage medium
CN112187931A
Systems and methods for distributed verification of online identity
WO2020223020A1