What is Attribute Based Access Control? - Axiomaticsma.axiomatics.com/acton/attachment/10529/f-01e1/1...axiomatics.com webinfoaxiomatics.com US Office 1 (312) 3-33 Europe Office 6

The New School of Thought

1 Creating a Business Case for Attribute Based Access Control

What is Attribute Based Access Control?

axiomatics.com | [email protected] | US Office +1 (312) 374-3443 | Europe Office +46 8 51 510 240


IntroductionThis paper looks at the history of access control and explains why Attribute Based Access Control has become the standard authorization model at organizations that need to both secure and share information assets.

The essay uses easy-to-understand examples to show the strengths and weaknesses of different authorization models.

It then goes on to explain how ABAC can overcome legacy authorization issues to provide a robust, flexible and fine-

grained solution to the access control challenges faced by today’s organizations. The paper also looks at the ABAC

architecture and details the key elements of the ABAC solution. Finally, it discusses the importance of policies and how

they can be used to satisfy strict internal controls and regulations.

Access ControlLet’s begin by answering the question: What is access control? Access control is the act of controlling access to anything.

Controlling access to physical locations such as a room, for instance. Or controlling access to documents online. Or

controlling access to secret formulas and trade secrets. Access control has been around as long as people have had

the need to share their resources selectively.

Access Control ListsTypically access control relies on verifying someone’s identity. For instance, most probably you will only let a family

member, or someone you know, into your home. You know the identity of the person and so grant them access to your

home accordingly. In the software world, identity is also commonly used as a basis for granting access. When we control

access based on user identity, we typically talk about access control lists (ACL). Many content management systems

use multiple ACLs to determine who can gain access to a given context.

ACLs are lists of user identities/names (e.g., Alice, Bob, Carol) that are associated with a resource that can be accessed.

Imagine a school where the chemistry lab has an ACL containing the names Alice and Bob. Such a list can be augmented

with actions. Alice can enter the lab but not leave it. Bob can both enter and leave the lab. In this case, the ACL would

be composed of both a username and an action.

ACLs are simple and straightforward but they are limited in terms of scale, management, flexibility and expressiveness.

How, for example, would you define an access control list for an entire school? What if the school had 1,000 students,

100 teachers, additional staff members, numerous resources, and an array of possible actions these actors could

perform? Suddenly this simple access control model is no longer so simple.



The problem with ACLs is that they are one-dimensional. Their simplicity fails to address the complex needs of today’s

organizations.

Role-Based Access Control (RBAC)Rather than focusing on identities, let’s consider a different organizing principle: roles. An individual associated with a

school could be a student, a teacher, or a member of the non-teaching staff (a nurse, an administrator, a food service

worker). These are all roles. Using this principle, we can start organizing our access control based on user roles and

the permissions associated with those roles. Teachers, for example, can issue grades. They can enter the teachers’

lounge. Students can use the cafeteria while nurses can enter the school clinic.

Role-Based Access Control (RBAC) was first defined in a seminal paper in 1992.1 RBAC was soon standardized by

the National Institute of Standards & Technology and quickly became the de facto standard for access control. This

model works extremely well with a medium-sized user base, a small number of applications, and simple access control

challenges. RBAC starts to fail when the number of access control use cases grows beyond a given point and becomes

unmanageable. This leads to a problem the IT security world has dubbed “role explosion”.

Role Explosion

Imagine for instance that a school wants to make sure students can only access classrooms that are relevant to their

grade or school year. Imagine further that a teacher can only enter a classroom associated with their department, and

that students can become teaching assistants. To manage these requirements, we would need a new role for every

year, class, and department department. And the more departments and years there are, the greater the number of

roles required. This is why many organizations using RBAC experience what’s called “role explosion”. The tendency

is for the number of roles to increase--along with their associated permissions--to the point where the system becomes

impossible to manage.

Segregation of Duty (SoD)

Role explosion is not the only major challenge faced by RBAC users. Another involves segregation of duty. Banks, for

instance, do not want traders approving the transactions they have initiated. And returning to our school example from

