Access control has gone beyond simply need-to-know to include need-to-share authorization. Traditionally, the focus of authorization and access control has been on building barriers to sensitive data and only making it available to a select few. But that’s changed as companies want to get more from their data and make it really work for them. Authorization is now about facilitating user access to the right data under the right conditions.One approach is Attribute Based Access Control, or ABAC.

 

ABAC is a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes.

 

This diagram shows the methodology:

 

The eXtensible Access Control Markup Language (XACML) Standard

 

XACML is a standard that defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies. Vendors may implement ABAC through XACML.

The XACML policy language is as expressive as a natural language. For example, consider the following sentence:

 

Jane Doe wants to view a confidential document at work during regular business hours.

 

A sentence like this includes four grammatical building blocks:

– a subject

– an action

– a resource

– the environment in which the request is made

Each of these “building blocks” can be described using attributes:

 

Term

Definition

Examples

Subject

Who or what is demanding access to an information asset.

Roles, group memberships, the department / company to which the user belongs, management level, certifications or competencies, user ID

Action

Action the subject wants to perform.

Read and write are common values. More complex scenarios, like a bank transfer, may use multiple attributes such as “action type=transfer” and “amount=$500”.

 

Resource

The information asset or object impacted by the action.

For banking, the resource may be “debit account=<your account number>.” In law firms, a resource could be a document and an attribute could be “case matter = 100.”

Environment

The context in which access is requested.

Current time, location from where access is requested, client type (PC, smartphone, etc.), type of communication channel (I.E. protocol or encryption strength)

 

 

Gathering Authorization Requirements

 

Now let’s define the authorization requirements for Jane Doe’s organization, which we will call The Organization.

 

The Organization has the following authorization requirements:

 

 

  • Any person must have the same clearance level or higher as the classification of the document he or she is requesting to view, must also be working on that project, be a current employee, and have finished the appropriate training.
  • Only senior personnel with a top secret clearance can edit records that are classified as top secret or below, if they are working on the project the record is part of, are a current employee, and have finished the appropriate training.
  • Junior personnel cannot view top secret information between 20:00 and 6:00.

 

 

Identifying Required Attributes

 

Now, referring back to the authorization requirements we defined for The Organization in the previous step, we will create an attributes table.

 

The columns in our attribute table include:

  • Short name: the user-friendly name of an attribute e.g. role or citizenship. It is the name usually displayed in editors and reporting tools.
  • Namespace: the context to which the attribute belongs. Namespace follows the reverse domain name notation naming convention, like we use in Java. So, if we have com.organization.user, we can append a short name like role to create the fully qualified XACML attribute identifier com.organization.role.
  • Category: a concept that comes straight from XACML that states an attribute always belongs to a category. There are 4 commonly used categories: subject, action, resource, and environment; they are defined in step 2 of our tutorial.
  • Data type: a classification of the data. Attribute values can be of different types in XACML. The most commonly used are string, integer, and Boolean. There over a dozen data types available to choose from.
  • Value range: an optional field to specify a pattern or range of provided values. Attribute values may be completely random (e.g. a user’s first name). Others belong to a fixed list of values e.g. state names or a pattern e.g. zip codes.

 

 

Short name

Namespace

Category

Data type

Value range

role

com.organization.user

Subject

String

Junior, senior

actionId

com.organization.action

Action

String

View, edit

objectType

com.organization.object

Resource

String

Record

clearance

com.organization.user

Subject

String

None, secret, top secret

classification

com.organization.record

Resource

String

None, secret, top secret

status

com.organization.user

Subject

String

Current, terminated

training

com.organization.user

Subject

String

X, Y, Z

training

com.organization.record

Resource

String

X, Y, Z

project

com.organization.record

Resource

String

A, B, C, D…

project

com.organization.user

Subject

String

A, B, C, D…

employeeId

com.organization.user

Subject

String

Alice, Bob, Carol…

recordId

com.organization.record

Resource

String

123,456,789…

 

 

 

Authoring the Authorization Policies

 

Now we need to write our authorization requirements into attribute-based rules.

 

Original requirement: Any person must have the same clearance level or higher as the classification of the document he or she is requesting to view, must also be working on that project, be a current employee, and have finished the appropriate training.

 

Attribute-based rule:

 

A user with role==”junior” OR role==”senior” AND user.clearance>=record.classification can actionId==”view” on objectType==”record” if classification==”secret” AND user.project == “record.project” AND status==”current” and record.training is in user.training

 

 

Original requirement: Only senior personnel with a top secret clearance can edit records that are classified as top secret or below, if they are working on the project the record is part of, are a current employee, and have finished the appropriate training.

 

Attribute-based rule:

 

 

A user with the role==”senior” can actionId==”edit” if user.project ==record.project AND user.clearance>= record.classification AND status==”current” and training == “training”

 

Original requirement: Junior personnel can edit a record if their clearance is greater than or equal to the classification of the record, if they are working on the project the record is part of, are a current employee, and have finished the appropriate training.

 

Attribute-based rule:

 

A user with the role==”junior” can actionId==”edit” if user.project==record.project AND user.clearance>=record.classification AND user.status==”current” AND user.training==record.training

 

Original requirement: Junior personnel cannot access top secret information between 20:00 and 6:00.

 

