Legal claims defining the scope of protection. Each claim is shown in both the original legal language and a plain English translation.
1. A method comprising: receiving a request to access a resource of a computer system storing a first plurality of authorization plugin modules; obtaining, by the computer system, a configuration identifying a second plurality of authorization plugin modules that is a proper subset of the first plurality of authorization plugin modules by accessing a configuration file identifying the second plurality of authorization plugin modules; executing, by the computer system, each of the second plurality of authorization plugin modules to generate a plurality of authorization decisions; obtaining, by the computer system, an authorization policy specifying logic to determine whether to grant the request based on the plurality of authorization decisions by accessing a policy database comprising a plurality of authorization policies; and determining, by the computer system, whether to grant the request using the logic specified in the authorization policy and the plurality of authorization decisions.
An authorization system grants or denies access to protected resources. When a request is made, the system selects a subset of available authorization plugin modules based on a configuration file. Each selected plugin module then makes an individual authorization decision (allow or deny). These decisions are combined using logic defined in an authorization policy retrieved from a policy database. The policy specifies how to evaluate the multiple decisions to arrive at a final decision to grant or deny access to the requested resource.
2. The method of claim 1 , wherein at least one of the second plurality of authorization plugin modules is configured by an external mechanism.
In the authorization system described above, at least one of the authorization plugin modules used to make individual authorization decisions is configured externally. This external configuration can involve settings that control how the module operates, what data sources it uses, or the specific rules it applies when determining authorization. This external configuration allows administrators to customize the behavior of the authorization plugin modules without modifying their code.
3. The method of claim 1 , wherein the authorization policy is defined in extensible access control markup language.
In the authorization system described above, the authorization policy, which determines how to combine the individual authorization decisions from the plugin modules, is defined using Extensible Access Control Markup Language (XACML). XACML is a standard XML-based language for expressing access control policies. Using XACML provides a flexible and standardized way to define complex authorization rules that can incorporate various attributes of the user, the resource, and the environment.
4. The method of claim 1 , wherein the authorization policy implements a Java™ authorization contract for containers.
In the authorization system described above, the authorization policy implements a Java Authorization Contract for Containers (JACC). JACC is a standard set of interfaces and classes that allow Java EE containers (such as application servers) to enforce security policies. This means the authorization system can integrate seamlessly with Java EE applications and leverage standard security mechanisms provided by the container.
5. The method of claim 1 , wherein a first authorization plugin module exchanges information with a second authorization plugin module using a protocol selected by an external mechanism.
In the authorization system described above, the authorization plugin modules can exchange information with each other to coordinate their authorization decisions. The protocol used for this communication is configurable through an external mechanism. This allows different modules to use different protocols as needed (e.g., REST APIs, shared memory, message queues), and allows the system to adapt to different environments and requirements.
6. The method of claim 1 , wherein determining whether to grant the request comprises a cumulative decision of the plurality of authorization decisions.
In the authorization system described above, the final authorization decision (grant or deny access) is made by combining the individual authorization decisions from the plugin modules into a single, cumulative decision. This can involve various methods, such as requiring all modules to approve the request (AND logic), allowing any module to approve the request (OR logic), or using a weighted scoring system to combine the decisions. The cumulative decision is determined by the authorization policy.
7. An apparatus comprising: data storage to store a first plurality of authorization plugin modules; and a server coupled to the data storage to: receive a request to access a resource; obtain a configuration identifying a second plurality of authorization plugin modules that is a proper subset of the first plurality of authorization plugin modules by accessing a configuration file identifying the second plurality of authorization plugin modules; execute each of the second plurality of authorization plugin modules to generate a plurality of authorization decisions; obtain an authorization policy specifying logic to determine whether to grant the request based on the plurality of authorization decisions by accessing a policy database comprising a plurality of authorization policies; and determine whether to grant the request using the logic specified in the authorization policy and the plurality of authorization decisions.
An authorization apparatus controls access to resources. It includes data storage for authorization plugin modules and a server. When a request arrives, the server reads a configuration file to select a subset of the stored plugin modules. Each selected module makes an authorization decision. The server then retrieves an authorization policy from a policy database. This policy contains logic specifying how to combine the individual module decisions. Finally, the server uses the policy logic and the module decisions to determine whether to grant or deny the request.
8. The apparatus of claim 7 , wherein the authorization policy is based on a set of rules.
In the authorization apparatus described above, the authorization policy, which governs how access decisions are made, is based on a set of rules. These rules define conditions that must be met to grant or deny access, typically based on attributes of the user, the resource, and the environment. The rules are used to evaluate the individual authorization decisions made by the plugin modules.
9. The apparatus of claim 7 , wherein determining whether to grant the request is based on the contents of an object.
In the authorization apparatus described above, the decision to grant or deny access is based on the contents of an object. This means that the authorization policy considers the data or metadata associated with the resource being accessed. For example, access might be granted based on the object's owner, creation date, or security classification. The policy uses this information, along with the authorization plugin module decisions, to determine access.
10. The apparatus of claim 7 , wherein determining whether to grant the request is based on an editable file that associates the second plurality of authorization plugin modules with a calling application that provided the request.
In the authorization apparatus described above, the decision to grant or deny access is based on an editable file that associates the authorization plugin modules with the application that made the request. This file defines which modules are used for a particular application. This allows different applications to have different authorization requirements and configurations. The system consults this file to determine which modules to use when processing a request from a specific application.
11. The apparatus of claim 7 , wherein determining whether to grant the request comprises combining the plurality of authorization decisions.
In the authorization apparatus described above, determining whether to grant the request involves combining the authorization decisions from the selected plugin modules. This combination can involve various methods, such as requiring all modules to approve the request (AND logic), allowing any module to approve the request (OR logic), or using a weighted scoring system to combine the decisions. The specific combination method is specified by the authorization policy.
12. The apparatus of claim 7 , wherein the authorization policy is defined in extensible access control markup language.
In the authorization apparatus described above, the authorization policy, which defines how access decisions are made, is defined using Extensible Access Control Markup Language (XACML). XACML is a standard XML-based language for expressing access control policies. Using XACML provides a flexible and standardized way to define complex authorization rules that can incorporate various attributes of the user, the resource, and the environment.
13. The apparatus of claim 7 , wherein the authorization policy implements a Java™ authorization contract for containers.
In the authorization apparatus described above, the authorization policy implements a Java Authorization Contract for Containers (JACC). JACC is a standard set of interfaces and classes that allow Java EE containers (such as application servers) to enforce security policies. This means the authorization apparatus can integrate seamlessly with Java EE applications and leverage standard security mechanisms provided by the container.
14. The apparatus of claim 7 , wherein a first authorization plugin module communicates with a second authorization plugin module using a protocol selected by an external mechanism.
In the authorization apparatus described above, the authorization plugin modules can communicate with each other using a protocol selected by an external mechanism. This means the communication protocol is not hardcoded but can be configured, allowing flexibility and adaptability. For example, modules might communicate using REST APIs, shared memory, or message queues, depending on the specific requirements of the environment.
Unknown
August 12, 2014
Browse 5M+ US patents with plain-English claim translations and AI-generated analysis.