Tweet

This is the second article in a three-part series on Web 2.0 access control.

In the first article we noted that while developers accept the benefits of adopting third-party solutions for common functions such as data storage, cryptography, numerical analysis, parsing, etc., we continue to develop ad hoc solutions for application access control. As a result, application-specific user accounts and passwords proliferate, each application reinvents how roles should be implemented 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 develop and maintain.

We described the concepts of user-centric identity and organization-centric authorization as foundations for "outsourcing" the access control problem.

User-centric identity means identity that is verified using portable credentials provided by a trusted third party, just as passports and driver licenses are used to prove identity in non-digital transactions. Organization-centric authorization means that organizations will define roles, associate roles with users, and set access policies within an organization-wide authorization framework that is external to its applications. Authorization 2.0 applications will understand Identity 2.0 and will exploit these external authorization frameworks to drive their access control logic.

In this article we recommend a set of best practices for developers that should result in applications that are easier for organizations to integrate into their existing IT environment, and that will allow developers to write less code and produce more maintainable software. Following these practices is a first step on the road to realizing the benefits of Identity 2.0 and Authorization 2.0.

Web Access Control Best Practices

Best Practice #1: Refine the Requirement
Ok, so you need digital identity. What are you going to do with it? If a driver’s license or passport is going to be issued to an individual based on his or her digital identity, that identity had better be very good. Or better yet, don’t do it all? But perhaps it’s sufficient to tie an individual to an email address or a URL. My favorite provider of SSL certificates uses a novel combination of the email address of the domain admin contact and an automated dial-back to a user-provided phone number. During the call the user must use touch-tone to enter a 4-digit key displayed on the registration screen. It’s not bullet-proof, but it’s not bad. The point is, understand the risk and design appropriately.

Best Practice #2: Outsource Public User Account Registration
Many applications don’t need user identity, they need user account identity: a persistent unique identifier “owned” by the user with which the application can associate state, history and user preferences. If you simply need to associate a user with a password-protected user account don’t build yet another user account registration system; instead spend your effort integrating support for one of the community open identity systems like iNames, OpenID, or LID: leverage their registration systems. There is a variety of open source libraries available for each and interoperability is not difficult to achieve. By supporting open identity your application becomes part of an ad hoc federated web within which users can create and reuse open identity accounts and enjoy the convenience of single sign-on.

Best Practice #3: Leverage Local Authentication Technologies
Let’s face it: the vast majority of organizations continue to rely on simple username-password authentication. Whether an organization uses Microsoft Active Directory, Open LDAP, *nix /etc/password or RADIUS, and whether it partitions desktop and Web user accounts, it makes sense to allow organization to use their existing authentication technologies. Don’t hardwire your own form-based authentication. Instead define a simple Web service interface that can easily be implemented by organization admin staff on top of existing local authentication. Provide hooks to point your application at the local authentication Web service. Do the same for local roles. These simple architectural decisions will make it easier to integrate your application in the diverse IT environments of your users.

