A document has been updated: http://cocoon.zones.apache.org/daisy/documentation/1236.html
Document ID: 1236 Branch: main Language: default Name: Introduction (unchanged) Document Type: Cocoon Document (unchanged) Updated on: 1/13/07 8:44:39 PM Updated by: Carsten Ziegeler A new version has been created, state: publish Parts ===== Content ------- This part has been updated. Mime type: text/xml (unchanged) File name: (unchanged) Size: 3157 bytes (previous version: 37 bytes) Content diff: --- <html><body><p>TODO</p></body></html> +++ <html> +++ <body> +++ +++ <p>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.</p> +++ +++ <p>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 <tt>web.xml</tt> 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.</p> +++ +++ <p>Cocoon Auth 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.</p> +++ +++ <p>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.</p> +++ +++ <p class="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.</p> +++ +++ </body> +++ </html>
