Trusted Information Sharing – ABAC Architecture

In my previous post, I introduced you to the two concepts of Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). ABAC resolves a number of the limitations associated with RBAC, as I discussed in that post. In this post, I wanted to drill into the architecture underlying ABAC a little bit more.

In simple terms, there are four main parts of the ABAC architecture. These are:

  • The Policy Decision Point (PDP) – this is really the brains of the ABAC architecture. It evaluates requests for information against policies that it has been configured with. If it does not have enough information to make its decision to permit or deny access to the information, it can ask for more information from another part of the architecture, the Policy Information Point.
  • The Policy Information Point (PIP) – this acts as a bridge if you will between the PDP and other external sources of information, including databases and LDAP directory servers. It retrieves additional attributes from these external sources and passes them back to the PDP so the PDP can make its decision.
  • The Policy Administration Point (PAP) – this is the tool that is used to create the policies used by the PDP.
  • The Policy Enforcement Point (PEP) – this is responsible for protecting the information being requested. It inspects a request for information, and then creates an authorization request which it sends to the PDP.

Now let’s take an example that walks through an information request and how it is processed with the ABAC architecture. Using an example that most of you would be familiar, let’s say we have an application that a user Pete is trying to select information with, and that information is stored in a database. There are a number of steps that happen when a simple request such as this is made. Let’s look at such an example very simplistically, leaving out many of the complexities. The steps can be summarized as follows (the numbers refer to the diagram below this list):

0. Step zero is not actually shown in the diagram below. That’s where user Pete logs in to the application. There may be a variety of load balancers, firewalls and so on involved here, but for now these aren’t germane to this discussion so we’ll ignore them.

  1. Pete requests some information from the database behind the application. What that information is doesn’t matter, but let’s say for now he asks to view a particular file. For future reference, this is the sort of thing Trusted Information Sharing is all about – sharing files and other information securely. But I’ll come back to that in a later post. 🙂 In this application, the request for Pete to view a particular file is passed to the Policy Enforcement Point (PEP). The PEP looks at that request and generates an authorization request – can Pete view the file?
  2. The authorization request generated by the PEP is passed to the Policy Decision Point (PDP).
  3. The PDP evaluates the policies that have been set up for this system to help it determine whether to permit or deny Pete’s request. Those policies are created and maintained by the Policy Administration Point (PAP), in a separate process to that being shown here.
  4. The PDP may not have enough information from the policies it evaluates to determine if the request should be allowed. For example, let’s say the file that Pete is requesting is classified as Top Secret. The policy defines that, but it doesn’t tell the PDP whether Pete has that classification or not, so the PDP needs to talk to one or more Policy Information Points (PIPs) which can retrieve Pete’s classification as an attribute from something like an LDAP server.
  5. The decision to permit or deny Pete access to that file is passed back to the PEP by the PDP.
  6. If the decision made by the PDP is to permit Pete viewing the file, the information needed for that retrieval is extracted from the database behind the application.
  7. And finally, Pete can view the file

So there you have it. That’s how ABAC works in generic terms. You’ll notice that just like my last post, I have not referred to any specific products that actually handle this work, just the concepts that make up the architecture. In my next post, I’ll start introducing some of the products that can be used in implementing such an architecture.


After 22 years of working at Oracle in just about every role except Marketing and Support, I am now working as a Senior Managed Services Consultant with Red Stack Tech, specializing in Oracle Database technology, High Availability and Disaster Recovery solutions. I am also a member of the OakTable Network, and have presented at RMOUG Training Days, Hotsos Symposia, Oracle OpenWorld conferences, and other user group events. I have co-authored the Expert Oracle Enterprise Manager 12c and Practical Oracle Database Appliance books published by Apress, and am one of the authors of the Building Database Clouds in Oracle Database 12c book published by Addison Wesley.

Leave a Reply

Your email address will not be published. Required fields are marked *