RE: back-ldap connection caching, proxy controls?

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Pierangelo Masarati [mailto:masarati@aero.polimi.it]

> Howard,
>
> sorry for replying so late to your message; I set it aside
> because I wanted to think about it, and urgent things overcame
> it.

No problem, I've had plenty to keep me busy in the meantime...

> Your point should be clear, I guess; actually there's one flaw
> even in repeatedly doing binds with the same handle: think what
> happens if a system is (mis)configured like
>
> access to attrs=userPassword
> 	by anonymous auth
> 	by users none
>
> which would result in successful first bind and unsuccessful
> following binds.

No system is foolproof. We can't protect sysadmins from shooting themselves
in the foot, they will find a way to do so no matter what...

> Another point is that pam_ldap, auth_ldap and
> so usually do a search followed by a bind, because users usually
> know their userid, not their dn (exploiting the rewrite features
> of back-ldap/back-meta you could turn a dn-looking userid into a
> dn before bind takes place ;).

Yes, I see that. I'm taking a different approach to develop an LDAP-plugin
for the SASL library - I perform a SASL bind as the user and then use the
WhoAmI extended op to get the user's DN. Requires fewer ops than the anon
search/bind approach. This is an approach I thought of for the back-ldap
proxy, but it's coming in handy for the sasldb replacement:
	1. plugin creates TLS LDAP session, with local certificate
	2. plugin authenticates to LDAP server using SASL EXTERNAL
	3. if 1 and 2 succeed, then plugin init is considered a success
	4. the LDAP session is kept, not discarded.

For a sasldb_getdata() request, which passes authid, realm, and
propertyname,
reuse the existing LDAP session.
	1. plugin authenticates to LDAP server using SASL EXTERNAL, supplying
	   user's authcid as the SASL authzid. Since the session has been
	   established already, SASL EXTERNAL authentication imposes nearly zero
	   overhead.
      2. plugin asks LDAP "WhoAmI?"
	3. plugin does ldapsearch on returned DN, for attribute named
"propertyname" and returns the value to SASL.

The sasldb_putdata() request is the same except step 3 uses ldapmodify
instead of ldapsearch.

Of course, the trick here is that the plugin principal that's used to
contact the LDAP server must have permission to authorize itself as any
user. Note that this is an LDAP transaction for the purpose of retrieving a
user's secret, which can then be used by the SASL library in authenticating
the user. So we can't just bind to LDAP with the user's secret, because no
one knows it yet...

The major advantage to this approach is that it avoids needing to configure
search parameters into the plugin, for mapping uid's to DNs... All of that
is kept on the LDAP server, and doesn't need to be copied/configured/managed
anywhere else. Of course, there are plenty of holes here; I've only just
begun the code and haven't exercised it (mentally or actually) very much
yet. It may still be simpler in the long run to configure searches for the
UID but my method will frequently be more efficient.

> What about caching handles based
> on bound dn? If a connection comes with a certain dn, and there's
> already one for that dn it could be reused (mutex-protected); when
> a bind takes place for a dn that's not cached yet, a new handle
> could be created and added to the cache (as soon as the bind
> succeeds).

That's OK, up to a limit. We don't want to consume too many sockets on the
client and certainly not on the server. That's why my preference is to do
things X.500-style with a single connection, and authIDs associated with
each operation. The alternative I've come up with is to use two connections;
one for the privileged ID that can search for UIDs, and one that is
continually rebound as the user of interest to perform modifications.
>
> This approach, although fairly simple (maybe I'm missing some key
> point) should be fairly feasible; this could also lead to
> bund dn/related caches, because what prevents cacheing in back-ldap
> is actually the fact that search results may vary based on the
> bound dn.

We need to keep the number of cached connections very small. That's the only
catch with your straightforward suggestion.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support