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
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).