Attribute-based rule:  To write the next requirement as an attribute-based rule, we will use Abbreviated Language For Authorization (ALFA) language. ALFA offers a lightweight and compact syntax to write XACML policies programmatically.

 

The rule below implements the time-based access control mentioned in the original requirement:

 

 

 policy checkTimeAccess {

    apply firstApplicable

      rule checkNightAccess {

        target clause role == “junior” and classification = “top secret”

        condition timeInRange(timeOneAndOnly(currentTime),

          “20:00:00”:time,  “06:00:00”:time)

      deny

      }

   }

 

Deploying the Policies

 

Now that we have finished creating our policy, let’s deploy it. Different implementations of XACML have different ways of deploying policies. At the very least, we need to make sure our policies our associated with a Policy Decision Point (PDP).

The PDP is responsible for evaluating the applicable policy and rendering an authorization decision.

 

Defining Policy Information Points (PIPs)

 

 

Policy Information Points (PIP) are the components in the ABAC architecture that store attribute values. PIPs come in a variety of form factors including LDAP directories, databases, and web services.

 

During the process of an evaluation, the PDP can call out to one or more PIP endpoints. For instance, a SQL database may communicate via Java Database Connectivity (JDBC).

 

It is important that we make sure our connection is configured to map information the PDP needs.

 

 

Configuring the user attributes

 

Now we need to map the following attributes and the way way we do it depends on the implementation of XACML we are using.

 

·      com.organization.user.role

·      com.organization.user.clearance

·      com.organization.user.status

·      com.organization.user.training

·      com.organization.user.project

·      com.organization.user.employeeId

 

To map these attributes, all we need to know is:

·      The attribute we want to map, such as com.organization.user.role

·      The source table, in our case Users

·      The key attribute – username for employeeId

 

Configure the resource attributes

 

We map these resource attributes as well:

·      com.organization.object.objecttype

·      com.organization.record.classification

·      com.organization.record.training

·      com.organization.record.project

·      com.organization.record.recordid

 

Validating Our Policies

Description

 

We can use access reviews to verify that the policies do deliver the desired use cases. The tests best suited for this are the PEP-PDP tests. For this, we develop independent, self-contained tests that do not use external data.

 

We also plan for tests that take into account the data sources (PIP). Tests can be used to verify that policies do not have side effects or gaps. In both cases, we make sure tests are always defined as a single unit test and then run together in a series or batch.

 

 

Use Case Tests

 

Here’s a table:

 

 

Description

Expected Result

Rule #1

 

Can Alice, who has a secret clearance, view a top secret document?

Deny

Can Bob, who has a top secret clearance, view a top secret document that requires completion of Training A, even though he has not completed Training A?

Deny

Can Carol, who has a secret clearance, view a secret document related to her project that she has completed the requisite training for, while she is a current employee?

Permit

Rule #2

 

Can Bob, who has a top secret clearance and is a junior employee, edit a top secret document?

Deny

Can Alice, who has a secret clearance and is a senior employee, edit a top secret document?

Deny

Can Dan, who has a top secret clearance and is a senior employee, edit a top secret document related to her project that he has completed the requisite training for, while he is a current employee?

Permit

Rule #3

 

Can Bob, who has a top secret clearance and is a junior employee, view top secret information at 22:00?

Deny

Can Dan, who has a top secret clearance and is a senior employee, view top secret information at 22:00?

Permit

 

 

Testing with Policy Information Points (PIP)

 

We use tests with policy information points to validate that the overall solution has been correctly configured.

 

We evaluate whether or not:

  • The authorization domain to which the PDP belongs is properly connected.
  • Attributes are correctly mapped to the data.
  • The PDP can properly communicate with PIPs.

 

Now let’s take the use case tests we defined and keep the key attributes only. This would include the user identifier, the resource identifier, and the action identifier as well as time of day, in our example.

 

We now will send XACML requests from a Policy Enforcement Point (PEP). The first use case test in Rule #1 in the table above would look like this:

 

 

{

        “Request”: {

            “AccessSubject”: {

                “Attribute”: [

                    {

                        “AttributeId”: “com.organization.user.role”,

                        “Value”: “Senior”

                    },

                    {

                        “AttributeId”: “com.organization.user.clearance”,

                        “Value”: “0_Secret”

                    },

                    {

                        “AttributeId”: “com.organization.user.employeeId”,

                        “Value”: “Alice”

                    }

                ]

            },

            “Resource”: {

                “Attribute”: [

                    {

                        “AttributeId”: “com.organization.record.status”,

                        “Value”: “1_TopSecret”

                    },

                    {

                    “AttributeId”: “com.organization.object.objectType”,

                        “Value”: “record”

                    }

                ]

            },

            “Action”: {

                “Attribute”: [

                    {

                        “AttributeId”: “com.organization.action.actionId”,

                        “Value”: “View”

                    }

                ]

            },

            “Environment”: {

                “Attribute”: []

            }

        }

}

 

 

 

Conclusion

 

In this tutorial, we have reviewed the fundamentals of Attribute Based Access Control and demonstrated how it offers dynamic, context-aware and risk-intelligent access control while going through an example.

 

For more information on Attribute Based Access Control, visit our Access Control 101 resource library.

 



Leave a Reply

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