Granularity in authorization: Fine grained vs. coarse grained authorization

As discussed in previous post about authorization, it’s the process by which the access or entitlement of the requester for the requested resource is decided or assured.

Granularity which literally means “level or scale of detail” and hence granularity in authorization means the level of details used to put on authorization rules for evaluating a decision to grant or deny the access.That means, If authorization rule for a resource access as per business need is just based on particular check(like associated roles) only then it is coarse. However, on contrary if business needs require more details regarding end user/actor, current environment conditions (time, date) etc. to grant the access then it is more granular and fine grained authorization.

Let’s understand the difference in  more details by taking  an example where the permissions for a page and service are defined for both the scenarios.

Coarse grained vs fine grained authorization

Coarse grained:

Assume the following permission sets which defines the access based on role assigned to the user

  • Rule 1: The users having the role “X” can access the page “/xyz/abc” .
  • Rule 2: The users with role “Y” can access the service “S1”.

Now as per above Rule sets the access is governed on the basis of role associated to the user and not based on any other user specific details or environmental conditions etc. As per above rules the user with appropriate roles can access the resource irrespective of any other conditions. Since normally a user may assign to multiple roles simultaneously there are different flavors of RBAC (like flat or hierarchical RBAC system etc.) but that will still rely on the roles and their combinations. The above rule sets here is based on prominent authorization system called Role Based Access Control system (RBAC). Here in this case RBAC is quite explicit and hence we can call it a coarse grained authorization

Fine grained authorization:

Now imagine if we want to restrict the access based on other additional conditions as well for the same scenario and as per below rules :

  • Rule 1: The service “S1” can be accessed by users

a)      Having role “Y” assigned to them And
b)      Belonging to region “Chicago” And
c)       Between 8 am to 5 pm And
d)      From a particular list of IPs’.

  • Rule 2 : The page “/xyz/abc” can be accesses by users:

a)      Having role “X” assigned to them And
b)      Gender is “Male”  And
c)       Age greater than 45 And
d)      Qualification is “Grad” Or “PostGrad”.

Now in above two rules set we can see that the level of authorization is more detailed or scaled than the earlier rules set. Here we have more granularity for taking decision and governing the access as per business needs and hence we can call it as fine grained authorization.

If we observe in fine grained rules above, there are rules which are also based on user attributes like “baseLocation”,“gender”, “age”, “qualification” etc and other environmental attributes  like “Time range”, “IP based” etc.  And similarly we can create rules based on user’s action on resource like “view”, “delete”, “read” etc. This granularity is achieved here by taking these attributes and it is known as “Attribute based Access Control” (ABAC) in today’s era.

One can assume ABAC having four governing factors whose attributes can be defined for access control. These are “subject”(or end user/actor), “resource”, “action” and “environment”.

How to implement fine grained authorization?

Now one can also think of putting all those fine grained authorization conditions inside actual service or page code or in a wrapper code and additionally use RBAC to achieve the same. But since, the rules we discuss may vary as per business needs or due to some other reasons. In that case it would be cumbersome and painful to change and deploy the code whenever change is required.

In order to avoid that there is an open standard XACML (eXtensible Access Control Markup Language) which is robust and flexible enough to design these policies independently. There are products (open source as well as enterprise) available that support XACML components  (About XACML in next post).


5 thoughts on “Granularity in authorization: Fine grained vs. coarse grained authorization

  1. I do accept as true with all the concepts you have presented for your post. They are really convincing and can definitely work. Still, the posts are too short for starters. May just you please extend them a bit from next time? Thank you for the post.

  2. My brother suggested I might like this web site. He was totally right. This post actually made my day. You cann’t imagine just how much time I had spent for this information! Thanks!

  3. Good day very cool blog!! Man .. Excellent .. Wonderful .. I’ll bookmark your web site and take the feeds also¡KI am satisfied to find a lot of helpful info right here in the submit, we need develop extra strategies on this regard, thank you for sharing. . . . . .

  4. ABAC policy evaluation at time of access works well enough for transactional access (user wants to access single reource = permit/deny) but breaks down (for me anyway) in the case where the user wants a list of resources she has access to. This involves some gymnastics of translating policy “conditions” into SQL, which means tightly coupling policies and code and breaking service encapsulation (exposing data schema). For me, this nullifies its value.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s