[Date Prev][Date Next]
Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- To: "Howard Chu" <firstname.lastname@example.org>
- Subject: Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- From: "Pierangelo Masarati" <email@example.com>
- Date: Mon, 28 Nov 2005 10:36:00 +0100 (CET)
- Cc: "Kurt D. Zeilenga" <kurt@OpenLDAP.org>, "OpenLDAP devel list" <openldap-devel@OpenLDAP.org>
- Importance: Normal
- In-reply-to: <438AC745.firstname.lastname@example.org>
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20498EEB4C91E6CD7543390E@cadabra-dsl.stanford.edu> <email@example.com> <0F84CCF877D1F094219160DC@cadabra-dsl.stanford.edu> <1132493739.3316.112.camel@ando> <F5A02675FC28DA7864C3438C@cadabra-dsl.stanford.edu> <1132505214.3316.117.camel@ando> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <1132590414.3330.4.camel@ando> <email@example.com> <firstname.lastname@example.org> <1132592221.3330.14.camel@ando> <1132594689.6044.6.camel@ando> <email@example.com> <1133163684.3318.10.camel@ando> <438AC745.firstname.lastname@example.org>
- User-agent: SquirrelMail/1.4.3a-1
> This discussion seems to be getting cloudier. There are some key
> differences between proxying and chaining, and the necessary solutions
> for each are not identical.
> Chaining is performed between cooperating DSAs. The collection of DSAs
> is conceptually a single DSA with a single homogeneous namespace. Any
> DSA in the collection can receive requests from any DUA, Binds can be
> chained, and the validated DUA credentials are usable across all the
> DSAs. In this environment, cascading / nesting isn't needed - the DSAs
> all trust each other and the DUA identity can be passed around as a
> simple assertion.
Here we're talking about chaining, and the remote DSA allows the local one
to assert the DUA's identity. The fact that proxying and chaining are
implemented by the same component(s), that is back-ldap + some overlay,
doesn't mean they are the same. An essential difference is, for example,
in asserting the DUA's identity, which is left to the administrator. When
identity assertion is present, it is somehow implicit that a trust exists
between the remote DSA and the proxy.
> Proxying is performed between alien DSAs - the target server has no
> special administrative or trust relationship with the requesting server.
> To the target DSA, the proxy server is just another DUA. Ideally the
> proxy server doesn't touch the operation at all, and just forwards it
> from the client to the target (which means the proxy server must also
> forward Bind requests from the client). In the case where the proxy
> server has been given its own credentials by the target server, allowing
> it to perform proxy authorization, I can see where cascading
> authorizations may make sense. It seems a bit ugly to me, and I wonder
> how often this is actually useful.
> At any rate, I don't believe the single proxyAuthz control is
> appropriate for both proxying and chaining purposes.
OK, cascading __is__ ugly; I'd prefer "nesting" controls. The entire
procedure makes sense to me, because the overall "chaining" may require
many steps, any of which MUST be performed with the appropriate identity.
In the case above, the actual write MUST occur with the DUA's identity (in
this case, asserted by the DSA that originally received the operation, and
propagated as a control on the chainedOperation, not in the original
operation (I think "sub-operation" is the right wording here). The point
is that what I was initially trying to design is an aggregate operation
which apparently is not simply a chaining of the original operation, but
something more, i.e. the chaining of an operation + a sync; where the sync
could be reduced to a post-read and thus make the whole thing look like it
couldbe done with a single operation with appropriate controls. The more
I think about it, the more I get convinced it is not.
I'm getting convinced that what we need is the "grouping"
<draft-zeilenga-ldap-grouping> (*) of a chianingOperation and a read, both
performed with the same identity (that of the replicator); the chaining
would bring a control that asserts the DUA identity, and the sub-operation
would be allowed to contain further proxyAuthz provided by the DUA itself.
(*) I haven't read <draft-zeilenga-ldap-grouping> carefully enough to be
sure it aswers this design problem, so please don't take it as granted.
Ing. Pierangelo Masarati
Responsabile Open Solution
Via Dossi, 8 - 27100 Pavia - ITALIA