-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 4/21/20 10:31, Mark H. Wood wrote:
> On Mon, Apr 20, 2020 at 12:17:54PM -0400, Christopher Schultz
> wrote:
>> 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.
>
> The point of "client fetches credentials via LDAP to do its own
> checking" seems to be *not* to delegate authentication, but to use
> the directory as a store of hashed credentials.
Right. But understanding that is important to being able to solve the
problem posed by Brian.
> The only reason for doing this that I've been able to come up with
> is that in this setup there is no reason why the enterprise user
> has to be a directory user, i.e. only a handful of directory
> administrators and service accounts can actually authenticate
> identities *to the directory*, while many objects have credentials
> stored in a different attribute that the directory itself does not
> use for authentication. Minimizing access to a central store of
> identity and authorization makes sense in some settings.
Fair enough. But LDAP servers are perfectly capable of managing their
own permissions such that not everyone who can bind to the server as a
user can, for example, make any changes to it.
> I get the feeling that the X.500 designers deliberately left
> specific applications (like authenticating identities in other
> products) as an exercise for the client designer, so as not to
> foreclose clever uses they hadn't thought of. One result is a
> rather Wild West approach to using directory services for
> authentication. (I see this also in services dedicated to
> authentication: seemingly no two organizations use CAS in the same
> way.)
Exactly. In this case, the LDAP server is free to store the
credentials in any way it wishes, protected using any available
scheme, but now Tomcat is apparently on the hook for being able to
support all the possible variations. It will definitely be a
moving-target and it's very different than the way in which e.g. an
application-managed database table of user authentication information
would (likely) behave.
The good news is that Tomcat can support multiple parallel
CredentialHandlers. You just have to make sure you configure them such
that you don't leave your system wide open. :)
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6fcDUACgkQHPApP6U8
pFg3hhAAoSWBjp14WycjZv8zlqu5bcopo4As0AtSfosAe4/OcFn5izuoXxKzNskD
ZU/iKfkmuTV94UZzxFRq5AwqainFGKKARK1HpUoi5qGn4kWD1GLuFeGehZiusgGz
8ENtbdyRcl1ES8gMst1uQVNjSuyJj9FJuPwZbbtbtKmKQ8+itbrZh5zJEdm+PKR/
JOtyZQ+90Fj2i+bWeXVgotDZZm8r+WSSgzeifTAcul3N+gmAJhjI8PbkXjpM9+cC
VZl1N1dfRHHPUxTumMHOBQ0JW3tnn+lWvXwl21WjYmyAEQEO0GZRxvZt0d65ZKX2
/kpoOW7l/8vK7mLfg8Mx8VTbIC+084ZI4a+gUJ8NnecRsjisFenP0FouBEicCQ0L
hDzczlMcghWBJBQyRSrn5KRylX6rpuxN3Fl0Cp9uc4p2gxvWWdVqqXmYcjLmZdE/
Ls221A5juVL3l8CCGJiDcD3X4mGTbeZOOFQcHPtK52mnjQICoWkSlmbDH4j36wS3
dK+/9rE/NWpLz53bnW6nUbMz3pvnMr1bhivkEO0CpnjrD5WH0Ev0CQuH3L7ThX6L
DlnyX/hllPMBan3mHOIky18UnfdWd6m7hVLzjAePlxKSlF1sEmDjCU9o9q6X5fP9
/BlVhA0l+zwdbv1hVagT2qhw5friwdtzwS7NxhtxkfgqnGY0UgA=
=up+K
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
