Authorising the User

First of all it is important to remember that this is only one means of doing this. The adminHandler defined in the component configuration section of the sitemap is:

context://admin/sitemap.xmap

<map:handler name="adminHandler">  <map:redirect-to uri="cocoon:/login"/>  <map:authentication uri="cocoon:/authenticate-user.html" /> </map:handler>

A password transformer to encrypt passwords is also declared (obviously the type of encryption is not important here and can be chosen by the user using their own transformer):

<map:transformers default="xslt"> <map:transformer name="password" src="resource://lib/transforming/PasswordTransformer"/> </map:transformers>

In order to authorise a user the authentication process with the URI "cocoon:/authenticate-user.html" is invoked. This is resolved within the current sitemap (the pseudo-protocol "cocoon:/") (although it does not strictly have to be there. In the example we have the following pipeline (note that it is internal only):

context://admin/sitemap.xmap

<map:pipeline internal-only="true"> <map:match pattern="authenticate-user.html"> <map:generate src="context://configs/adminUsers.xml" label="xml-content"/> <map:transform src="context://resources/transforms/admin-getLoginQuery.xsl"> <map:parameter name="username" value="{request-param:username}"/> <map:parameter name="password" value="{request-param:password}"/> </map:transform>  <map:transform type="password" /> <map:transform src="context://resources/transforms/admin-buildAuthenticateDOM.xsl" /> <map:serialize type="xml"/>  </map:match> </map:pipeline>

The pipeline takes the list of admin users, together with their associated data, and processes it to produce a single user after the admin-getLoginQuery.xsl transformer. The password entered by the user is then encrypted using the PasswordTransformer transformer previously declared. Finally an XML structure is built using the admin-buildAuthenticateDOM.xsl transformer.

The output of this is XML which is taken back by the adminHandler as confirmation that the use is authorised. This process is described in a little more detail below.

The Admin User File

The data on the users is stored in a simple XML file in the context://configs directory and takes the following example structure.

context://configs/adminUser.xml

<?xml version="1.0" encoding="ISO-8859-1"?> <authentication> <users> <user> <username>hsfr</username> <password>9f7f32c605xxxxxxx225613d30b</password> <data> locally defined data about this user - address etc </data> </user> </users> </authentication>

The file can obviously be put anywhere for stronger protection etc. The format can be changed but at the expense of rewriting all the transformers. The extra data structure holds user's details and an example of this is given on the documentation on Paloose forms. The data structure is fed into the admin-getLoginQuery.xsl transformer which is:

context://resources/transforms/admin-getLoginQuery.xsl

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:param name="password"/> <xsl:param name="username"/> <xsl:template match="//authentication"> <xsl:element name="authentication" > <xsl:attribute name="username"><xsl:value-of select="$username" /></xsl:attribute> <xsl:attribute name="password"><xsl:value-of select="$password" /></xsl:attribute> <xsl:apply-templates/> </xsl:element> </xsl:template> <xsl:template match="@*|node()"> <xsl:copy> <xsl:apply-templates select="@*|node()"/> </xsl:copy> </xsl:template> </xsl:stylesheet>

This adds the user's username and password that was entered on the login form (accessed by the redirect). Thus we get:

<?xml version="1.0" encoding="ISO-8859-1"?> <authentication username="hsfr" password="******"> <users> <user> <username>hsfr</username> <password>9f7f32c605xxxxxxx225613d30b</password> <data> ... </data> </user> </users> </authentication>

Next the password is encrypted using the PasswordTransformer transformer which outputs:

<?xml version="1.0" encoding="ISO-8859-1"?> <authentication username="hsfr" password="9f7f32c605xxxxxxx225613d30b"> <users> <user> <username>hsfr</username> <password>9f7f32c605xxxxxxx225613d30b</password> <data> ... </data> </user> </users> </authentication>

The next stage is o make sure that the user has the correct password and build a suitable XML document to give back to the auth-action. This is done by the admin-buildAuthenticateDOM.xsl transformer

context://resources/transforms/admin-buildAuthenticateDOM.xsl

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:variable name="gPassword" select="//authentication/@password" /> <xsl:variable name="gUsername" select="//authentication/@username" /> <xsl:template match="authentication"> <authentication> <xsl:apply-templates select="users"/> </authentication> </xsl:template> <xsl:template match="users"> <xsl:apply-templates select="user"/> </xsl:template> <xsl:template match="user"> <xsl:if test="normalize-space( username ) = $gUsername and normalize-space( password ) = $gPassword"> <ID><xsl:value-of select="username"/></ID> <data> <ID><xsl:value-of select="username"/></ID> <username><xsl:value-of select="username"/></username> <password><xsl:value-of select="password"/></password> </data> </xsl:if> </xsl:template> </xsl:stylesheet>

This transformer outputs a valid structure for this user, which is similar to what was input (without the root attributes):

<?xml version="1.0" encoding="ISO-8859-1"?> <authentication> <ID>hsfr</ID> <data> <ID>hsfr</ID> <username>hsfr</username> <password>9f7f32c60........513d30b</password> </data> </authentication>

or a blank structure:

<?xml version="1.0" encoding="ISO-8859-1"?> <authentication/>

if the password does not check. This is used by the AuthenticationManager when performing its checks. Provided that the above structure is returned (the XML serialize stage at the end of the pipeline) you may provide any form of authorization mechanism. Anything that is between the <data>...<data> tags is considered user defined and is passed through transparently together with the ID, username and password.

The next section deals with the login mechanism.