Re: proxyAttrSet: Only using the LAST value

["Pierangelo Masarati" <ando@sys-net.it>]

>>>>>> "Pierangelo" == Pierangelo Masarati <ando@sys-net.it> writes:
>
>     Pierangelo> I think you need different indices for different
>     Pierangelo> proxyattrset, e.g
>
> I figured that, but I wanted to be absolutely sure. That complicates
> matters, but is feasible. Any plans on simplifying this (my way :)?

That's my understanding; I don't see that much improvement "your way", but
I might be overlooking the whole stuff.

>
>     Pierangelo> I'm not sure about what you can do for that in 2.2,
>     Pierangelo> but note that even 2.3 is not going to forward sasl
>     Pierangelo> authentication anyway.  All it's going to do is to
>     Pierangelo> proxyAuthz __local__ identities, optionally using a
>     Pierangelo> SASL bind as administrative user.  I don't think
>     Pierangelo> proxying SASL binds is at all possible.
>
> He! You said that last time to, and Howard corrected you :).
> http://www.openldap.org/lists/openldap-software/200407/msg00595.html

OK, now I remember.  sasl-regexp IS working (AFAIK) but that's not the
point: in this sense, SASL binds don't even get to the backend.  What I
understand from your needs is that a client talks to a proxy backend for a
SASL bind, and the proxy forwards the talking to a remote server which
actually does the bind.  I see it this way: the client talks to the proxy
DSA, and the __frontend__ takes care of authenticating via the underlying
SASL mech; then regular operations are proxied to the remote server by the
proxy backend.

> Just to be sure. Did something change? Neither of you seemed perfectly
> sure exactly HOW things where...

Not in 2.2 AFAIK.

>
> Maybe I should say 'GSSAPI' here on instead of 'SASL'. I don't care
> about anything else than Kerberos V right now :)

In this sense, 2.2 should work, but possibly not the way you intend it.

> Could you please elaborate on what you mean by 'proxyAuthz __local__
> identities'?

This is a bit obsoleted by the fix I'm about to commit ;) but the identity
assertion of back-ldap used to work as follows:

- a client can auth somehow at the DSA that's acting as proxy (in the
scenario I envisaged while implementing this, there was a local bdb with
local identities);
- the client performs a request that's in the naming context of the remote
server
- the proxy redirects the request there but, since the user is only
authenticated for the local DSA, it would bind anonymously.  The idassert
notes this fact and, after applying user-defined authz rules, binds to the
remote server with an administrative identity, and authorizes as the local
identity (which might, or better should, be unknown at the remote server)
by means of the proxyAuthz control.

- now (5 minutes ago) I allowed also users that were formally
authenticated by the proxy backend (i.e. they scope the proxy naming
context and appear as bound thru it, while they got authenticated via
SASL) to have their identity asserted via proxyAuthz instead.  Otherwise,
at the first non-bind operation, the proxy backend would have tried to
rebind them with empty credentials.  You need (in HEAD) use the

idassert-mode self override

which means: assert the users as themselves binding as the administrative
identity (which can be instructed to use SASL).  I don't know how to make
it use GSSAPI, though.

This is HEAD as of 5 minutes ago.  I made it work with DIGEST-MD5 with
cleartext credentials in the remote server, which I guess it's not what
you'd prefer...

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497