I highly recommend going the route of LDAP here.  Storing user group info
within a RDBMS localizes the data.  Through LDAP reads are fast and the data
can be replicated easily.

Perhaps the components for now could be built using an external server.
Just pick one.  If the JNDI code written does not use server specific
features like special controls, then we could swap out an external LDAP
server for an embedded one using LDAPd without code changes.

Count me in on helping out however I recommend focusing on LDAP and of
course supporting other backing stores.  I already have to write code within
the LDAPd server to manage its users and groups as a basis for RBAC.
Perhaps the code could be reused.  The user/group directory information base
is what I will start designing soon after I have a newly designed system
backend completed for storing this information.

-----Original Message-----
From: Vincent Tence [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, September 10, 2003 12:07 PM
To: 'Avalon Developers List'
Subject: RE: Cornerstone UsersManager

Hi Alexis,

If you're talking about Authentication, Authorization and Auditing, there
has been some work done in this area over at sourceforge. The original idea
was to create AAA blocks for Phoenix. See
http://sourceforge.net/projects/aaa4avalon/

I think there has not been a lot of activity going on recently, but there is
already a good code base and some nice ideas there. I had an interest at
some point and worked on JDBC features, before our project got cancelled. If
this is something you want to revive, I would be ready to help out. Looks
like I might be needing that in the near future.

- Vincent

> -----Original Message-----
> From: Alexis Agahi [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, September 10, 2003 11:09 AM
> To: Avalon Developers List
> Subject: Cornerstone UsersManager
>
>
> Folks,
>
> How about having a cornerstone service for handling users
> management /
> authentification ?
>
> Many applications could share same "users" repository using
> this service via
> composition.
>
> We also could use vCard (or whatever) as user data structure.
>
> Users persistency could be done via a UsersStore (persistence
> on disk, ldap or
> database).
>
> Ideas ?
>
> --
> Al
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to