Oasis ABAC Architecture
An Oasis ABAC implementation consists of a number of components, each playing their part in delivering a single authorization decision.
Policy Enforcement Point (PEP)
The PEP represents the layer responsible for delivering the final permit/deny outcome to the application code. The application code supplies the PEP with a request context describing the nature of the request. For example, the application code could provide:
- Resource = "MainDoor"
- Action = "Open"
The PEP then consults the Policy Decision Point (PDP), providing the request context for it to consider as part of its decision-making process. Normally the PDP will return a definite Permit or Deny. However, it is possible that the PDP cannot make a definitive decision. For example, the policies that can be evaluated may be, in some way, incomplete. The application still requires a definitive answer to know whether it can proceed, and so the PEP uses PEP Bias (Permit or Deny) to provide an outcome upon which the application can act.
In addition to providing a policy outcome of a permit or deny, policies may provide obligations and advice. Obligations refer to actions the PEP must be able to complete for the policy outcome to be propagated to the application. An example of an obligation would be to create an audit record recording the permitted action. Advice refers to actions that the PEP may or may not be able to complete without affecting the policy outcome. For example, when the PDP denies user access user, it could provide a piece of advice that describes why. The PEP may not be able to do anything with this advice and will propagate it, with the outcome, to the application (who in turn may display the reason to the user). The ability of the PEP to process a piece of advice, unlike obligations, has no bearing on the policy outcome.
Policy Decision Point (PDP)
A Policy Decision Point takes the request from the PEP and applies a set of policies to the request to determine the permit or deny outcome. The policies are driven from information in the request and also information from the environment. For example, a request to update a medical record may require information about the doctor who is assigned to that medical record. PDPs refer to Policy Information Points (PIP) to obtain information necessary to execute the policies that is not contained in the request context.
Policy Information Point (PIP)
A Policy Information Point attempts to resolve information required by the policy to execute. These pieces of information are called Attributes. The PIP is typically composed of many Attribute Value Providers, each providing a variety of information. For example, there may be a value provider that provides user identity claim attributes; another may provide information about the purchase order limit of the requester. The attributes delivered may come from a relational database, requests to REST APIs, LDAP, or any other source of information.
Policy Access Point (PAP)
The Policy Access Point provides policies to the PDP. Separating the storage of policies from the PDP enables a variety of different storage options, for example: file system, relational database, and GIT