Apache » Cocoon »

Cocoon Authentication 1.0 homepage

Cocoon Authentication 1.0

Introduction

A central point in building a web application is authentication and authorization. The servlet specification provides already a mechanism for both, authentication and authorization: The authentication is done by specifying a authentication method and by defining URL spaces that require an authentication. A user can be in several roles and this role information can be used for authorization. The "real" authentication, how to query the used user database, is out of the scope of the specification. This is done by so called realms that are either provided by the used servlet engine or can be developed. Switching from a database to let's say a LDAP system requires no changes to your web application, you just have to change the used realm.

The authentication mechanism provided by Cocoon Auth is basically very similar but extends this mechanism in many ways. The mechanism described by the servlet specification has two major disadvantages for a Cocoon web application: the configuration of the protected areas is in the web.xml which is "outside" of Cocoon. If you look at the usual Cocoon configuration, the sitemaps, you will not see that your pipelines are only accessible for authenticated users. Furthermore, internal pipeline calls are not protected by the servlet engine as they happen inside Cocoon. In addition, the realms are proprietary, they tie your application to the used servlet engine/application server.

Cocoon Auth introduces the notion of an application: this is a web application built with Cocoon that shares the same user base. An application can have an own configuration etc. For authentication, so called security handlers are used (similar to realms). A security handler provides a flexible but decoupled way of authenticating users. For the application it doesn't matter if the users are stored in a database, in a LDAP system or in some obscure files in the file system.

Changing the user database can be done by just changing the used security handler. This allows to use a different authentication mechanism during development than in production. All you have to do is change the configuration and the application uses the different system.

Note: Cocoon Auth is very similar in its concepts to the authentication-fw block of Cocoon. To be honest, it is rewrite of the authentication-fw block, that tries to avoid all short-commings and problems of that block. One major drawback of the authentication-fw block is that the original idea has been to always use a pipeline to authenticate users. Later on, different ways have been "added". When the authentication-fw block was originally developed, Cocoon flow wasn't even in discussion, so the integration between those two techniques is not as good as it could be. There are more things in the authentication-fw block that are not as good as they could be, for example the authentication-fw block does not allow session replication (if you need that); Cocoon Auth tries to avoid all of these problems and is additionally focused to take advantage of the latest in Cocoon development.
Errors and Improvements? If you see any errors or potential improvements in this document please help us: View, Edit or comment on the latest development version (registration required).