cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From SAXESS - Hussayn Dabbous <>
Subject Re: [Fwd: Re: [heads-up] wiki abuse: your advice please]
Date Sun, 16 Mar 2003 11:20:03 GMT
Hy, Steve;

You asked if someone has something for plug-and play
authentification right at hand. I have something, but
it is currently under development. If you can put this
on a timescale of two months, then please read on.
Otherwise skip this email as irrelevant ...

I will be ready with my work on a generic authentification
server within the next two months and would happily give it
for free usage to the cocoon-comunity for plugin to the
Cocoon-Wiki and other services as appropriate. A brief
description follows:

I currently build up a generic authentification webapplication,
that acts as authentification server and can be queried from
any other webapps. The core is already running, but currently
incorporated into one specific webapplication. I will separate
out the  authentification part and repack it to a separate
"authapp" webapplication.

The general sequences will be something like:


1.) user registers at authapp
2.) authapp registers user but blocks access.
     a new user-entry is inserted into an LDAP database.
     Here we will allow a configurable accesspoint so that
     you can do whatever you want to check, if the user
     can be registered at all.
3.) authapp sends acknowledge-request email to user
     passing the userid (but NO passwd yet!)
4.) user send acknowledge
5.) authapp unblocks user
     Here we will allow a configurable accesspoint so that
     you can do whatever you want to check, if the user
     can be unblocked at all.
6.) authapp send generated passwd to user but not
     the userid (for obvious security reasons)
7.) On first login to the webapp the user is forced
     to modify the generated passwd.


1.) user accesses page from an "webapp"
2.) "webapp" asks user for credentials
3.) user enters userid/passwd
4.) "webapp" connects to authapp
5.) authapp checks for existance of userid and
     valid credentials.
6.) authapp sends back login infos
     plus authorisation status (allowed/denied to access page)
7.) "webapp" associates user to HTTP session
     and caches authorisation info for this page for later usage.
8.) "webapp" returns the page, if the user is authorised.

further calls to webapp within same session:

1.) user accesses page from an "webapp"
2.) if page-authorisation is cashed, decide based
     on the authorisation value (allow/deny)
3.) if page-authorisation is not cashed:
     webapp connects to authapp.
4.) authapp checks for status (allowed/denied to access page)
     and sends back allow/deny
5.) "webapp" caches authorisation info for this page for later usage.
6.) "webapp" returns the page, if the user is authorised.


the connection between authapp and the webapplication
primarily goes through a simple API (jar-file) and can be
incorporated into JSP-Wiki with ease. I think i will
make it even more simple to plug in to existing webapps
by simply setting up a special REALM for tomcat, that handles
ALL internals. Then all you need to do on the webapp side
is configuring your webapp to use the realm and your done.

On the authapp side you will need litle more to do:
1.) authapp needs an LDAP server in the background.
     We use secureway 3.2.1 for historical reasons.
     Open-LDAP should work either.
2.) To get authapp up and running is a matter
     of deploying the webapp to your appserver.
3.) define the authorisation space
4.) define the LDAP-structure
5.) define the LDAP-connection infos)

Again, if this is interesting stuff for the cocoon-Wiki
authorisation, please tell me. I will grant free usage
of this stuff to cocoon-comunity.

regards, Hussayn

Steven Noels wrote:
> explicitely asking for opinions over here
> -------- Original Message --------
> Subject: Re: [heads-up] wiki abuse: your advice please
> Date: Sat, 15 Mar 2003 11:48:15 +0100
> From: Steven Noels <>
> Reply-To:
> Organization: Outerthought
> To:
> References: <> 
> <> <>
> SAXESS - Hussayn Dabbous wrote:
>> what about simply reusing the userlist from the cocoon-dev, 
>> cocoon-user, cocoon-doc mailing lists and allow write access only to 
>> these
>> registered users ?
> We don't have access to the list of registered email addresses on
> cocoon-* lists, and I doubt that will happen any time soon - there's
> some privacy issues involved with that, too.
> Pier, do you have any opinion about this?
> I'm thinking along the lines of adding some container-based
> authentication around Edit.jsp, and some smallish webapp so that people
> can register an email address (= user name) / password. Does anyone has
> something like that laying around? Use cases:
>  * enter email address -> generated pwd gets send to you
>                        -> address & pwd are stored in db
>  * you can log into that app
>                        -> change pwd
>                        -> drop your registration data
>  * that same database is used for container-based authentication around
> Edit.jsp
> What do you guys think?
> </Steven>

Dr. Hussayn Dabbous
SAXESS Software Design GmbH
Neuenhöfer Allee 125
50935 Köln
Telefon: +49-221-56011-0
Fax:     +49-221-56011-20

View raw message