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:
registration: -------------
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.
login: ------
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.configuration =============
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 <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Organization: Outerthought
To: [EMAIL PROTECTED]
References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
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 E-Mail: [EMAIL PROTECTED]
