-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Brian,
On 4/17/20 08:28, Mark Thomas wrote:
> 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.
Hmm. The LDAP stuff I think wasn't me, but I understand it a little
bit. Brian, is there a standard I can read for this? I'm familiar with
LDAP servers storing credentials with "{sha}" prefixes but not others.
Honestly, for an LDAP backend, I'd expect the LDAP server to be
checking the credentials sent by the client, not to have the client
fetch the credentials and do its own checking. That's the whole point
of delegating authentication to the LDAP server.
>> 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.
Honestly, allowing the LDAP server to consume the user's plaintext
password would probably be the best. I'm not sure familiar with
Tomcat's LDAPREalm, but I'm assuming you can either connect as a
service-user and then check other users' credentials, or you can use
the login-user's credentials to authenticate directly. The latter
scheme seems like a better plan to me: the server gets to make the
decision for how to check the credentials and Tomcat doesn't need to
worry about it at all.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6dyzEACgkQHPApP6U8
pFi+qQ/+OJ9xHJZ0ntR/1NIo++wYfZUus6QhJv3qWGIUCKqkTWUdf28A2u+00h1A
XMjf6imOrzOmTCD39t4DcQQQ5BGtn6a+NmCagDQ90UdtxS72YgoQhbimOrQHOjDS
ZRFpuAThVj3qldwKMNawOFSAQUlLt0a4t8SMYrKn8hIuMaiU9ze7BEr6/s7pDNgr
hLA/JZXF1BCowBQMBMWChZ3ryFaHjTfdREL1V59qCEY7+7w4e2oPJHT74lEoAU9N
1WX2CziILN8JUEMS8VFQ1y+il8dN+Yw1Jebb3iM8OgLj2qVSGVI7Zj/T3ScViH//
SexNTRTzeCAzOPD9g7k7QZEgE/DFWgDkAHzzmssmV0Ws/C02plJKFvMtDwLk37XS
Lp9YlymtJF3coypnvaBRcc8POI3q89NQvF4yPOXL3g4Y5Dm52qD+hCNZ21L3MfkT
6S0YdpX/DEs2MC6jFYpsI3r0gZppstRRt3YxnI9gLSZ0NrroMrOl60+QFBRduYYi
4mfuSyD8nhyVvualbvGg3b/x4qjPokEyuOygGmM6C3B18iWF9N1BiT49dmvooFuo
0Rp6ql0bx5nyRS5mfsonHgxJMQcmwSnkaIMProV+bbDBMVsjh1sEhad4jBtkHLzE
GN3iqt7iPrQ/1PgTVEkOpAuvnL4OdPcFTVIPfjkOSCvDwCFEh1I=
=370p
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
