Michael Bartosh schrieb am Wed, Apr 10, 2002 at 12:56:31AM -0600: > At 7:52 AM +0200 4/10/02, Birger Toedtmann wrote: > >But why not storing *authentication* information (i.e. passwords) in > >LDAP as well so you don't have to maintain two userbases (one auth"E" > >in SASLs sasldb and one auth"O" in LDAP)? > > Because in theory, Directories are better suited for authorization, > and Authentication mechanisms for Authentication. At least that's > what the textbooks say- and what LDAP developers seem to think, which > is why, AFAIK, sasl is part of v3. v2 had extremely weak > authentication mechanisms- unless of course you built in Kerb > support, which is now deprecated in favor of Kerb-via-sasl. > > In practice, most LDAP implementations don't have great > authentication mechanisms without sasl. You can always use TLS, and > probably should, anyway, but that's not the point. Keeping hashed > password in the directory also means you have to cook up really > creative ACL's.
I agree with all points but practical/organisational issues. First, ha- ving credentials in a separate sasldb is as well complicated as having them in a directory secured by TLS and ACLs. And as I always use ACLs to protect directory information extending this to cover authentication credentials (i.e. passwords) is not a showstopper. The hint to textbook authentication/authorization separation is clear but lacks some details I think: SASL is a lib for faciliating authentication mechanisms, not directly for storing authentication credentials. Whereas LDAP servers are not directly designed for faciliating authorization mechanisms but storing user information (including credentials). So I would prefer for SASL doing all authentication requests but fetching information needed from a directory. But if you need to authenticate to the directoy before fetching anything (which makes perfect sense) you are then in a loop. Which seems to be a case for integrating both a bit more? Regards, Birger