above, we would not want students to be able to edit student grades. But what about students serving as teaching

assistants? We might want them to be able to edit other students’ grades, but not their own.

In RBAC terms, teaching assistants would have two roles: that of a student and that of a teaching assistant. But assuming

students can view their own grades and that teaching assistants can edit student grades, a person with both roles could

potentially edit his or her own grades.

1 Ferraiolo, David F, and D Richard Kuhn. “Role-based access controls.” arXiv preprint arXiv:0903.2171



To prevent teaching assistants from editing their own grades, we need to ensure that there is a Segregation of Duty

(SoD) in place. Unfortunately, RBAC doesn’t have a mechanism for implementing SoD in this sort of common, real-

world example. We could try to work around the problem by making sure students are never made teaching assistants

or we could remove the “edit grade” action from the teaching assistant role. But this would force us to alter our

requirements for the sake of our access control system’s limitations.

Outgrowing RBAC

What if we could express access control not only in terms of roles and permissions but also in terms of additional

parameters such as “year,” “department,” and “permissions”? What if we could express a relationship between an actor

and a targeted object? Such an access control model would be truly multi-dimensional, and this is where Attribute

Based Access Control is a perfect fit. What if we could use contextual information, e.g: time of day, risk score, etc...

Attribute Based Access Control (ABAC)Role, department, and year are examples of attributes. An attribute is a piece of information that can be used to describe

someone or something. An attribute is typically a key-value pair, meaning that attributes come in sets: an identifier (or

key) and the value or values identified with it. The attribute identified as “role” could, for example, have values such as

“art teacher,” “teaching assistant,” “nurse,” etc.

We referred to RBAC as being two-dimensional because it focuses exclusively on user roles and permissions. ABAC

has the ability to employ user attributes, action attributes, context attributes (such as time, device, and location) and

many more. The fact that we can use attributes that describe virtually anything makes ABAC multi-dimensional.

Policies

Attributes alone, though, are not enough. Let’s say you are a teacher in the arts department. How do we implement

your authorization requirements based on those attributes? We need a mechanism that will allow us to do that.

In ABAC we use a policy language called the eXtensible Access Control Markup Language (XACML). Using this

language, we can combine attributes in order to implement our policy requirements.

Say for example we have the requirement “Teachers can view student grades.” XACML allows us to take this sentence

and translate it into attribute categories. These categories represent the grammatical function of the attribute in the

authorization requirement.



Requirement: Teachers can view student grades.

The word in red represents the subject while the word in green, the verb, denotes the action. Finally, the words in blue

represent the object or resource targeted for access.

In terms of attributes, the requirement is:

○ Users with role = teacher

○ Can do the action = view

○ On object type = grade

Using XACML, policies can be written to satisfy extremely complex requirements. For this reason, some have dubbed

ABAC “policy-based access control.” XACML policies help to make ABAC extremely flexible and expressive to both

share and lock down access as conditions dictate.

Policies Enable Relationships

One of the key aspects of ABAC is its ability to implement relationships. ABAC is multi-dimensional in that it

can utilize attributes that describe the user, the resource, the action, and the context. When we have attributes

of the user and attributes of the resource, we can then relate them together.

Let’s return to the policy requirement allowing teachers to view student grades. What if we wanted to ensure that

teachers could only view the grades of those students attending their course?

Requirement: Teachers can view the grades of those students attending their course.

Broken down into attributes, the requirement becomes:


○ Can do the action = view

○ On object type = grade

○ If grade.course.teacher = user.userId

The conditional expression at the end denotes a relationship. From the grade a student has received, we look at the

course for which the student received the grade. From the course, we determine who was the teacher of that class.

We compare that teacher’s identity to the identity of the individual trying to view the grade. If there is a match, that

teacher can view the grade.



This ability of ABAC to implement relationships makes it far more flexible than RBAC and provides more fine-grained

access than RBAC ever could. The use of relationships helps to avoid role explosion and allows for truly fine-grained

access control.

Policies Scale Better

Another area in which ABAC outperforms RBAC is in scalability. The use of policies allows ABAC to scale effortlessly