Best Practice #4: Resist Native HTTP Authentication
HTTP Basic and Digest Authentication ([url=http://www.ietf.org/rfc/rfc2617.txt]RFC
2617[/url]) are universally supported in browsers and HTTP client libraries. Server platforms of all stripes provide simple configuration mechanisms to trigger a username/password prompt. Why shouldn’t developers take advantage of a standards-based mechanism for authentication that comes for free?

The first reason is that HTTP auth is server-centric. The RFC requires browsers to re-prompt the user, regardless of REALM, if the user navigates to a protected space on a different server. Therefore organizations that operate multiple Web servers on different hosts or using different virtual server names (a common practice) cannot achieve browser-based user-centric authentication using HTTP auth. The second reason is a usability argument: common browsers provide no effective mechanism to terminate authentication. Once a user has successfully authenticated, browsers continue to send username/password for matching resources until the user exits the browser.

Yes, it’s easy and universally available but, for the benefit of mankind, please resist the temptation. When it comes to authentication, think globally and act locally.

Best Practice #5: Implement Data-driven Access Control
It’s common to see application code littered with access control conditions like the following:

>If the current user is the administrator, do the following, or
>If the current user is allowed to perform an update operation, then enable these menu items, or
>If the current user has not acknowledged the disclaimer notice, redirect to the disclaimer form, etc.

This is the hallmark of application-centric authorization. The application defines what it means to be an administrator, to be allowed to perform an update, or to acknowledge a notice. In organization-centric authorization, access control logic is expressed outside of the application. Organization-centric authorization is data-driven.

Data-driven access control:

>isolates access control policy from code: changes to a set of access control rules automatically apply to all uses of those rules throughout an application or set of applications; code does not need to be modified if the policy is changed.
>is easier to understand and express than code that implements the same policy, decreasing the chance of error
>is managed by organization systems staff not the application programmer
>is platform independent: access control rules can be stored remotely from applications that use them, and potentially can be evaluated remotely,
>increases sharing and reuse: rules are written once but may be used in different situations by different applications
>reduces application complexity: access control logic is abstracted, code is simplified and programming time and effort are reduced

When adopting data-driven access control you will need to select a third-party access control system to do the heavy-lifting. Among other things, your choice will dictate the language in which access control policies will be expressed. A detailed discussion is outside the scope of this short article but, in choosing, you should consider such things as the performance of the rule evaluation engine, the expressive power of the access control language, and the simplicity and clarity of expressing common access control conditions like those in the first paragraph of this section.

In the standards arena, XACML-based systems are an option. In the Open Source category check out Sun's implementation . Also, the Internet2 folks appear to have
OpenXACML in the pipe. But be warned: this stuff is not for the faint of heart.

In the final article in the series we illustrate through some simple examplesa lightweight approach to data-driven access control using DACS – the Distributed Access Control System.

Best Practice #6:Leverage the Apache Web Server
A data-driven approach based on Apache+DACS adds a high performance, universal access control tier to the application stack. DACS authentication drivers for many common authentication technologies become immediately available to the application. Access control rules can be written requiring a user to authenticate before access to the application is granted, or more specific rules may require that an authenticated user possess an application-specific role. All of this can be achieved without writing a line of custom access control code, and with performance that is virtually indistinguishable from raw Apache.

Best Practice #7:Ensure your Application is Proxy-friendly
This really follows from Best Practice #6: if Apache+DACS provides the access control tier, applications running in a servlet container often will be deployed via proxy. Common tricks to determine the application base programmatically simply don’t work in a proxy environment. This can break application code that constructs URLs for embedding in generated content, for driving browser navigation or for redirects. To guarantee success, applications should be designed to obtain their public-facing URL from a configuration file. Access control rules must be expressed with respect to the public-facing URL.

Conclusion

In this article we outlined a set of best practices for access control in Web 2.0. In the next and final article in the series we look at a dummy PHP application called FooApp and how the concepts desribed in this series are realized in its design.

References

DACS – the Distributed Access Control System: a lightweight distributed authentication and authorization framework for the federated Web.

Identity 2.0 Presentation, Dick Hardt, Sxip Identity.

OpenID a decentralized identity based on “ownership” of a URL at an OpenID-enabled server.


OpenSAML a set of open source Java and C++ libraries implementing the SAML 1.1 Specification. OpenSAML has been produced by Internet2 members as part of their work on the Shibboleth Project.

xdi.org: an international non-profit public trust organization governing open public
XRI (Extensible Resource Identifier) and XDI (XRI Data Interchange) infrastructure.

Rick Morrison is President of Metalogic Software Corporation, a software development firm specializing in federated applications and services for Web 2.0. With DSS - Distributed Systems Software, Metalogic is co-developer of DACS - the Distributed Access Control System (http://dacs.dss.ca). Rick has over fifteen years experience developing innovative software for the Web in commercial, government and research settings. Contact Rick at: http://2idi.com/contact/@metalogicsoftware.

No comments yet. Be the first one to comment.