DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35036>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35036 Summary: JNDI Realm unable to use NIS context factory & FLAT Product: Tomcat 5 Version: 5.5.7 Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina:Modules AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Am not very used to programmatic manipulations of JNDI, but while trying to use the JNDIRealm over a NIS (yellow pages passwords/groups) i noticed the following problems. First, the sun NISContextFactory use a FLAT directional model (i don't know exactly what it means, but i think this is related to the imposibility for a node to know his parent), one of the consequences is it's impossible to build a fully qualified name from a user entry. The following code in realm does fail with exception thrown at the line "name = name.addAll(entryName)": NameParser parser = context.getNameParser(""); Name contextName = parser.parse(context.getNameInNamespace()); Name baseName = parser.parse(userBase); // Bugzilla 32267 Name entryName = parser.parse(new CompositeName(result.getName()).get(0)); Name name = contextName.addAll(baseName); name = name.addAll(entryName); To get around this a try catch around it and defaulting the dn to 'username' did solve my problem. So easy to fix. Second, if there is no way to have digested passwords supporting anykind of salt. The method digest() from RealmBase only gets the credential, not the encrypted password to extract the salt. Most unis based password still rely on salts. (Some even use MD5+salt or SHA+salt) Third, there is a test "if (password.startsWith("{SHA}"))" around line 1188. Seems in case of NIS, there is a more generic {<algorithm_here>}<encrypted_password_here> form used. In my case, mapping to an HP-UX NIS is in the form "{crypt}<encrypted_password>". The {crypt} part must be removed before comparing to crypted password. Last but not least, the HP-UX crypt does use DES (i know this is far from the best choice algorithm) but java does not provide a DES digest, so i had to do some other way. I solved the crypt problem and salt problem by using code inspired from http://cvs.sourceforge.net/viewcvs.py/esup-casgeneric/esup-casgeneric/esup-casgeneric/source/org/esupportail/cas/server/util/crypt/Crypt.java?rev=1.1&view=markup As there can be lots of possible from depending on the jndi mapping, for the password, maybe a good solution would be to add a parameter to the JNDIRelam which would be digestClass="com.company.someDigestClass" and have the realm do a digestedPassword = theDigestClass.encrypt(storedPassword, crendentials). This way the encryptClass could extract the salt from storedPassword and then encode the Credentials using it the class dedicated algorithm and return the encryptedPassword for comparaison. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