where scaling RBAC is cumbersome and labor-intensive.

Imagine we have a requirement that teachers in the art department can enter classrooms in the art department.

Requirement: Teachers in the art department can enter classrooms in the art department

In terms of attributes, the requirement can be rendered as follows:


○ Can do the action = enter

○ On object type = classroom

○ If teacher.department = classroom.department

Note that the implementation is abstracted away from any particular department. This means the policy will work

regardless of the department. As a result, it will work equally well whether we are talking about the math, science,

biology, or art department. It will even work for a new language department the principal is slated to launch next semester.

In ABAC, you only need one policy to provide for all these possibilities whereas in RBAC you would need to implement,

manage, provision, and de-provision numerous new roles.

In short, ABAC scales better because policies scale better. It reduces the management burden and also makes sure

the right access control checks are applied consistently to all entities in the system.

With policies, the provisioning and de-provisioning process is made much simpler. In RBAC, you are constantly having

to add or remove roles and/or permissions from users. In ABAC, the user’s attributes are used directly, which greatly

simplifies this process since we no longer need to worry about granting or removing user permissions as this is taken

care of automatically.



POLICIES ENABLE DYNAMIC SEGREGATION OF DUTY

We have seen that ABAC enables relationships and that relationships improve scalability. Now we will look at how

relationships help to eliminate violations of Segregation of Duty, also known as toxic combinations. To illustrate this

point, let’s go back to our teaching assistant example.

The original requirements were:

○ Teaching assistants can modify students’ grades.

○ Teaching assistants cannot modify their own grades.

In an RBAC setting, we would be unable to satisfy the combination of the two requirements because we would be

limited to a static form of segregation of duty. In other words, we could grant a teacher the ability to modify student

grades and we could grant students the right to view their own grades. As students, teaching assistants would not be

able to modify their own grades, or those of anyone else. This would prevent the teaching assistants from tampering

with their own grades but it would also prevent them from performing one of their required functions: modifying other

students’ grades.

Because teaching assistants are both students and teaching assistants at the same time, requirements like those above

lead to a toxic combination. RBAC cannot resolve such a dilemma. But ABAC can, by employing yet another type of

relationship.

○ Users with the role = teaching assistant

○ Can do the action = modify

○ on object type = grade

○ If grade.student.name != user.userId

In this case, a user who is a teaching assistant can modify a student grade unless the user is the student in question.

This relationship implements segregation of duty check and avoids any toxic combination. Students can now become

teaching assistants and carry out grading tasks but they cannot modify their own grades. Mission accomplished!

POLICIES CAN ADDRESS DIFFERENT SCOPES

ABAC provides a unified, consistent, and coherent way of addressing different access control concerns across an entire

enterprise. For every department or user, the same tooling and language is used to express access control requirements,

namely, attributes and policies.



Consequently, different parties within an organization can create access control policies to address their own concerns.

This means that the head janitor can define specific policies, as can the principal or various student groups. This is

possible because policies can be made to address different scopes or concerns.

For instance, the head janitor may want to define when staff and students may enter the school grounds:

○ Deny teachers and students access to school grounds between 10pm and 6am.

The principal may want to deny access to students that have been expelled:

○ Deny expelled students access to school grounds and school resources.

The principal may also want to implement a chewing gum ban:

○ Deny access to anyone chewing gum.

Chemistry teachers may want to limit access to the lab supply room to only a few trusted students:

○ Allow a student access to the lab supply room if the student’s name is on the trusted student list.

These requirements introduce a variety of policy authors. We have global rules (such as the chewing gum ban) and

specific rules (such as the chemistry lab rule that only applies to the chemistry department). ABAC can accommodate

these different authors and their different concerns of various scope. It can even work out conflicts between policies

since it allows us to define policy priorities.

POLICIES BRIDGE THE GAP BETWEEN THE BUSINESS AND IT

RBAC has traditionally been in the hands of IT and more specifically the IAM (Identity Access Management) team. The

rise in the number of applications, data, and users, has led to IAM teams creating ever-increasing numbers of roles

