YNT: ldap backend new version and mail portlet improvements

[Ender Hikmet KILIÇOÐLU <en...@kilicoglu.nom.tr>]

yes you are rigth for subclassing I tried to realize this uzing baseldap
class which is main class for all ldap OM objects. But still maybe one layer
can be added for more flexibility.

For now I dont think we need jce needed because I had many problem with jce
and localization. Also As you said there is no support for one way salt
encryption crypt. For this purpose I think some puggable password provider
class will be enough. As you said  its possible to soolve this problem on
security layer not on ldap layer. So DB backend can use it also.

Only user lookup paths will be enough other information may exist in one
preconfigured path (not static)

-----Özgün Ileti-----
Kimden: Sami Leino [mailto:sami.leino@netorek.fi]
Tarih: Saturday, May 31, 2003 3:50 PM
Kime: jetspeed-dev@jakarta.apache.org
Konu: Re: ldap backend new version and mail portlet improvements


> ldap field mapping configuration (objectclass=jetspeeduser)

Quite important feature, which would make subclassing LDAPUser much
easier. Configuration could be done either using a property file, or
providing a hook for the subclass to specify which attributes to store.
Hook for the subclass could be more flexible solution, IMO.

> self binding option storing crypt password
> optional password creation interface (?)

It would be nice if the crypt implementation could be converted to use
JCE. As far as I know, JCE does not support UNIX crypt, which is quite
widely used with LDAP. Therefore, an extra layer must be introduced for
covering both JCE and UNIX crypt, or alternatively UNIX crypt must be
dropped in order to make LDAP security implementation symmetric with the
database security implementation.

Another problem is that UNIX crypt uses a salt in the encrypted password.
This means that when the same clear-text password is encrypted several
times, the result is different every time. In order to check if the
supplied password matches to the stored one, you need first to parse the
salt from the stored password, and encrypt the supplied password with it
to see if the passwords match. I think that there should be a "boolean
passwordsMatch(String cleartextPassword, String encryptedPassword)" method
for comparing the passwords, and this method could perhaps be added to the
CredentialsManagement interface?

A possibility to configure different search path for different kind of
entities (users, roles, groups, permissions) would also be a nice feature.
Overriding the base path should be optional, so you could use the same
base path for all kind of entities if you wanted to.

--

Sami Leino
Software Developer, Netorek Oy, Turku, Finland
Email: sami@netorek.fi
Phone: +358 44 0140499



---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org