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:[EMAIL PROTECTED] Tarih: Saturday, May 31, 2003 3:50 PM Kime: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] Phone: +358 44 0140499 --------------------------------------------------------------------- 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]
