Return-Path: Delivered-To: apmail-cocoon-cvs-archive@www.apache.org Received: (qmail 9772 invoked from network); 18 Nov 2005 04:22:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 Nov 2005 04:22:30 -0000 Received: (qmail 20013 invoked by uid 500); 18 Nov 2005 04:17:55 -0000 Delivered-To: apmail-cocoon-cvs-archive@cocoon.apache.org Received: (qmail 18703 invoked by uid 500); 18 Nov 2005 04:17:10 -0000 Mailing-List: contact cvs-help@cocoon.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@cocoon.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list cvs@cocoon.apache.org Received: (qmail 18269 invoked by uid 99); 18 Nov 2005 04:15:52 -0000 X-ASF-Spam-Status: No, hits=-9.4 required=10.0 tests=ALL_TRUSTED,NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 17 Nov 2005 20:15:15 -0800 Received: (qmail 7322 invoked by uid 65534); 18 Nov 2005 04:14:55 -0000 Message-ID: <20051118041455.7320.qmail@minotaur.apache.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r345438 [12/286] - in /cocoon/site/site/2.1: ./ developing/ developing/portal/ developing/portal/coplets/ developing/webapps/ developing/webapps/authentication/ faq/ howto/ installing/ plan/ plan/documentation/ plan/otherplanning/ plan/over... Date: Fri, 18 Nov 2005 04:13:22 -0000 To: cvs@cocoon.apache.org From: crossley@apache.org X-Mailer: svnmailer-1.0.5 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Added: cocoon/site/site/2.1/developing/portal/authentication.html URL: http://svn.apache.org/viewcvs/cocoon/site/site/2.1/developing/portal/authentication.html?rev=345438&view=auto ============================================================================== --- cocoon/site/site/2.1/developing/portal/authentication.html (added) +++ cocoon/site/site/2.1/developing/portal/authentication.html Thu Nov 17 20:00:02 2005 @@ -0,0 +1,1347 @@ + + + + + + + +Authentication Framework + + + + + + + + + +
+ + + +
+ + + + + + + + + + + + +
+
+
+
+ +
+ + +
+ +
+ +   +
+ + + + + +
+

Authentication Framework

+ +

Introduction

+
+

One central point in building a web application is authentication and +authorization. The Cocoon authentication framework is a flexible module for +authentication, authorization and user management. A user can be legitimated +using any information available via any source, e.g. an existing database, LDAP +or the file system. With this mechanism it is very easy to use an exisiting user +management/authentication system within Cocoon.

+

The basic concept of the authentication framework is to protect documents +generated by Cocoon. By document we refer to the result of a request to Cocoon, +this can either be the result of a pipeline or of a reader defined in the +sitemap.

+

A document is protected by an authentication handler. A document is +associated with a defined handler to provide the protection. A user's request +for a document will only succeed if the handler signals that the user passes +authentication.

+

A handler can be used to protect several documents in the same way. If a user +is authenticated he can access all these documents. It is possible to use +different handlers, to protect documents in different ways.

+

The use of the authentication framework and its components is described in +the following sections.

+
+
Note
+
As you will see, the user management of the authentication +framework is very flexible.
+You can design your application without taking into account which backend is +used for the
+user management. The backend can be the file-system, a SQL database, an XML +database, a LDAP directory or
+just about anything. You can connect to any system simply by developing the +authentication resource.
+Another advantage is the flexible switching between user databases. For example, +you can use the file-system for
+the development process and later on, switch to a LDAP system on the production +system. This is done by changing
+the authentication resource. If you test this resource on your +production system, you don't have to test your whole application again.
+(Although in general this might be a good idea...).
+
+
+ +

Sitemap Components

+
+

The Authentication Framework adds some actions to the sitemap: the +auth-protect action, the auth-login action, the +auth-logout action and the auth-loggedIn action. The +authentication-manager gets the configuration for the authentication +framework and the actions control the pipelines. The auth-login and the +auth-logout action control the authentication whereas the +auth-loggedIn action controls the application flow.

+

+

+
+ +

Protecting Documents

+
+

One feature of the framework is the user authentication. A document can be +accessible for everyone or it can be protected using this framework. The process +of requesting a document can be described as follows:

+
    + +
  1. The user requests a document (original document).
  2. + +
  3. The authentication framework checks if this document is protected. If no +protection is specified, the response to the request is the original document. +
  4. + +
  5. If the document is protected, the framework checks, if the user is +authenticated to view it.
  6. + +
  7. If the user is authenticated, the response is the original document. If not, +the framework redirects to a special redirect-to document. This redirect-to +document is freely configurable and could, for example, contain information +about the unauthorized access and a login form.
  8. + +
  9. Using the login form an authentication resource can be called with the +corresponding user information (e.g. user id and password). This authentication +resource uses the framework for the authentication process.
  10. + +
  11. In case of a successful authentication the framework can redirect to the +original document (or to any configured start document).
  12. + +
  13. If the authentication fails another document is invoked by the framework +displaying information to the user.
  14. + +
+

This process is only one example for a use-case of the framework. It can be +configured for any authentication scheme. All resources are freely configurable. +

+ +
+
+ +
 
+
+ + + Propchange: cocoon/site/site/2.1/developing/portal/authentication.html ------------------------------------------------------------------------------ svn:eol-style = native