On 15/4/20 6:24 am, Mark Thomas wrote:
On 14/04/2020 07:34, Brian Burch wrote:
<snip/>
I searched for usages of MessageDigestCredentialHandler.setAlgorithm,
but only found it used once - within TestJNDIRealm. I did not find any
occurrences within tomcat mainline code, but would not be surprised if
the algorithm was intended to be set within code which used
introspection at runtime.
Correct. During the parsing of server.xml
My initial code inspection makes me strongly suspect tomcat does not
initialise JNDIRealm and a nested CredentialHandler properly during
startup. However, I am not smart enough to attach my debugger to the
tomcat jvm until it is too late.
I had a smart idea... at a breakpoint I changed the value of the
algorithm instance variable from null to "SHA" before the comparison,
but I was slapped down with the following Exception:-
If you had tried "SHA-1" here it should have worked.
Noted, but see later.
So, if anyone has read this far, perhaps you can suggest my next best
course of action. Does this seem to be a bug in tomcat processing of
server.xml and initialisation of the JNDIReal nested CredentialHandler's
algorithm attribute? Is there a smart way to catch the tc8 startup
process and catch it early enough in my remote debugger?
Are the classes org.apache.catalina.storeconfig.RealmSF and
CredentialHandlerSF where I should be looking for a bug?
No. That is to do with writing out server.xml. You can ignore them in
this context. If it were a Tomcat bug I'd start looking around
RealmRuleSet or CredentialHandlerRuleSet
Thanks very much for your tip. I successfully stopped tomcat
initialisation and stepped through the latter two classes.
Or perhaps I
have just coded my server.xml badly and the algorithm is being silently
ignored?
Very interesting! There were no error messages and without your comments
I would have trusted my server.xml based on the "working" tomcat7 version.
I stared hard at the xml and eventually realised I had not got the
correct syntax in the tc7 Realm section. Inadvertently, my coding had
NOT nested the JNDIRealm below the LockoutRealm. However, because the
algorithm attribute was associated with the JNDIRealm section,
everything /appeared/ to be working OK.
Once I had converted the file for tc8, I properly nested the
CredentialHandler within JNDIRealm, but JNDIRealm was not nested within
LockoutRealm. The peculiar resulting data structure meant that the
CredentialHandler was not initialised properly with /any/ algorithm.
Once I fixed my server.xml, authentication succeeds when algorithm ==
SHA-1 BUT the LDAP hash must be prefixed {SHA} (see below).
I'd expect you to see an error message if your server.xml isn't quite
right although that is what this looks like.
There was no error message. I think my xml was syntax-free, but it did
not reflect my intent.
My tomcat users are in transition. Many still have SHA-1 LDAP hashes,
but for non-tomcat reasons they need to be migrated to SHA-256 fairly soon.
Having stepped through MessageDigestCredentialHandler.matches I am
surprised it makes an explicit test for
storedCredentials.startsWith("{SHA}"). This means the code is too
simplistic to recognise al LDAP hash of {SHA-1}. It certainly can't
recognise {SHA256} from the directory.
https://docs.oracle.com/javase/7/docs/api/java/security/MessageDigest.html
states the jvm is required to support the MD5, SHA-1 and SHA-256
algorithms, but I can't see how to coerce MessageDigestCredentialHandler
to recognise and match SHA-256 hashes.
Do you agree with my analysis? Should I just hack the code and see what
happens?
Also, given the LDAP mixture of SHA-1 and SHA-256 hashes, do you think
it is worth me trying to nest two CredentialHandlers within the single
JNDIRealm?
Brian
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
