DO NOT REPLY [Bug 35036] New: - JNDI Realm unable to use NIS context factory & FLAT

[bu...@apache.org]

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: delbd@oma.be


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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org