Google Site Search

Google
 

Friday, May 17, 2013

Authorization (Access Control) Best Practices

After the recent wrestling match in the blogosphere that included vendors and analysts on XACML, I want to provide some best practices for access control/authorization.

The wrestling match is covered in my earlier post.

Let me insert my favorite punch line before I mention the best practices.

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


References

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

OASIS Cloud Authorization TC




Please do not forget to view the presentation above. :)


1 comment:

Unknown said...

Nice article,

Would like to know your inputs on how to handle some of the use cases that a typical product requires.
1) UI security provision : Controls can be enabled or disabled depending on Entitlements
2) Rest Resources security : typical read/write resources for entities.
3) With in read depending on the entitlements data security has to be nested.
4) Similar for updates a generic resource for updating may be given access, but requirement span out to enable selective updates on few attributes of the resources.

On top of this, a typical software product doesn't have security requirements defined while(ui page or rest resource or entity crud operations) are being written. So only attaching entitlements to the code bit(mentioned above) may not be sufficient.
It would be good to know your inputs on use cases like above
Solutions could be : using resource level security with typical saml2 entitlements and additional nested security of data points using something like drools or seam. Is that feasible and a good idea ?