[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: Pierangelo Masarati <email@example.com>
- Subject: Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)
- From: Howard Chu <firstname.lastname@example.org>
- Date: Mon, 28 Nov 2005 01:00:53 -0800
- Cc: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>, OpenLDAP devel list <openldap-devel@OpenLDAP.org>
- In-reply-to: <1133163684.3318.10.camel@ando>
- 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>
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051027 SeaMonkey/1.1a
Pierangelo Masarati wrote:
On Mon, 2005-11-21 at 11:13 -0800, Kurt D. Zeilenga wrote: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.
In theory, the slave could attach a post-readEntry control to
chaining operation wrapping the the modify request and use
the returned entry to "pre-sync" the value. Of course,
syncrepl would then need to ignore changes to that
entry that have an later CSN.
Note that use with a chaining operation is necessary here
for two reasons:
1) to avoid conflict with any client provided read
entry control, and
2) appropriate authorization (e.g., as slave not
Of course, the devil is in the details.
Talking about details, one of the reasons we'd need a chaining operation
is to avoid conflicts with client provided controls; it seems, from your
suggestion, that the authorization as the client should be added by the
chaining layer to the client's operation (the sub-operation), thus
potentially conflicting with client-provided authorizations. If we were
to add the authorization to the outer controls set (those of the
chaining operation) then the post-read would still occur with the
client's identity, and the whole thing would not work. The chaining
operation would need the possibility to handle layers of nesting for
things like controls, so that:
- layer 1: ... (<none>)
- layer 2: proxyAuthz; ...
- layer 2: ... (<none>)
- layer 1: postRead; ...
In this case, the scope of the postRead would be outside that of the
proxyAuthz, so the original identity (i.e. that of the replicator) would
be used instead of that of the client.
Another possibility is to extend <draft-weltman-ldapv3-proxy> to support
cascaded authorizations, so that a sequence of identities can be
provided instead of just one, and they are applied in the provided
order, each time applying server side constraints (that is,
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
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.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/