-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Brian,
On 4/20/20 12:17, Christopher Schultz wrote:
> 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/MessageDiges
t
>
>>>
.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.
Aha: if you remove this:
userPassword="userPassword"
Then you'll end up "binding as user" instead of "comparing
credentials". If you do that, you'll delegate credential-checks to the
server.
In that case, I think you will not need any <CredentialHandler> or
anything like that.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6dzJMACgkQHPApP6U8
pFiboA/+L8+kTZxAWdKq+oO7bKMkC7DzVYCxzlXrPJpMzR1bO80cP8OTOY4EWQQ0
BafXn/PQ5SSZS4rNUjUX3tz5nlVVoPk3WP8jChdV7ccPzkEAxfGa3Dzzt7vX/h1F
npEh20Ss5p5ESIfo6rqawjW+9dwad4Ov2rXv4yjKNxvmrkIKjrKP+GMe9iZbZV78
G8JP/WdnEkBGu4gIo63L16zco7f6kKqNo5e9m2UKpeSgR00M92SxuhOG+f5RQhdf
n9RkaL0y2XXnbm2oXv2O1yFNXkl/uxe3ySKVqJeEImrHyWoqdi4Z9qSIknjZoPjY
S1WUOgmxLqqIrssdBl0/BJBFezVFO0zBiKd9DXZg4nALp3aVwHpJrg6tXg7qhiON
nuiPY1bMXJzTF9TFFTnYNb1AxWW0T37VJx2Ni6/uAOXTdK0yDAB+9itz/kLgVgvx
3RS1P74VJ6u508iX30c04kXa1qZBfDpcpyAiRQEsKONHkU2mZPBFGuDBATyOc0n+
poAdnhDlOLP7FyrXwdDAxPpDXVDsX1KrRqxhVvXNrBBPCEkzZa6vWOdJz58JB84Z
CgbNaxd2gcPx9kogZ7183Xs91t4KsqZtbOzFQPdQINvNuRB0SkMCGpRM6vsJ5eoz
jUYcMhnzSk4vCqipgn42X+uEEqRxt5EwoMN6esCe/BkY9dgPOkE=
=ZSsb
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
