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

Re: direct local change when a consumer chains a write to the producer? (Was: openldap-server-2.2.29: multimaster support)



Pierangelo Masarati wrote:
On Mon, 2005-11-21 at 11:13 -0800, Kurt D. Zeilenga wrote:
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
        client).

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:

chainedOperation
    - layer 1: ... (<none>)
        - layer 2: proxyAuthz; ...
            ...
                - sub-operation
            ...
        - layer 2: ... (<none>)
    - layer 1: postRead; ...
chainedResponse

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,
authzTo/AuthzFrom policies).
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.

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/