3

The simple solution to access restriction when number of users are small is Access Control Matrix. Here the rows are the users and columns are different types of asset.

In my case, I have a document which I need to serve which have different attributes. So my columns will be different attributes. So now it is simple 2-D matrix.

But I have requirements which also depend on the information inside document. So lets say I have two types of documents, one with X attribute and other without X attribute.

As far as I have got, this will increase the dimension of my matrix to 3-D, where in Z axis I will have two entries, "X Attr Doc", "Without X Attr Doc".

My requirements are such that it also depends upon the information i am serving.

Only Solution I have come up till now is to have a 2-d matrix and in each cell of the matrix have a certain rule.

Looks like this: Access Matrix

Here the ClientIDs are different users, and Public, Core, Private, Default are different categories (set of attributes) of which they are granted access or not.

You can see in one cell, the access is granted only if certain condition is met which depends on the document.

Also, I want in future this table to be configurable, for eg, whenever a new client register, we can add one new row. Or we can have new column if we have new category which need to be served.

Is there any better solution? If not, can any one suggest the most performance efficient way to implement it in JAVA. I was thinking of expression language like SPEL, but I have no idea.

David Brossard
  • 1,360
  • 7
  • 16
prakharjain
  • 447
  • 1
  • 3
  • 11

1 Answers1

5

Disclaimer: I work for Axiomatics, the leading fine-grained authorization vendor.

Hi Prakharjain,

What you are describing is the basis for Attribute-Based Access Control (). With ABAC you define access based on user attributes as you would in RBAC (e.g. user identity, role, group) but also other user attributes (department, date of birth, location...) as well as resource attributes, action attributes, and environment attributes (IP address, time, device).

In your case, you want to control access to assets e.g. a document. You state that your document has different attributes. In ABAC, you can define a document owner, whitelist, blacklist, type, sensitivity, department, etc... You can have as many attributes as you like.

Once you've defined your attributes (essentially your information model), you can start defining your authorization policies. This is the key here. Rather than define permissions in a table or matrix (which are hard to define, maintain, keep up-to-date, and audit), you define authorization entitlements using policies. A policy looks like the following:

A user can view a document in their department.

This is the baseline Permit policy. It grants access provided the user and the document are in the same department. A rewritten (broken down) version would look like:

A user can do action == "view" on asset of type == "document" if user.department == asset.department

And you can add more policies to the baseline one. For instance, you could state that

  1. If the user is not the owner and the document is private, then deny access.
  2. If the user.clearance < document.classification, then deny access.
  3. If the user is in the whitelist, then allow access.

You can choose how policies get combined together.

In addition to defining attributes and a policy model, ABAC also defines an architecture:

Attribute Based Access Control Architecture

  1. the Policy Decision Point (PDP): the core of the architecture where policies are evaluated and decisions are reached. The PDP is to XACML what the Supreme Court is to US law.
  2. the Policy Enforcement Point (PEP): the integration items which can be anywhere in an application architecture. PEPs are extremely versatile depending on where they enforce access control. The PEP is to XACML and the PDP what police officers and judges are to courts and the law
  3. The Policy Information Point (PIP): in ABAC and XACML, there is a need for attributes. Attributes are there to describe users, services, resources, actions, and the environment. Policy Information Points are attribute stores. They can be any format and located anywhere. PIPs are to XACML what the DVLA, the set of police records, the census bureau, etc… are to a nation and its citizens.
  4. The Policy Administration Point (PAP): this is where you manage your policies.

There is one major standard which implements ABAC and that is XACML (eXtensible Access Control Markup Language). What you need is a XACML implementation such as Axiomatics Policy Server.

Also have a look at this question I replied to.

HTH, David.

David Brossard
  • 1,360
  • 7
  • 16