RE: proxyAuthz propagation in back-ldap

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 07:28 PM 12/10/2003, Howard Chu wrote:
>> -----Original Message-----
>> From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
>
>> I see my cases are a bit confusing.  To clarify the access
>> operation cases:
>>
>> 1) proxy anonymous, forwards anonymously
>>    Proxy establishes an anonymous association with the remote,
>>    forwards client access requests (regardless of how the client
>>    is bound to the proxy) under that anonymous association.
>>
>> 2) proxy authenticates, forwards as self
>>    Proxy establishes its identity with the remote and forwards
>>    client access requests (regardless of how the client is
>>    bound to the proxy) under this (the proxy's) association.
>
>OK, now I understand. These are two pretty common proxying cases.
>
>> 3) proxy authenticates, forwards as anonymous
>>    Proxy establishes its identity with the remote and forwards
>>    client requests (regardless of how the client is bound to
>>    the proxy) as anonymous (using proxy control).
>
>I can't imagine a lot of cases where one would want this, instead of (1).

Example: Consider a proxy inside a DMZ.  (Outside) clients
which connect to the proxy must authenticate to it.  It,
because its in the DMZ, has to authenticate to the (inside)
remote.  But the remote doesn't know the clients and/or
the proxy may not want to disclose them to the remote,
so the choice is either to provide no control (same as 2)
or to provide an anonymous control.  The latter allows the
remote to provide less stuff to the remote for this class
of users (and other more stuff to other classes of users,
or then what it might obtain for its own purposes).


>> 4) proxy authenticates, forwards as client
>>    Proxy establishes its identity with the remote and forwards
>>    client access requests with client identity (using proxy
>>    control).
>
>This is the case we want to add support for now.
>
>> >Today things may be a bit different.
>
>> Well, I think we now have enough operational experience in
>> various forms of proxying to take a good stab at chaining.
>
>> >> (note: if the client itself provides a proxy control,
>> >> the proxy should reject the operation (e.g., not chain it)
>> >> (possibly returning 'referral').  Also, each proxy generate
>> >> proxy control should be marked critical.)
>> >
>> >I'm not sure why this is required. The draft spec does not
>> prohibit multiple
>> >instances of this control from appearing in a request.
>>
>> Because the draft doesn't say what the semantics of multiple
>> controls.
>
>> The problem here is that the proxy has no way to tell which
>> control failed if the remote reports a proxy authorization
>> error.
>
>OK, the draft obviously has several holes still. It doesn't even specify what
>result code to return when the control cannot be honored.

I thought the latest version defined a new result code for that.

>I'll take a look thru those chaining docs...
>
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support