So - you are wrapping up development of yet another Web app. The database is in place, CRUD functions are working, user interface and reports have been signed off. Now your thoughts are turning to access control. Just enough time to splice in that trusty user authentication and roles module, make a few tweaks and move on to the next project. Wait! Do you really want to contribute yet another authorization stovepipe to the growing forest? We all curse the proliferation of authentication and authorization “solutions” on the Web. Yet we continue to treat access control as an after thought.

Developers accept the benefits of adopting third-party solutions for common functions such as data storage, cryptography, numerical analysis, parsing, etc., yet continue to roll their own application access control solutions. Why? The disadvantages of RYO are obvious: application-specific user accounts and passwords proliferate, each application reinvents how roles should be implemented — perhaps even a language for specifying access constraints — and, if integration with an external authentication framework is required, each application must implement interfaces to the drivers. This is irritating to our users, a headache for those who administer the applications, and costly to maintain.

In this article we develop a set of Web 2.0 best practices for “outsourcing” the access control problem. Following these practices produces applications that readily integrate into an organization’s existing access control infrastructure, and simplifies application development and maintenance.

Examples are based on DACS (http://dacs.dss.ca) – the Distributed Access Control System. DACS is a mature, lightweight open source (http://sourceforge.net/projects/dacs) system for single sign-on and data-driven access control.

Download pdf Web 2.0 Access Control Best Practices – Part 1