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 CoWarp 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.

CoWarp introduces the notion of an application: this is a web application build 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.

CoWarp is very similar in its concepts to the authentication-fw block of Cocoon. To be honest, it is a totally 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 was to always use a pipeline to authenticate users. Later on different ways have been "added". When the authentication-fw block was 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; CoWarp tries to avoid all of them and is additionally focused to take advantage of newer Cocoon versions like Cocoon 2.2.