[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: proxyAuthz propagation in back-ldap



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.

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).

4) proxy authenticates, forwards as client
   Proxy establishes its identity with the remote and forwards
   client access requests with client identity (using proxy
   control).


At 05:54 PM 12/10/2003, Howard Chu wrote:
>> (The proxy anonymous, client authenticated case is
>> nonsense.)
>
>In a *chaining* situation that's true. In a *proxy* situation this is a very
>common use.

I'm referring here to the case where the proxy has an anonymous
association but attempts to forward requests under the client
identity (with a proxy control).

>We need to be conscious of the fact that chaining and proxying are driven by
>two very different purposes, even though there may be overlap in how they are done.

This is why I'm enumerating cases...  but I distinguish chaining
and proxying a bit differently than you.  (I used proxy above
with regard to this difference.)

>Chaining is really about coordinated distributed operation - a single DIT is
>fragmented and distributed across a body of servers, all of whom are
>explicitly set up to trust each other and cooperatively serve the original
>DIT - it's inherent in X.500, it's alien to the LDAP worldview.

Yes.


>Proxying is about tunneling from one namespace to a foreign namespace.

I view proxying all about supporting application-level gateways,
such as an LDAP-aware load-balancer.  But other, I think we agree.
Proxying is transparent to the remote server(s).


>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.

>Currently if slapd
>receives multiple instances, they will be processed in order.

But the specification defines no semantics of their order.

>As such, if the
>client-supplied proxy control is handled after the back-ldap inserted proxy
>control, the result will be as desired.

The problem here is that the proxy has no way to tell which
control failed if the remote reports a proxy authorization
error.

Kurt