On 16/04/2020 09:56, Brian Burch wrote:
> On 15/4/20 6:24 am, Mark Thomas wrote:
<snip/>
>> 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.
Can you provide before and after extracts from server.xml. I'm not 100%
what your non-working configuration looked like. I'll see if we can do
anything to highlight the configuration issue.
> 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?
Chris is probably the best person to comment on this as he did the
research and work on this.
> 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?
Yes.
>From memory, each MessageDigestCredentialHandler uses a single hash. If
you need to support multiple hashes you use the NestedCredentialHandler
and nest multiple MessageDigestCredentialHandler instances, in
preference order.
Additional forms of {...} at the start of the hash look to something
MessageDigestCredentialHandler needs to be adjusted to handle. Maybe
look for {SSHA} first and then look for {...} and simply remove the
{...} before processing the hash.
Alternatively, a smarter MessageDigestCredentialHandler that looks at
the leading {...} and adjusts the algorithm accordingly (maybe falling
back to a configured default if none is found) looks to be a more
efficient solution for your use case.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
