> Craig Berry wrote:
First, let me remind you that the list has decided not to use
html email. It's no problem for me, but some people dislike it.
> >Good point, but what about assigning LDAP user privileges? Isn't
> >it neccessary to assign each new user rights to read and modify
> >his own data, and read global group/role/permission data?
> >This would make creating new users much more complicated.
> >When using signle LDAP account to access all data on behalf of
> >Turbine application makes the installation easier.
>
> This is one of those questions that each admin (or admin team) needs
> to decide. You might well have different access levels, so e.g. a user
> could authenticate to read all of her own data, but modify only certain
> fields, while a more privileged admin account could both read and write
> all data, and in turn general/anonymous users could get read-only
> access to only non-sensitive public data (name, email, phone number,
> that sort of thing). The granularity of access control is a can-of-worms
> subject. Best to allow for all (reasonable) possibilities.
I'm all in for allowing the largest range of possibilities, but
this something that we didn't even try with the databases, because
managing DB user accounts and privileges is complicated and very
server dependent. Some of them allow an user to grant other users
the permissions they have, but others require administrator privileges
to grant rigths. Creation of new user accounts is usualy reserved
only to the administrators. Now, it is almost always desirable that a web
application could create user acounts on it's own, and we certainly
wouldn't like to give admin privileges over the database server
to the application. Keeping the system secure would require human
intervetion whenever creation of new account is requested. This
is not an acceptable solution for sites that are expected to grow
to hundreds or tousands of users.
I don't have any experience in LDAP server management, but I suspect
that they are very similar to database servers in this regard.
This makes me believe that using user's personal information for
authenticating to the LDAP server is not practical.
> * Client retrieves encrypted password, encrypts the entered password,
> and compares. Weakness per my discussion above.
> * Client sends entered password to server, gets back a boolean result
> indicating whether it matched the stored value.
>
> Obviously, the second option is preferable, where it is available.
> Netscape's ldapsdk authenticate() call operates this way, for example.
Good. Now I'm pretty confident that we are hadling both cases properly.
> Cool, i'm going to pull it down this morning.
I commited another boatload of changes today :)
> By the way, has anyone made Jetspeed 1.2b1 work with the new Turbine?
Uh, I bet the Jetspeed guys are not happy about recent shuffling of
many commonly-used classes (like User, or TurbineUserPeer) around.
On the other hand, nobody came here to complain. They probably will
once they try to upgrade their turbine.jar :-).
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
