-----Original Message-----
From: Rafal Krzewski [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 21, 2000 2:20 AM
To: Turbine
Subject: Re: Validate in user class vs LDAP
>Craig Berry wrote:
>> That's necessary for such purposes as adding users, of course.
>> And it can certainly be used for single-user data access. But
>> the prefered mechanism for getting a single user's data is to
>> authenticate as that user and then grab the data. This minimizes
>> the potential for accidental or intentional abuse. The reasoning
>> is similar to why even users who have root access on Unix
>> systems don't always log on as root.
>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.
>> Or in which it may be retrievable, but encrypted. Even if you
>> include client-side code to encrypt and compare, you're dependent
>> on the server-side encryption scheme never changing, which is a
>> slight danger. You must also provide a client-side encryption
>> implementation for each back-end scheme supported by the app.
>> Far easier to pass the password to the back end and let *it* do
>> the encrypt and compare. Again, the analogy to Unix's password
>> scheme is instructive.
>
>A server that is presented a plaintext password, encrypts it and
>sends it back for client side compare does not make much sense,
>now does it? Sensible servers would store the encrypted password,
>and return only compare results, just as unix/NT login etc.
That's not what I was saying. The two major modes of operation (given
an encrypted password on the server side) are:
* 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.
>You can see most of the framework in org.apache.turbine.services.security,
>but there will be some additions to it. Right now I'm working on refactoring
>the ACLs, and my friend is working on LDAP user implementation.
Cool, i'm going to pull it down this morning.
By the way, has anyone made Jetspeed 1.2b1 work with the new Turbine?
