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. 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. 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.) -- Mark H. Wood Lead Technology Analyst University Library Indiana University - Purdue University Indianapolis 755 W. Michigan Street Indianapolis, IN 46202 317-274-0749 www.ulib.iupui.edu
signature.asc
Description: PGP signature