and permissions. This has led to roles and permissions with complex names and obscure meanings like “teacher_

dept123_lab1”.

Because ABAC is policy-based and because policies use natural attributes such as user role, department and date of

birth, the policies themselves are a direct reflection of the original requirement. The use of attributes allows the requirement

to map directly into the policy. This provides several benefits. Policies are relatively easy to maintain. They make it

possible to verify authorization policy coverage. They can be efficiently audited and compliance can be effectively

proven.



Externalized AuthorizationWhat is externalized authorization?

The ABAC model provides externalized authorization by leveraging the principle that software code should be decoupled

based on the function it serves. Instead of delivering a single application that implements all the features that are

required, the software developer simply implements core business functionality and reuses common blocks for non-

functional aspects such as authentication, logging, and data storage.

These non-functional aspects can then be effectively externalized. No one would dream of re-implementing authentication.

The same applies to authorization. Why should application developers have to rewrite authorization for each application?

Why can’t applications simply reach out to an external authorization server as they do for authentication? ABAC

addresses these challenges and meets them.

Existing frameworksABAC did not invent externalized authorization. The term Externalized Authorization is used by Gartner to describe the space ABAC lives in. Other analyst firms e.g. Kuppinger Cole called this space Dynamic Authorization Management.

Many frameworks have strived to externalize authorization in the past. Such frameworks include:

• The Java Authentication and Authorization Service, or JAAS is the Java implementation of the standard Pluggable Authentication Module (PAM) information security framework.

• Spring Security (Java)

• Microsoft Claims

There are many more frameworks in different layers (application layer, data layer…) that are being used to externalize authorization. While these frameworks are a great way forward in terms of externalizing authorization and making it more manageable, they still suffer from several issues:

• The frameworks are technology-specific i.e. they require subject-matter expertise

• They only work for a given set of applications e.g.:NET

• The frameworks are typically only role-based

• The frameworks are seldom policy-based



ABAC enables externalized authorization by:

○ Providing a standard architecture

○ Providingastandardauthorizationpolicylanguage

○ Providingastandardmechanismforqueryingauthorizationdecisions

What is externalized authorization?

In ABAC, authorization is no longer implemented in code but rather using policies in XACML, a standard policy language.

XACML is rich enough to define many different scenarios--from simple, role-based access control use cases to access

control lists to relationship-based and risk-aware access control. It uses attributes of the user, the resource, the action,

and the environment.

Policies are defined, authored, managed, and versioned centrally at a central point of management. They can be run

centrally or distributed for local decision-making or enforcement.

Because policies are managed outside the application being protected, they can evolve independent of the application

code. This makes it easier to adapt the application to new scenarios and authorization requirements.

The key components are:

• Policy Enforcement Point (PEP): the PEP is responsible for protecting the application. It intercepts the business

