cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: [Fwd: Re: Cocoon - modified authentication.xml]
Date Fri, 12 Aug 2005 09:08:23 GMT
Hi Ron,

thanks for your updates. I just applied them to subversion.

If you have any questions or want to provide more updates, additional
docs etc., please direct them to the cocoon developer list
(dev@cocoon.apache.org)

Thanks
Carsten

Ron Wheeler schrieb:
> This is a post that I sent to Carsten Ziegeler. I should probably been 
> directed to this list.
> I includes my modified version of the documentation fragment 
> authentication.xml
> 
> I am a newbee at Cocoon so my changes need to be carefully checked.
> I hope that my background and inexperience will result in a document 
> that is clearer to the intended audience.
> 
> I am working through the tutorial and revising the 
> tutorial-develop-webapp.xml as I test the tutorial steps.
> I have found some pretty big holes that makes me think that the tutorial 
> depends on some files and file placemets that have changed in the 2.1.7 
> distribution. I am doing my best to find the missing pieces and guess 
> what the filenames should be for the files that are being created.
> 
> 
> I will forward a draft as soon as I get to the end. You might also get 
> some questions before that but so far I have been able to figure out 
> each problem as it came up.
> 
> Ron
> 
> 
> -------- Original Message --------
> Subject: 	Re: Cocoon - modified authentication.xml
> Date: 	Fri, 05 Aug 2005 09:58:14 -0400
> From: 	Ron Wheeler <rwheeler@artifact-software.com>
> Reply-To: 	rwheeler@artifact-software.com
> Organization: 	Artifact
> To: 	cziegeler@s-und-n.de
> References: 
> <OF2AEC342E.9B50FCC6-ONC1257054.0034C402-C1257054.0036ACFB@sundn.de>
> 
> 
> 
> around 507
>      <s2 title="Getting Roles">
> This resource gets the
>           parameter "type" with the value "roles" and should deliver an 
> XML schema with
>           the root node "roles" and for each role a sub-element "role" 
> with a text child
>           of the rolename:</p>
> 
> Doesn't it return an XML datastructure rather than a schema.
> 
> This brings up the question about various schemas for the XML 
> datastructures  for the user defined resources in this section.
> Are there schemas that describe the structures that the user defined 
> resources must pass back to the framework.
> 
> 
> Ron
> 
> 
> cziegeler@s-und-n.de wrote:
> 
> 
>>Hi Ron,
>>
>>many thanks for your work, really appreciated! Obviously, I'm not a native
>>speaker therefore I'm really happy whenever someone corrects my mistakes!
>>Could you please send your final version to the developer mailing list
>>(dev@cocoon.apache.org). This is the official way and we want to ensure
>>that all contributions go this way, so everyone can keep track of them. I
>>will happily pick it up from there and apply it asap.
>>
>>Now, for your questions:
>>
>>Unclear concepts:
>>
>> 
>>
>>
>>>"own parameter"??? around line 203 -  For each piece of information an
>>>own parameter is created.
>>>   
>>>
>>
>>Perhaps a "separate parameter" is better? Actually, you have to create a
>>parameter
>>for each and every piece of information you need for authentication.
>>Usually these
>>are the request parameters comming from the form. So if you have a form
>>with user name
>>and password, you have to create two parameters here. But you could also
>>add some other
>>information as the ip address of the client etc.
>>
>>
>> 
>>
>>
>>>around line367   Not sure what this means in this context  " <p>The tag
>>>is removed from the resource.</p>"
>>>   
>>>
>>
>>The XML containing the tag - or element - (session:setxml) is passed (as
>>SAX events) through the pipeline.
>>When the transformer receives this tag the transformer processed the tag
>>(or command) in the
>>way described in the paragraph lin 367. The tag is then removed by the
>>transformer
>>which means the transformer does not pass this tag to the next component in
>>the pipeline.
>>
>> 
>>
>>
>>>398 "sides" - do you mean "sites"
>>>   
>>>
>>
>>Yes.
>>
>> 
>>
>>
>>>563  This makes no reference to changing anything and only talks about
>>>sending information except in the name. What does it do? It talks about
>>>getting things and things being "sent".
>>>   <s2 title="Changing information of a user">
>>>      <p>The <em>change-user</em> resources changes information of a
>>>   
>>>
>>
>>user.
>> 
>>
>>
>>>        It gets the parameters "type" with the value "user", "role"
>>>with the rolename
>>>        and "ID" with the ID of the user. In addition all application
>>>specific
>>>        information of this user is sent as parameters.</p>
>>>   </s2>
>>>   
>>>
>>
>>Ah ok, this chapter describes resources (which actually are pipelines) that
>>are invoked by
>>the authentication framework. So, when the user changes the information,
>>the
>>authentication framework calls this "change-user" resource (or pipeline)
>>and
>>adds the parameters (type, role and ID). It's up to the developer to
>>develop this
>>resource (pipeline) and do whatever appropriate. For example, updating the
>>database
>>with the new information.
>>
>> 
>>
>>
>>>569 changed "should" to "will" but it has the same problem as "Changing
>>>information of a user" in that it talks about getting things not
>>>deleting except in the title and first sentence. What does it do? How do
>>>you invoke it?
>>>  <s2 title="Delete a user">
>>>      <p>The <em>delete-user</em> resource will delete a user. It gets
>>>   
>>>
>>
>>the
>> 
>>
>>
>>>        parameters "type" with the value "user", "role" with the
>>>rolename and "ID" with
>>>        the ID of the user.</p>
>>>   </s2>
>>>   
>>>
>>
>>Yes, actually, it's the same. So, it's the task of the web developer to
>>define all these pipelines
>>and then either the authentication framework or youself call this pipeline.
>>For example, if you provide your own delete user functionality, you can
>>then
>>call this resource, provide the required parameters and it will delete the
>>user.
>>
>>Now, actually these features, like change user, delete user etc., are
>>currently not really used. They are there to provide "standardized hooks"
>>for your own application to perform these tasks if required.
>>I hope this makes things a little bit more clear. If you need more
>>information, just ask :)
>>
>>
>>Thanks for your work!
>>
>>Have a nice weekend
>>Carsten
>>Freundliche Grüße / With kind regards
>>Carsten Ziegeler
>>
>>S&N AG
>>Klingenderstrasse 5
>>D 33100 Paderborn
>>
>>voice  +49 5251/1581-49
>>fax      +49 5251/1581-71
>>eMail  cziegeler@s-und-n.de
>>web   http://www.s-und-n.de
>>
>>
>>
>>                                                                                                                                                     
>>                     Ron Wheeler                                                                                                                     
>>                     <rwheeler@artifact-so         An:      cziegeler@s-und-n.de                                                                     
>>                     ftware.com>                   Kopie:                                                                                            
>>                                                   Thema:   Cocoon - modified authentication.xml                                                     
>>                     01.08.2005 16:09                                                                                                                
>>                     Bitte antworten an                                                                                                              
>>                     rwheeler                                                                                                                        
>>                                                                                                                                                     
>>                                                                                                                                                     
>>
>>
>>
>>
>>I started reading the authentication documentation and came across a few
>>things that made it harder to read than it needed to be so I did a
>>cleanup on the English.
>>
>>I have attached a modified version of the authentication.xml file.
>>I tried to make it more readable and I fixed some spelling and grammer
>>problems.
>>
>>I found the following bits and pieces that where not suffieciently clear
>>to me that I felt comfortable changing them.
>>
>>If you can tell me what you meant here, I will try to finish my editing.
>>
>>I am not a Cocoon expert so you may want to check what I have done but I
>>was pretty careful not to change things where I was not able to figure
>>out the original authors's intent.
>>
>>I hope that this contributes in a small way to the success of Cocoon.
>>
>>Ron
>>
>>
>>Unclear concepts:
>>
>>"own parameter"??? around line 203 -  For each piece of information an
>>own parameter is created.
>>
>>around line367   Not sure what this means in this context  " <p>The tag
>>is removed from the resource.</p>"
>>
>>398 "sides" - do you mean "sites"
>>
>>563  This makes no reference to changing anything and only talks about
>>sending information except in the name. What does it do? It talks about
>>getting things and things being "sent".
>>    <s2 title="Changing information of a user">
>>       <p>The <em>change-user</em> resources changes information of a
>>user.
>>         It gets the parameters "type" with the value "user", "role"
>>with the rolename
>>         and "ID" with the ID of the user. In addition all application
>>specific
>>         information of this user is sent as parameters.</p>
>>    </s2>
>>
>>569 changed "should" to "will" but it has the same problem as "Changing
>>information of a user" in that it talks about getting things not
>>deleting except in the title and first sentence. What does it do? How do
>>you invoke it?
>>    <s2 title="Delete a user">
>>       <p>The <em>delete-user</em> resource will delete a user. It gets
>>the
>>         parameters "type" with the value "user", "role" with the
>>rolename and "ID" with
>>         the ID of the user.</p>
>>    </s2>
>>
>><?xml version="1.0" encoding="UTF-8"?>
>><!--
>> Copyright 1999-2004 The Apache Software Foundation
>>
>> Licensed under
>>the Apache License, Version 2.0 (the "License");
>> you may not use this file
>>except in compliance with the License.
>> You may obtain a copy of the
>>License at
>>
>>     http://www.apache.org/licenses/LICENSE-2.0
>>
>> Unless required
>>by applicable law or agreed to in writing, software
>> distributed under the
>>License is distributed on an "AS IS" BASIS,
>> WITHOUT WARRANTIES OR
>>CONDITIONS OF ANY KIND, either express or implied.
>> See the License for the
>>specific language governing permissions and
>> limitations under the License.
>>-->
>><!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.0//EN"
>>"document-v10.dtd">
>><document>
>>   <header>
>>       <title>Authentication Framework</title>
>>       <authors>
>>           <person name="Carsten Ziegeler" email="cziegeler@s-und-n.de"/>
>>       </authors>
>>   </header>
>>   <body>
>> <s1 title="Introduction">
>>    <p>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.</p>
>>    <p>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.</p>
>>    <p>A document is protected by a authentication handler. A document is
>>associated with a
>>      defined handler to provides the protection. A user's request for a
>>document will only succeed if the handler
>>               signals that the user passes authentication.</p>
>>    <p>It is possible to use different handlers to protect different
>>documents in different ways.</p>
>>    <p>The use of the authentication framework and its components is
>>described in the following
>>       chapters.</p>
>>    <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 <em>authentication resource</em>.
>>               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 <em>authentication resource</em>. 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...).
>>    </note>
>> </s1>
>> <s1 title="Sitemap-Components">
>>    <p>The authentication Framework adds some actions to the sitemap: the
>><em>auth-protect</em>
>>       action, the <em>auth-login</em> action, the <em>auth-logout</em>
>>action
>>       and the <em>auth-loggedIn</em> action. The
>><em>authentication-manager</em> gets
>>       the configuration for the authentication framework and the actions
>>controle the pipelines.
>>       The <em>auth-login</em> and the <em>auth-logout</em> action control
>>the
>>       authentication whereas the <em>auth-loggedIn</em> action controls
>>the application
>>       flow.</p>
>>   <figure src="images/authentication-fw.jpg" alt="Overview"
>>             width="480" height="360"/>
>> </s1>
>> <s1 title="Protecting Documents">
>>    <p>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:</p>
>>    <ol>
>>       <li>The user requests a document (original document).
>>       </li>
>>       <li>The authentication framework checks if this document is
>>protected. If no protection
>>         is specified, the response to the request is the original
>>document.
>>       </li>
>>       <li>If the document is protected, the framework checks, if the user
>>is
>>         authenticated to view it.
>>       </li>
>>       <li>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.
>>       </li>
>>       <li>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.
>>       </li>
>>       <li>In case of a successful authentication the framework can
>>redirect to
>>         the original document (or to any configured start document).
>>       </li>
>>       <li>If the authentication fails another document is invoked by
>>         the framework displaying information to the user.
>>       </li>
>>    </ol>
>>    <p>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.</p>
>>    <s2 title="The Authentication handler">
>>       <p>The basic object for authentication is the authentication
>>handler.
>>                          It controlles the access to the documents. Each
>>document in the
>>         sitemap can be related to exactly one authentication handler. All
>>documents belonging
>>         to the same handler are protected in the same way. If a user has
>>access to the
>>         handler, the user has the same access rights for all documents
>>associated with this
>>         handler.</p>
>>       <p>Each authentication handler needs the following mandatory
>>         configuration:</p>
>>       <ul>
>>         <li>A unique name.
>>         </li>
>>         <li>The authentication resource: A Cocoon pipeline used to
>>authenticate a user.
>>             (We will see later on, that there are more possibilities than
>>using a pipeline).
>>         </li>
>>         <li>The redirect-to document: This document is displayed when a
>>user fails authentication.
>>         </li>
>>       </ul>
>>    </s2>
>>    <s2 title="The Configuration of a Handler">
>>       <p>So let's have a look at the configuration. A handler is
>>configured in the sitemap using a <em>component configuration<em> for the
>>authentication manager.
>>                        This configuration is specified in the
>><em>map:pipelines</em> section of a sitemap:</p>
>><source>
>>&lt;map:sitemap&gt;
>>   ...component definitions...
>>
>>&lt;map:pipelines&gt;
>> &lt;map:component-configurations&gt;
>>   &lt;authentication-manager&gt;
>>     &lt;handlers&gt;
>>       &lt;handler name="portalhandler"&gt;
>>         &lt;redirect-to uri="cocoon:/sunspotdemoportal"/&gt;
>>         &lt;authentication uri="cocoon:raw:/sunrise-authuser"/&gt;
>>       &lt;/handler&gt;
>>     &lt;/handlers&gt;
>>   &lt;/authentication-manager&gt;
>> &lt;/map:component-configurations&gt;
>>&lt;map:pipeline&gt;
>>  ... document pipelines following here:
>></source>
>>       <p>Using a unique name for each handler (only alphabetical
>>characters
>>         and digits are allowed for the handler name), the framework
>>manages different
>>         handlers. So various parts of the sitemap can be protected in
>>different ways.
>>       </p>
>>       <p>A handler is inherited to a sub sitemap. Each sub sitemap can
>>define
>>          its own handlers. These handlers are only available to the sub
>>sitemap
>>          (and of course to its sub sitemaps). However, it is not possible
>>to
>>          redefine (overwrite) a previously defined handler in a sub
>>sitemap.</p>
>>    </s2>
>>    <s2 title="Protecting Documents">
>>       <p>A document is protected by associating it with a defined
>>handler.
>>       This is done by using the <em>auth-protect</em> action and the
>>handler parameter:</p>
>><source>&lt;map:match pattern="protectedresource"&gt;
>> &lt;map:act type="auth-protect"&gt;
>>   &lt;map:parameter name="handler" value="portalhandler"/&gt;
>>   &lt;map:generate src="source/resource.xml"/&gt;
>>   &lt;map:serialize type="xml"/&gt;
>> &lt;/map:act&gt;
>>&lt;/map:match&gt;</source>
>>       <p>If this document is requested, the action checks that the
>>defined handler successfully authenticates the user.
>>                        If not, the action automatically redirects to the
>><em>redirect-to</em> document
>>          configured in the handler. (In the example above this is the
>>pipeline defined by <em>cocoon:/sunspotdemoportal</em>.</p>
>>       <p>If the user is authenticated, the commands inside the
>><em>map:act</em> will be execute and
>>          the user gets the document itself.</p>
>>       <p>So, the <em>auth-protect</em> action must be included in the
>>pipeline of the
>>         document. It gets the handler information as a parameter. If the
>>pipeline does
>>         not use the <em>auth-protect</em> action or the parameter
>><em>handler</em> is missing,
>>         the document is accessible by any user.</p>
>>       <note>You will see learn later on how to efficiently protect
>>several documents with a handler.</note>
>>    </s2>
>>    <s2 title="The redirect-to document">
>>       <p>If the requested document is not accessible by the user, the
>>authentication framework
>>         redirects to the configured <em>redirect-to</em> document. This
>>document is a mandatory
>>         element of the authentication handler.</p>
>>       <p>This <em>redirect-to</em> document is an unprotected pipeline in
>>the
>>         sitemap. For tracking which document was originally requested by
>>the user,
>>         the <em>redirect-to</em> pipeline gets the request parameter
>><em>resource</em>
>>         with that value. In addition all parameters specified inside the
>><em>redirect-to</em>
>>         tag of the handler configuration are passed to the pipeline as
>>well.</p>
>>       <p>For example, the <em>redirect-to</em> document can contain a
>>form for the user
>>         authentication. This form should invoke the real authentication
>>process that is
>>         described below.</p>
>>    </s2>
>>    </s1>
>>    <s1 title="Authenticating a User">
>>       <p>Usually, the <em>redirect-to</em> document of a handler contains
>>a form for the user
>>          to authenticate. But of course, you are not limited to this. No
>>matter how the
>>          <em>redirect-to</em> document is constructed, there is somewhere
>>where the user has the abilitiy
>>          to authenticate, so in most cases the user has a form where he
>>can enter
>>          his information (e.g. user name and password). You have to write
>>a pipeline
>>          presenting this form to the user. When the form is submitted,
>>the authentication
>>          process has to be started inside the authentication framework.
>>As a submit
>>          of a form invokes a request to Cocoon, a pipeline in the sitemap
>>is triggered.
>>          We refer to this pipeline as a <em>login pipeline</em>.</p>
>>    <s2 title="The Login Process">
>>       <p>The authentication process is started by invoking the
>><em>auth-login</em> action.
>>         So, the <em>login pipeline</em> has to contain this action:</p>
>>       <source>&lt;map:match pattern="login"&gt;
>> &lt;map:act type="auth-login"&gt;
>>   &lt;map:parameter name="handler" value="portalhandler"/&gt;
>>   &lt;map:parameter name="parameter_userid"
>>value="{request-param:name}"/&gt;
>>   &lt;map:parameter name="parameter_password"
>>value="{request-param:password}"/&gt;
>>   &lt;map:redirect-to uri="authentication-successful"/&gt;
>> &lt;/map:act&gt;
>> &lt;!-- authentication failed: --&gt;
>> &lt;map:generate src="auth_failed.xml"/&gt;
>> &lt;map:transform src="tohtml.xsl"/&gt;
>> &lt;map:serialize/&gt;
>>&lt;/map:match&gt;</source>
>>       <p>The <em>auth-login</em> action uses the handler parameter to
>>call the
>>         <em>authentication resource</em> of this handler. This
>><em>authentication resource</em> needs to
>>         know the information provided by the user, e.g. in the form. For
>>each piece of information an own
>>         parameter is created. The name of this parameter has to start
>>with "parameter_".
>>         So in the example above, the <em>authentication resource</em>
>>gets two parameters: userid and password. As
>>         the values of these parameters were sent by a form they need to
>>be passed on
>>         to the <em>authentication resource</em>. If you use
>>"{request-param:...}" for the value of a
>>         parameter, the <em>auth-login</em> action will pass the actual
>>value of that request
>>         parameter to the <em>authentication resource</em> (by using the
>>input modules concept
>>         of Cocoon).</p>
>>       <note>You might be wondering why we explicitly pass the request
>>parameters on to the
>>         internal pipeline call. Note that the <em>authentication
>>resource</em> of the
>>         portalhandler is defined by <em>cocoon:raw</em>. By using this,
>>no request
>>         parameter of the original request is passed on to the internal
>>pipeline by
>>         default and therefore we have to define them explicitly. If you
>>use
>>         <em>cocoon:</em> then the parameters of the form are by default
>>passed on
>>         to the <em>authentication resource</em> and we could omit the
>>parameter definition
>>         from above. But we feel that it is safer to explicitly define
>>them.</note>
>>       <p>If the user is not already authenticated with this handler, the
>>framework calls
>>         the <em>authentication resource</em> and passes the parameters to
>>it. If this
>>         authentication is successful, the action returns a map and the
>>sitemap
>>         commands inside the <em>map:act</em> are executed. If not already
>>done, a session is created on
>>         the server as well.</p>
>>       <p>If the authentication fails, the action does not deliver a map
>>and
>>       therefore the commands inside the <em>map:act</em> are skipped. The
>>error
>>         information delivered by the <em>authentication resource</em> is
>>stored in the
>>         <em>temporary</em> context. So you can get the information using
>>either the
>>         <em>session transformer</em> or the <em>session-context input
>>module</em>.</p>
>>       <note>As you can see from the example above, you are not limited in
>>defining
>>         the information the user has to provide. This can be as many
>>fields as you need.</note>
>>    </s2>
>>    <s2 title="The authentication resource">
>>       <p>The last chapter described the authentication process but left
>>out
>>         details about the authentication itself. This chapter closes this
>>gap.</p>
>>       <p>The authentication can be done by different components:</p>
>>       <ul>
>>         <li>A sitemap resource (pipeline).
>>         </li>
>>         <li>A distant resource, e.g. requested via HTTP.
>>         </li>
>>         <li>A java class.
>>         </li>
>>       </ul>
>>       <p>The first two are actually similar as in both cases a URI is
>>called. So we
>>         will talk about them in the next chapter. Authentication using a
>>java class
>>         is the topic of the following chapter.</p>
>>       <s3 title="Using a URI as the authentication resource">
>>       <p>Using this flexible approach nearly any kind of authentication
>>is
>>         possible (e.g. database, LDAP). The <em>authentication
>>resource</em> is a
>>         mandatory configuration of the authentication handler:</p>
>>       <source>&lt;autentication-manager&gt;
>> &lt;handlers&gt;
>>   &lt;!-- Now follows the handlers configuration --&gt;
>>   &lt;handler name="portalhandler"&gt;
>>     &lt;!-- The login resource --&gt;
>>     &lt;redirect-to uri="cocoon:/sunspotdemoportal"/&gt;
>>     &lt;authentication uri="cocoon:raw:/sunrise-authuser"/&gt;
>>   &lt;/handler&gt;
>> &lt;/handlers&gt;
>>&lt;/autentication-manager&gt;</source>
>>       <p>If the <em>authentication resource</em> is a sitemap resource or
>>a remote
>>         resource, this resource is requested by the framework with the
>>given parameters from
>>         the <em>auth-login</em> action (see previous chapter). In
>>addition, all parameters inside
>>         the <em>authentication</em> tag of the handler configuration are
>>passed to the resource.
>>         The response of this resource must contain XML conforming to the
>>following scheme:</p>
>>       <source>&lt;authentication&gt;
>>   &lt;ID&gt;Unique ID of the user in the system&lt;/ID&gt;
>>   &lt;role&gt;rolename&lt;/role&gt; &lt;!-- optional --&gt;
>>   &lt;data&gt;
>>       Any additional optional information can be supplied here.
>>       This will be stored in the session for later retrieval
>>   &lt;/data&gt;
>>&lt;/authentication&gt;</source>
>>       <p>The XML is very simply, only the root element
>><em>authentication</em> and the <em>ID</em>
>>        element with a valid unique ID for the user in this handler is
>>required. Everything else is optional.
>>       </p>
>>       <p>The framework checks the response of the authentication resource
>>for the
>>         given scheme: the root node must be named <em>authentication</em>
>>and one child called
>>         <em>ID</em> must be present. In this case the authentication is
>>successfull and
>>         the framework creates an authentication session context and
>>stores the XML inside.</p>
>>       <p>The mandatory <em>ID</em> tag is
>>         an unique identification for the user inside the web application
>>or
>>         more precisly inside this handler. The <em>role</em> is optional
>>and can
>>                          be used for categorizing users and displaying
>>different functionality inside the Cocoon portal
>>         engine.</p>
>>       <note>The <em>role</em> element is optional; you can use your own
>>       categorization and exchange it with a <em>roles</em> element or a
>><em>group</em>
>>       element or leave it out, if you don't need it. In addition you can
>>add any
>>       other element there as well and access the information later
>>on.</note>
>>       <p>Using the <em>data</em> node, the <em>authentication
>>resource</em> can pass any
>>         information of the user to the session. You can retrieve the
>>         information as long as the session is valid.</p>
>>       <p>If the authentication is not successful, the resource must
>>create
>>         an XML with the root node <em>authentication</em>, without
>>         the <em>ID</em> tag. In addition a <em>data</em> node can be
>>added containing
>>         more information about the unsuccessful attempt. This data
>>         node is then stored into the <em>temporay</em> context (see
>>previous
>>         chapter).</p>
>>       <note>It is advisable to make an internal pipeline for the
>><em>authentication resource</em>.
>>          An internal pipeline is not directly accessible by a
>>user.</note>
>>       </s3>
>>       <s3 title="Using a Java class as the authentication resource">
>>       <p>Using a class is an alternative for using a pipeline.
>>          You can define this class in the handler configuration as an
>>attribute
>>          <em>authenticator</em> of the <em>authentication</em> element,
>>e.g.:</p>
>>       <source>&lt;autentication-manager&gt;
>> &lt;handlers&gt;
>>   &lt;!-- Now follows the handlers configuration --&gt;
>>   &lt;handler name="portalhandler"&gt;
>>     &lt;!-- The login resource --&gt;
>>     &lt;redirect-to uri="cocoon:/sunspotdemoportal"/&gt;
>>     &lt;authentication authenticator="mypkg.MyAuthenticator"/&gt;
>>   &lt;/handler&gt;
>> &lt;/handlers&gt;
>>&lt;/autentication-manager&gt;</source>
>>          <p>This class must conform to the <em>Authenticator</em>
>>interface. This
>>           interface provides a method that tries to authenticate a User
>>and
>>           delivers XML that is stored in the session on success. So, the
>>behaviour
>>           is similar to the pipeline.</p>
>>       </s3>
>>    </s2>
>>    <s2 title="Logging out">
>>       <p>The logout process is triggered by the "auth-logout"
>>         action:</p>
>>       <source>&lt;map:act type="auth-logout"&gt;
>> &lt;map:parameter name="handler" value="unique"/&gt;
>>&lt;/map:act&gt;</source>
>>       <p>This action logs the user out of the given handler and removes
>>all
>>         the information about this handler that is stored in the
>>session.</p>
>>    </s2>
>> </s1>
>> <s1 title="User Management">
>>    <p>In addition to the authentication, the framework manages all kinds
>>of
>>       information belonging to the user. For this reason the framework
>>       creates an own session context called <em>authentication</em>. All
>>information
>>       is stored in this context in an XML structure.</p>
>>    <p>The authentication information (the "authentication" scheme
>>retrieved
>>       from the authentication resource) is stored in this context, so you
>>can
>>       retrieve and change the information using the session transformer
>>and the
>>       usual getxml, setxml etc. commands, so we suggest you to read the
>>session
>>       context document.</p>
>>    <note>The <em>authentication</em> context is only available to the
>>      <em>session transformer</em> if the pipeline in which the
>>transformer is
>>      running, is associated with the (authentication) handler. Or putting
>>      it in other words, you have to use the <em>auth-project</em> action
>>      in that pipeline. Otherwise the <em>authentication</em> context
>>      is not available.</note>
>>    <s2 title="Getting information from the context">
>>       <p>Each element from the context is gettable using an XML
>>         tag:</p>
>>       <source>&lt;session:getxml context="authentication"
>>path="/authentication/ID"/&gt; &lt;!-- Get the ID --&gt;
>>&lt;session:getxml context="authentication"
>>path="/authentication/data/username"/&gt;</source>
>>       <p>The path expression is an absolute XPath-like expression where
>>only
>>         concrete nodes and attributes are allowed. The session
>>transformer replaces
>>         the tag with the value of the first node found in the context,
>>this can either
>>         be text or XML.</p>
>>    </s2>
>>    <s2 title="Setting information in the context">
>>       <p>Using another tag, information can be stored into the
>>context:</p>
>>       <source>&lt;session:setxml context="authentication"
>>path="/authentication/data/usersername"&gt;
>>   Mr. Sunshine
>>&lt;/session:setxml&gt;</source>
>>       <p>Again the path is an absolute XPath-like expression where only
>>         concrete nodes and attributes are allowed. If the requested node
>>exists,
>>         the framework changes the value of that node. If the node does
>>not exists, the framework
>>         adds it to the context with the given value.</p>
>>       <p>The tag is removed from the resource.</p>
>>    </s2>
>> </s1>
>> <s1 title="Application Management">
>>    <p>The application management ia very useful feature for building and
>>maintaining web applications.
>>                        A developer uses it to configure different
>>       applications and to manage the user data for these
>>applications.</p>
>>    <s2 title="Configuring an Application">
>>       <p>A "authentication" application is related to one authentication
>>handler, so an
>>         application is part of the authentication handler
>>configuration:</p>
>>       <source>&lt;autentication-manager&gt;
>>   &lt;handlers&gt;
>>       &lt;handler name="unique"&gt;
>>            ....redirect-to/authentication configuration
>>            &lt;applications&gt; &lt;!-- the applications for this handler
>>--&gt;
>>                &lt;application name="unique"&gt;
>>                    &lt;load uri="loadapp"/&gt; &lt;!-- optional --&gt;
>>                    &lt;save uri="saveapp"/&gt; &lt;!-- optional --&gt;
>>                &lt;/application&gt;
>>            &lt;/applications&gt;
>>       &lt;/handler&gt;
>>   &lt;/handlers&gt;
>>&lt;/autentication-manager&gt;</source>
>>       <p>A configuration for an application consists of a unique name
>>(only
>>         alphabetical characters and digits are allowed for the
>>application name) and
>>         optional load and save resources. The application configuration
>>can contain
>>         application specific configuration values for the various parts
>>of the
>>         application, e.g. information for a portal.</p>
>>       <p>On a successful authentication, the framework invokes the load
>>resource (if present) for each application
>>         of the handler. The content or result of the
>>         load resource is stored in the session context.</p>
>>       <p>The user does not always visit all sides or all applications at
>>         once. So it is not necessary to load all applications in advance.
>>                          Each application can specify if the data is
>>loaded upon
>>         successful authentication or the first time it is needed:</p>
>>       <source>....&lt;application name="unique"
>>loadondemand="true"/&gt;...</source>
>>       <p>The load resource gets several parameters: all the values of the
>>         subnodes of the "authentication" node from the authentication
>>context (e.g. ID, role
>>         etc.) and the parameter "application" containing the unique name
>>of the application.
>>         This unique name must not contain one of the characters '_', ':'
>>or '/'.</p>
>>
>>       <p>In addition the load and save resource get all of the parameters
>>specified
>>         inside the load / save tag of the handler configuration.</p>
>>    </s2>
>>    <s2 title="Configuring the resources">
>>       <p>For managing the application the framework needs to know to
>>which
>>         application a resource belongs. So in addition to the handler
>>parameter the
>>         auth-protect action gets the application name as a second
>>parameter:</p>
>>       <source>&lt;map:match pattern="protectedresource"&gt;
>> &lt;map:action type="auth-protect"&gt;
>>   &lt;map:parameter name="handler" value="unique handler name"/&gt;
>>   &lt;map:parameter name="application" value="unique application
>>name"/&gt;
>>
>>   &lt;map:generate src="source/resource.xml"/&gt;
>>           ...
>> &lt;/map:action&gt;
>>&lt;/map:match&gt;
>></source>
>>       <p>With this mechanism each application resource can easily access
>>its
>>         (and only its own) information. If a resource has no
>>"application" parameter it can
>>         not access information of any application.</p>
>>    </s2>
>>    <s2 title="Getting, setting and saving application information">
>>       <p>A resource accesses its application data similar to the way is
>>accesses the authentication data:</p>
>>       <source>&lt;session:getxml context="authentication"
>>path="/application/username"/&gt;
>>&lt;session:setxml context="authentication"
>>path="/application/shoppingcart"&gt;&lt;item1/&gt;&lt;item2/&gt;&lt;/session:setxml&gt;</source>
>>
>>       <p>The path must follow the same restrictions and rules as always
>>and
>>         it has to start with "/application/". </p>
>>    </s2>
>> </s1>
>> <s1 title="Module Management">
>>    <p>In addition to the application management feature, the framework
>>offers a facility
>>       called module management. It enhances the application management by
>>adding the
>>       possibility of configuring components for the application. For
>>example, the Cocoon
>>       portal engine needs information about the source of the portal
>>profile
>>       for the user, about where the layout is stored, etc. Each portal
>>       needs this information. Assuming that a portal is an application
>>each
>>       application needs this information. As only the portal engine
>>itself knows what
>>       information it needs, the module management is a standarized way
>>for
>>       configuring such components.</p>
>>    <p>The module configuration is part of the application
>>       configuration:</p>
>>    <source>&lt;autentication-manager&gt;
>> &lt;handlers&gt;
>>   &lt;handler name="unique"&gt;
>>     ....redirect-to/authentication configuration
>>     &lt;applications&gt;  &lt;!-- the applications for this handler
>>--&gt;
>>       &lt;application name="unique"&gt;
>>         ...
>>         &lt;configuration name="portal"&gt;
>>           ...portal configuration
>>         &lt;/configuration&gt;
>>       &lt;/application&gt;
>>     &lt;/applications&gt;
>>   &lt;/handler&gt;
>> &lt;/handlers&gt;
>>&lt;/autentication-manager&gt;</source>
>>    <p>So whenever the portal engine is asked to build the portal it can
>>       easily retrieve its configuration from the current application by
>>getting the
>>       module configuration named "portal".</p>
>> </s1>
>> <s1 title="User Administration">
>>    <p>Using the framework, it is possible to add new roles to the system
>>and to
>>       add new users. For this purpose, there are several optional entries
>>for the
>>       authentication handler which provide the needed functionality:</p>
>>    <source>&lt;autentication-manager&gt;
>> &lt;handlers&gt;
>>   &lt;handler name="unique"&gt;
>>            ...redirect-to/authentication configuration...
>>
>>     &lt;!-- Optional resource for loading user information --&gt;
>>     &lt;load-users
>>uri="cocoon:raw://financeresource-sunrise-loaduser"/&gt;
>>
>>     &lt;!-- Optional resource for loading roles information--&gt;
>>     &lt;load-roles uri="cocoon:raw://financeresource-sunrise-roles"/&gt;
>>
>>     &lt;!-- Optional resource for creating a new user --&gt;
>>     &lt;new-user uri="cocoon:raw://financeresource-sunrise-newuser"/&gt;
>>
>>     &lt;!-- Optional resource for creating a new role --&gt;
>>     &lt;new-role uri="cocoon:raw://financeresource-sunrise-newrole"/&gt;
>>
>>     &lt;!-- Optional resource for changing user information --&gt;
>>     &lt;change-user
>>uri="cocoon:raw://financeresource-sunrise-newuser"/&gt;
>>
>>     &lt;!-- Optional resource for deleting a role --&gt;
>>     &lt;delete-role
>>uri="cocoon:raw://financeresource-sunrise-delrole"/&gt;
>>
>>     &lt;!-- Optional resource for deleting a user--&gt;
>>     &lt;delete-user
>>uri="cocoon:raw://financeresource-sunrise-deluser"/&gt;
>>   &lt;/handler&gt;
>> &lt;/handlers&gt;
>>&lt;/autentication-manager&gt;</source>
>>    <p>The entries are described in the following subchapters. All tags
>>can
>>       have additional parameter definitions which are passed to the given
>>resource,
>>       e.g:</p>
>>    <source>&lt;!-- Optional resource for deleting a user--&gt;
>>&lt;delete-user uri="cocoon:raw://financeresource-sunrise-deluser"&gt;
>> &lt;connection&gt;database&lt;/connection&gt;
>> &lt;url&gt;db:usertable&lt;/url&gt;
>>&lt;/delete-user&gt;</source>
>>    <s2 title="Getting Roles">
>>       <p>The <em>load-roles</em> resource is invoked from the framework
>>whenever
>>         it needs information about the available roles. This resource
>>gets the
>>         parameter "type" with the value "roles" and should deliver an XML
>>schema with
>>         the root node "roles" and for each role a subelement "role" with
>>a text child
>>         of the rolename:</p>
>>       <source>&lt;roles&gt;
>> &lt;role&gt;admin&lt;/role&gt;
>> &lt;role&gt;guest&lt;/role&gt;
>> &lt;role&gt;user&lt;/role&gt;
>>&lt;/roles&gt;</source>
>>    </s2>
>>    <s2 title="Getting Users">
>>       <p>The <em>load-users</em> resource is called whenever information
>>         about the available users is needed. There are three different
>>uses of this
>>         resource:</p>
>>       <ul>
>>         <li>Loading all users: The resource gets the parameter "type"
>>            with the value "users". It should then deliver all users in
>>the system.
>>         </li>
>>         <li>Loading all users of one role. The resource gets the
>>            parameters "type" with the value "users" and "role" with the
>>rolename.
>>         </li>
>>         <li>Load information of one user. The resource gets the
>>            parameters "type" with the value "user", "role" with the
>>rolename and "ID" with
>>            the authentication ID of the user.
>>         </li>
>>       </ul>
>>       <p>The XML format of the resource should look like the
>>         following:</p>
>>       <source>&lt;users&gt;
>> &lt;user&gt;
>>   &lt;ID&gt;authentication ID&lt;/ID&gt;
>>   &lt;role&gt;rolename&lt;/role&gt;
>>   &lt;data&gt;
>>      ... application specific data ...
>>   &lt;/data&gt;
>> &lt;/user&gt;
>> &lt;user&gt;
>>   ...
>> &lt;/user&gt;
>>   ...
>>&lt;/users&gt;</source>
>>    </s2>
>>    <s2 title="Creating a new role">
>>       <p>The <em>new-role</em> resource creates a new role in the system.
>>It
>>         gets the parameters "type" with the value "role" and "role" with
>>the new
>>         rolename.</p>
>>    </s2>
>>    <s2 title="Creating a new user">
>>       <p>The <em>new-user</em> resource creates a new user with a role.
>>It
>>         gets the parameters <em>"type"</em> with the value
>><em>"user"</em>,
>>         <em>"role"</em> with the rolename and <em>"ID"</em> with the new
>>ID for this
>>         user.</p>
>>    </s2>
>>    <s2 title="Changing information of a user">
>>       <p>The <em>change-user</em> resources changes information of a
>>user.
>>         It gets the parameters "type" with the value "user", "role" with
>>the rolename
>>         and "ID" with the ID of the user. In addition all application
>>specific
>>         information of this user is sent as parameters.</p>
>>    </s2>
>>    <s2 title="Delete a user">
>>       <p>The <em>delete-user</em> resource will delete a user. It gets
>>the
>>         parameters "type" with the value "user", "role" with the rolename
>>and "ID" with
>>         the ID of the user.</p>
>>    </s2>
>>    <s2 title="Delete a role">
>>       <p>The <em>delete-role</em> resources deletes a role. It gets the
>>         parameters "type" with the value "role" and "role" with the
>>rolename .</p>
>>    </s2>
>> </s1>
>> <s1 title="Configuration Summary">
>>    <p>Here is a brief summary of the authentication handler
>>configuration: </p>
>>
>>    <source>&lt;autentication-manager&gt;
>> &lt;handlers&gt;
>>   &lt;handler name="unique"&gt;
>>     &lt;!-- The redirect-to resource --&gt;
>>     &lt;redirect-to uri="cocoon:raw://loginpage"/&gt;
>>     &lt;!-- Authentication resource --&gt;
>>     &lt;authentication uri="cocoon:raw://authenticationresource"/&gt;
>>
>>     &lt;load uri="cocoon:raw://authenticationsaveresource"&gt;
>>       &lt;!-- optional parameters --&gt;
>>     &lt;/load&gt;
>>     &lt;!-- optional save resource --&gt;
>>     &lt;save uri="cocoon:raw://authenticationsaveresource"&gt;
>>       &lt;!-- optional parameters --&gt;
>>     &lt;/save&gt;
>>
>>     &lt;applications&gt;
>>       &lt;!-- the applications for this handler --&gt;
>>       &lt;application name="unique"&gt;
>>
>>         &lt;!-- Loading/Saving --&gt;
>>         &lt;load uri="cocoon:raw://loadapp"&gt;
>>           &lt;!-- optional --&gt;
>>           &lt;!-- optional parameters --&gt;
>>         &lt;/load&gt;
>>         &lt;save uri="cocoon:raw://saveapp"&gt;
>>           &lt;!-- optional --&gt;
>>           &lt;!-- optional parameters --&gt;
>>         &lt;/save&gt;
>>         &lt;!-- module configurations: --&gt;
>>
>>         &lt;configuration name="portal"&gt;
>>           ...portal configuration
>>         &lt;/configuration&gt;
>>       &lt;/application&gt;
>>     &lt;/applications&gt;
>>
>>   &lt;/handler&gt;
>> &lt;/handlers&gt;
>>&lt;/autentication-manager&gt;</source>
>> </s1>
>> <s1 title="Pipeline Patterns">
>>    <p>As explained in the previous chapters, the framework uses the
>><em>auth-protect</em>
>>       action for authentication and protecting documents. This chapter
>>shows some
>>       commonly used pipeline patterns.</p>
>>    <s2 title="Single protected document">
>>       <p>For protecting a document with an authentication handler only
>>the <em>auth-protect</em>
>>         action with the parameter configuration for the handler is
>>required.</p>
>>       <p>Pattern:</p>
>>       <ol>
>>         <li>Pipeline matching
>>         </li>
>>         <li>Using the <em>auth-protect</em> action for protecting
>>         </li>
>>       </ol>
>>       <p>Example:</p>
>>       <source>&lt;map:match pattern="protected"&gt;
>> &lt;map:act type="auth-protect"&gt;  &lt;!-- protect the resource --&gt;
>>   &lt;map:parameter name="handler" value="myhandler"/&gt;
>>
>>   &lt;map:generate src="resource.xml"/&gt;
>>   &lt;map:transform src="toHTML"/&gt;
>>   &lt;map:serialize/&gt;
>> &lt;/map:act&gt;
>>&lt;/map:match&gt;</source>
>>       <p>It is very important that the <em>auth-protect</em> action wraps
>>the real
>>         pipeline, as the pipeline is only invoked if the action grants
>>access. The
>>         matching must be done before the action is checked as the action
>>performs a
>>         redirect for this document.</p>
>>    </s2>
>>    <s2 title="Multiple protected documents">
>>       <p>Often you want to protect a bunch of documents in the same way.
>>One
>>         solution is to use the single protected document pattern for each
>>document.
>>         With the multiple protected document pattern you only have to use
>>the action
>>         once for all documents and not within each document pipeline.</p>
>>       <p>The prerequisite for this is a common matching pattern for the
>>         documents:</p>
>>       <ol>
>>         <li>Pipeline pattern matching
>>         </li>
>>         <li>Using the <em>auth-protect</em> action for protection
>>         </li>
>>         <li>Pipeline matching
>>         </li>
>>       </ol>
>>       <p>Example:</p>
>>       <source>&lt;map:match pattern="protected-*"&gt;
>> &lt;map:act type="auth-protect"&gt; &lt;!-- protect the resource --&gt;
>>   &lt;map:parameter name="handler" value="myhandler"/&gt;
>>
>>   &lt;map:match pattern="protected-first"&gt;
>>     &lt;map:generate src="resource1.xml"/&gt;
>>     &lt;map:transform src="toHTML"/&gt;
>>     &lt;map:serialize/&gt;
>>   &lt;/map:match&gt;
>>       ....
>>   &lt;map:match pattern="protected-second"&gt;
>>     &lt;map:generate src="resource2.xml"/&gt;
>>     &lt;map:transform src="toHTML"/&gt;
>>     &lt;map:serialize/&gt;
>>   &lt;/map:match&gt;
>>
>> &lt;/map:act&gt;
>>&lt;/map:match&gt;</source>
>>       <p>Very important - as explained with the single document pattern -
>>is
>>         the leading match before the action is performed. The subsequent
>>matches are required
>>         to check which pipeline to use.</p>
>>    </s2>
>>    <s2 title="Controlling the Application Flow">
>>       <p>If you want to create documents which behave different depending
>>if you
>>         are logged in or not, the <em>auth-loggedIn</em> action is the
>>component to use to
>>         control your application flow. This action checks if the user is
>>authenticated
>>         for a given handler and calls all sitemap components inside the
>><em>act</em>
>>         tag.</p>
>>       <source>&lt;map:match pattern="startpage"&gt;
>>
>> &lt;map:act type="auth-loggedIn"&gt;  &lt;!-- check authentication --&gt;
>>   &lt;map:parameter name="handler" value="myhandler"/&gt;
>>
>>   &lt;map:redirect-to uri="loggedInStartPage"/&gt;
>> &lt;/map:act&gt;
>>
>> &lt;map:generate src="startpage.xml"/&gt;
>> &lt;map:transform src="toHTML"/&gt;
>> &lt;map:serialize/&gt;
>>&lt;/map:match&gt;</source>
>>       <p>In the example above, if the user is already logged he is
>>         redirected to the <em>loggedInStartPage</em> document. If he is
>>not logged in
>>         for the given handler, the usual start page is generated.</p>
>>       <p>The <em>auth-protect</em> action returns - if the user is logged
>>in for the
>>         given handler - all values from the context to the sitemap, e.g.
>>ID, role etc.
>>         These values can be used within the other components:</p>
>>       <source>&lt;map:match pattern"protected"&gt;
>> &lt;map:act type="auth-protect"&gt;  &lt;!-- protect the resource --&gt;
>>   &lt;map:parameter name="handler" value="myhandler"/&gt;
>>
>>   &lt;!-- Append the ID of the user to the file name --&gt;
>>   &lt;map:generate src="resource_{ID}.xml"/&gt;
>>   &lt;map:transform src="toHTML"/&gt;
>>   &lt;map:serialize/&gt;
>>
>> &lt;/map:act&gt;
>>&lt;/map:match&gt;</source>
>>       <p>But the <em>auth-loggedIn</em> action does not give the included
>>pipeline
>>         access to the authentication context belonging to the handler. If
>>you want this, you
>>         have to nest the <em>auth-protect</em> action inside!</p>
>>       <source>&lt;map:match pattern"start"&gt;
>>
>> &lt;map:act type="auth-loggedIn"&gt;  &lt;!-- check authentication --&gt;
>>   &lt;map:parameter name="handler" value="myhandler"/&gt;
>>
>>   &lt;map:act type="auth-protect"&gt;  &lt;!-- give access to the context
>>--&gt;
>>     &lt;map:parameter name="handler" value="myhandler"/&gt;
>>
>>     &lt;map:generate src="getinfofromcontext.xml"/&gt;
>>     &lt;map:transform type="session"/&gt;
>>     &lt;map:transform src="toHTML"/&gt;
>>     &lt;map:serialize/&gt;
>>   &lt;/map:act&gt;
>> &lt;/map:act&gt;
>>
>>&lt;/map:match&gt;</source>
>>    </s2>
>>    <s2 title="Session Handling">
>>     <p>If a user is authenticated, the user has a session. However, care
>>has to be taken that
>>       the session tracking works, which means that Cocoon can detect that
>>a follow up request
>>       of the user belongs to the same session.</p>
>>     <p>The easiest way is to use the <em>encodeURL</em> transformer as
>>the last transformation
>>       step in your pipeline. For more information about session handling,
>>have a look in
>>       the <link href="session.html">chapter about sessions</link>.</p>
>>    </s2>
>> </s1>
>></body>
>></document>
>>
>>
>>
>>
>>
>>
>> 
>>
> 
> 


-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message