Over a million developers have joined DZone.

Authorization (Access Control) Best Practices

DZone's Guide to

Authorization (Access Control) Best Practices

· DevOps Zone ·
Free Resource

Learn how integrating security into DevOps to deliver "DevSecOps" requires changing mindsets, processes and technology.

I use the following statement when I describe the differences between authentication and authorization.

Authentication is finite while Authorization is infinite.

Best practices for access control:

1. Know that you will need access control/authorization.

Too many times architects spend majority of their system security design time on authentication and federated identity. This leads to limited time provided to authorization. Compared to authentication, authorization can get very complex over time. 

2. Externalize the access control policy processing

You are headed toward disaster if your access control processing is embedded in your application. This is because access control requirements are never complete during the first phase of application development. Authorization rules or requirements change over the application lifecycle as business needs or environment change.  If the access control processing is not decoupled from the application, you will face hardship. Lots of band-aid will be applied to the application code to meet the changing/ever-growing authorization requirements.

3. Understand the difference between coarse grained and fine grained authorization

Google/Bing will help you understand the difference. Wikipedia will definitely help you here. Application designers tend to create a model of authorization (for simplicity) during initial design. Almost always, this model tends to be a simple coarse grained authorization model. The challenge is that the read world authorization needs for your application is not set in stone. It is an ever changing phenomenon that will just pull your model in all directions.

4. Design for coarse grained authorization but keep the design flexible for fine grained authorization

This goes in line with item 2 where the access control policy has to be separated or decoupled from your application.  If your initial design for the access control system or library is designed for coarse grained authorization, because of the low coupling, it becomes easier to incorporate fine grained authorization logic over time.

5. Know the difference between Access Control Lists and Access Control standards

Access Control Lists (ACL) are pretty popular among system designers. The challenge is that they are proprietary and not usable across applications or domains. You may earn your bonus or accolades using ACLs in your application. Over time, they tend to become restrictive due to changing requirements.
There are 2 prominent access control standards that I list here:
a) IETF OAuth2: this is a REST style Internet Scale lightweight resource authorization framework.
b) OASIS XACML: standard for fine grained authorization. Has an access control architecture namely PEP (Policy Enforcement Point), PDP (Policy Decision Point), PIP (Policy Information Point) and PAP (Policy Administration Point).
Fig: Typical XACML Fine Grained Access Control Architecture

6. Adopt Rule Based Access Control : view Access Control as Rules and Attributes

Access Control should be viewed as rules on various entities (and their attributes) involved in the authorization check.
I am not forcing you to use XACML.  But I would certainly encourage you to design your access control system in terms of rules and attributes.  Have a look at my article on  Access Control Strategies. It is critical that you design your access control system as rules and attributes.
Hey, Drools based access control system is certainly not bad as long as you decouple the access control system. It is a trade off between proprietary rigid ACLs and flexible fine grained XACML. You can manage your Drools Rules via Guvnor.

7. Adopt REST Style Architecture when your situation demands scale and thus REST authorization standards 

With the growing demand for web based services and APIs and the proliferation of mobile devices in the world, it has become essential to incorporate REST style architecture to your system design.

It is essential for you to use OAuth2 standard for REST authorization. While OAuth2 takes care of defining the tokens and some rules for authorization (scope of authorization and actor/resource), it may still be essential for system architects to incorporate fine grained authorization.  Certainly give a look at the REST Profile of XACML v3. There is also JSON binding available.

8. Understand the difference between Enforcement versus Entitlement model

Prominent access control strategies and standards involve the Enforcement model. The access control system is trying to enforce access to a resource. This leads to a Yes/No type question.  The enforcement model does not scale in a cloud or a resource constrained environment. 

Entitlement model is where in the access control system does not perform enforcement or access checks. Rather it answers questions such as "What permissions does this user have?". The question seeker will then use the returned answer to perform local enforcement.

Cloud Enforcement vs Entitlement Model


PicketBox XACML: Open Source free implementation of OASIS XACML v2.

OASIS Cloud Authorization TC

Additional Information

This article appeared as a blog post in May 2013 at http://anil-identity.blogspot.com/2013/05/access-control-best-practices.html

Slideshare: http://www.slideshare.net/anilsaldhana/authorization-bestpractices

Thanks for reading this article. My blog is at http://anil-identity.blogspot.com

Learn how enterprises are using tools to automate security in their DevOps toolchain with these DevSecOps Reference Architectures.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}