flow between the client and the application, converts the business request (View record #123) into an authorization

request (Can Alice view record 123?) and sends it off to the PDP. When it receives a response back from the PDP,

it enforces it, that is, it lets the original business request go through to the backend application or it bounces it back

to the client. The PEP’s form factor depends on the nature of the application being protected. For instance, you

might use an API gateway to protect APIs and microservices. You could use an IIS filter to protect .NET web

applications.

• Policy Decision Point (PDP): the PDP is at the center of the architecture. It is the brain or engine that processes

the incoming request and evaluates it against the authorization policies it has been configured with. It eventually

produces a decision that it sends back to the PEP. In the process of evaluating policies and producing a decision,

it may turn to policy information points (PIP) to retrieve additional attribute values for needed attributes such as a

user’s department or role.

• Policy Information Point (PIP): a PIP is the driver that connects the PDP to underlying sources of attributes. These

sources can be LDAP, databases, web services, and more. The sources contain metadata about the user or the

resource. Examples include the user’s role, department, date of birth, and clearance, as well as the resource’s

classification, department, and amount (in the case of a transaction). A PDP can use several PIPs at the same time

to retrieve several attribute values.



• Policy Administration Point (PAP): the PAP is the tool through which administrators create, manage, and edit

authorization policies. The policies are then deployed to the PDP.

Central Point of Management

The architecture, with a single Policy Administration Point (PAP), enables externalization and centralization of the

policies and configuration. It makes the system easier to manage and more scalable. It also makes it possible to centrally

manage all the Policy Decision Points (PDP). This is an improvement from existing authorization systems that come

with their own management portals, as these make the system difficult and time-consuming to manage as well as hard

to keep in sync.

The fact that Policy Decision Points are centrally managed means they can be deployed in a variety of ways. For

instance PDPs can be installed as a central enterprise authorization service, or they can be located with the application

they are protecting. This can enhance the performance of the system.

ABAC follows the architecture defined in the XACML standard and depicted in the graphics below.

Scalable Authorization

Because the Policy Decision Point is stateless, several PDPs can be deployed to increase the load and throughput.

To this end, administrators can deploy PDPs behind a load balancer and distribute traffic accordingly. This means it is

possible to grow the authorization capacity linearly with the growth in demand.



Standardized Request / Response Process

One of the key benefits of ABAC is that it standardizes the way authorization is queried. Unlike other existing frameworks

(Spring, claims-based, etc.), which have different ways of querying their own authorization engines, the ABAC authorization

approach boils down to a simple “Yes” or “No” response. This applies no matter how complicated the question. The

simplicity of the request/response process facilitates integration with different applications and frameworks.

ABAC also lets you have richer response flows. Although the response is always in terms of a Yes/No question, the

decision can be augmented with additional statements such as:

○ Yes, allow + log the fact the user has been granted access. Or

○ No,deny+reroutetheusertoatwo-factorauthenticationpage.

Policy-Driven AuthorizationUsing policies to meet internal controls and regulations.

As mentioned earlier, ABAC is sometimes referred to as policy-based access control. It is the authorization policies of

an organization that govern who can access information and the conditions under which they can do so. These make

it possible for organizations to comply with strict regulations in every market in which they operate. ABAC policies are

written in the XACML language. XACML can precisely replicate in a policy any regulations or internal controls to be

enforced. The Policy Decision Point will then ensure requested data is protected in accordance with that policy.

Policy auditing and compliance validation.

We have already discussed role explosion and the management difficulties it presents. Using policies to externally

manage authorization not only reduces the demands on administrators; it also considerably simplifies the auditing

process. With the right tools auditors can get a list of the conditions under which a policy allows a user to view data, or



alternatively the full set of the conditions under which the data can be viewed. This level of authorization transparency

helps auditors prove compliance and allows managers to see what team members or third parties have access to.

SummaryAccess control has evolved to meet the changing security challenges organizations face in the digital age. Attribute

Based Access Control is quickly becoming the standard model for organizations confronted by the need for a robust

and flexible solution to today’s increasingly complex security demands. Unlike earlier access control models, ABAC

provides a multi-dimensional system that through its use of attributes and policies prevents role explosion, increases

scalability, enables relationships, eliminates Segregation of Duty conflicts, and externalizes authorization for ease of

management and control. Additionally, it allows organizations to comply with an ever-growing body of regulations in an

increasingly demanding regulatory environment.

If there is a textbook way to protect sensitive assets, ABAC is it.

[email protected] www.axiomatics.com twitter.com/axiomatics

525 W Monroe St, Suite 2310Chicago, IL 60661, USA

Tel: +1 (312) 374-3443

Västmannagatan 4S-111 24 Stockholm, SwedenTel: +46 (0)8 51 510 240

Trademarks All brand names and product names used in this book are trademarks, registered

trademarks, or trade names of their respective holders.

Copyright © 2016 by Axiomatic. All rights reserved.

Our best-in-class software can be deployed across any it environment to safeguard data.

Call or email us to learn how Axiomatics can work with your enterprise:

Documents

What is Attribute Based Access Control? - Axiomaticsma.axiomatics.com/acton/attachment/10529/f-01e1/1...axiomatics.com webinfoaxiomatics.com US Office 1 (312) 3-33 Europe Office 6