On a high level, attribute-based access control (ABAC) may be defined as a method where a subject's requests to perform operations on resources are granted or denied based on assigned attributes of the subject, assigned attributes of the resource, environment conditions, and a set of one or more policies that are specified in terms of those attributes and conditions. Here, attributes are characteristics of the subject, resource, or environment conditions. Attributes contain information given by a name-value pair. A subject is a human user or non-person entity, such as a device that issues access requests to perform operations on resources. Subjects are assigned one or more attributes. A resource (or object) is a system resource for which access is managed by the ABAC system, such as devices, files, records, tables, processes, programs, networks, or domains containing or receiving information. It can be the resource or requested entity, as well as anything upon which an operation may be performed by a subject including data, applications, services, devices, and networks. An operation is the execution of a function at the request of a subject upon a resource. Operations include read, write, edit, delete, copy, execute and modify. Environment conditions describe an operational or situational context in which an access request occurs. Environment conditions are detectable environmental characteristics. Environmental characteristics are generally independent of subject or resource, and may include the current time, day of the week, current stock market index, current temperature, or the current threat level. Finally, a policy is the representation of rules or relationships that makes it possible to determine if a requested access should be allowed, given the values of the attributes of the subject, resource, operation and possibly environment conditions. A policy may be expressed as a logical function, which maps an access request with a set of attribute values (or references to attribute values) to an access decision (or an indication that the request has not returned a decision).
An ABAC scenario is depicted in FIG. 1. In step 1, a user (or subject) 100 requests access to a resource 110 through the intermediary of an ABAC mechanism 120 which selectively protects access to the resource 110. The ABAC mechanism 120 forms a decision by retrieving, in step 2a-2b-2c-2d, applicable rules R1, R2, R3 from a policy repository 130, subject attributes (e.g. name, affiliation, clearance) from a subject attribute data source 140, resource attributes (e.g. type, owner, classification) from a resource attribute data source 150, and environment conditions expressed as environment attribute values from an environment attribute data source 160. If the ABAC mechanism 120 is able to determine that the decision is to permit access, it will take appropriate measures to grant the user 100 access to the resource 110, e.g. by selectively deactivating a hardware or software protection means. Otherwise, access to the resource 110 may be denied.
There currently exist general-purpose ABAC policy languages that have the richness to express fine-grained conditions and conditions which depend on external data. A first example is the Extensible Access Control Markup Language (XACML) which is the subject of standardization work in a Technical Committee of the Organization for the Advancement of Structured Information Standards (see www.oasis-open.org). A policy encoded with XACML consists of declarative (in particular, functional) expressions in attribute values, and the return value (decision) of the policy is one of Permit, Deny, Not Applicable, or Indeterminate. An XACML policy can apply to many different situations, that is, different subjects, resources, operations and environments and may give different results for them. The XACML specification defines how such a request is evaluated against the policy, particularly what policy attributes are to be evaluated or, at least, which values are required to exist for a successful evaluation to result. A key characteristic of this evaluation process is that the request must describe the attempted access to a protected resource fully by containing information sufficient for all necessary attribute values to be retrieved. In practice, it may be that the request is interpreted in multiple stages by different components, so that a PEP (Policy Enforcement Point) issuing the requests provides only some attribute values initially, and a PDP (Policy Decision Point) or other component responsible for the evaluation can dynamically fetch more values from remote sources as they are needed. A second example is the Axiomatics Language For Authorization™, which the applicant provides.
XACML-based solutions typically offer “authorization as a service”, wherein a PEP in a target application/system captures access requests in real time and sends them to a PDP for evaluation against a current version of one or more XACML policies. Such externalized authorization approach ensures continuity in that it drastically reduces or eliminates the latency between an update of the policy and actual enforcement of the new rules therein.
A company may deploy a plurality of applications of ABAC policies in order to separate the plurality of applications. The reasons for separation of a deployment into a plurality of applications may be related to confidentiality of the information in the different applications, e.g. between different units or sites of a company. Further, separation of applications may be related to stability concerns, such that any malfunctions within one application do not affect another application.
However, a deployment of an ABAC policy consumes information technology (IT) resources of a company. Hence, deployment of a plurality of applications may lead to large overhead costs in IT administration and management. Further, the deployment of a plurality of applications may consume computing resources, mainly memory.
USPTO Backgrounds
USPTO Backgrounds