[Date Prev][Date Next]
RE: Referal chaining
At 12:22 PM 5/17/00 -0700, Howard Chu wrote:
>On top of this, if referral chaining was turned on, the referral-caching
>backend would propagate the request and return the result. Chaining was
>always done anonymously, which made it somewhat less than useful.
>Unfortunately there's still no obvious way to fix this.
SASL authentication supports separation of authentication and authorization
identities. Hence, a chaining server can authenticate as itself and provide
the client's authorization identity. The chained server can then
authenticate the chaining server and, if appropriate, grant rights
associated with the provided authorization identity.
Problem with this approach, of course, is the separate session
is needed per authorization identity.
However, there are other approaches... such as using a control to
provide the authorization identity which allow one connection
to be used to chain requests. I think there was an I-D on this
subject... but it's likely expired.
>What we really need
>is DSP on TCP; trying to use a client access protocol for inter-server
>operation is just nuts...
I think having N protocols is nuts. Most inter-server operations can
be mapped onto LDAP and, where not, LDAP can be extended. You can
even define an extended operation to allow LDAP requests to be sent
(and responded to) in both directions. In fact, this is one way
that client-initiated, server-pushed replication could be implemented.
One shouldn't think of LDAP as being restrictive in capability, but
a framework for building new functionality upon.
Anyways, getting back to the subject of chaining implementation
in OpenLDAP... I think it would be quite difficult to implement
well under the current architecture. However, I think the
problems set (dumb clients) often solved through chaining can
be solved other ways, such as use of a proxy. Implementing
an LDAP proxy, using SLAPD as the server side protocol engine
is quite implementable in OpenLDAP. With back-ldap, you even
have a prototype.