directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@apache.org>
Subject Re: [ApacheDS] [RFC 4370] Why we should implement the "Proxied Authorization Control"
Date Sat, 31 Jan 2009 09:56:36 GMT
Alex Karasulu wrote:
> Hi folks,
>
> Lately we've been thinking about disaster recovery and leveraging the change
> log to recover from partition corruption. We've also mixed into the fray the
> idea of building up a replica after a nascent server is added to a cluster.
> We also spoke about applying the changes in the CL of one server to bring a
> fresh server to some previous state.
>
> In all these cases, and a couple more below,
>
>    - exporting then reimporting
>    - connection pooling
>
>
> there is a distinct need to preserve the identity information associated
> with the creatorsName and the modifiersName. In the above examples, the
> server internally must apply changes in the change log as the identity of
> the creator and modifier.  In most cases timestamps should also be
> preserved. Internally this is easy to do with ApacheDS' API. However it is
> not so easy when changes are coming from outside of the server.  For example
> when bringing a new replica into a cluster and loading it with entries it's
> very hard to preserve the values of these operational attributes.
>   
> Currest State
> -------------------
>
> Some leg work was done to be able to implement a "RunAs" capability in
> ApacheDS. An autorizedPrincipal property and effectivePrincipal was added to
> all operation contexts [0] via a base class.  The authenticatedPrincipal and
> yet another effectivePrincipal is accessible via the CoreSession [1]. The
> DefaultAuthorizationInterceptor [2] was indirectly modified via it's base
> class, BaseInterceptor [3], to leverage the effectivePrincipal.
>
> There needs to be some clarification here as to what all this is about. A
> session must have an authenticated principal and my optionally have an
> authorized principal. The authenticated principal is the principal whose
> credentials were provided to bind after establishing the session.  The
> authorized principal is another identity associated with the session rather
> than with an individual request. There are, I believe, SASL mechanisms that
> would set this authorized principal. When this is the case, operations
> should be performed as the authorized user.  Hence the
> getEffectivePrincipal() method on the CoreSession checks if an authorized
> principal exists and returns that or in it's absence returns the
> authenticated principal.
>
> AbstractOperationContext [0], also contains an authorized principal and has
> access to the CoreSession. These operation contexts represent requests being
> processed. Eventually with the proxied authorization control implemented,
> this authorized principal will be populated when the control is used to
> issue requests. The effectivePrincipal() method on OperationContexts will
> return the authorized principal when it is set at the request level. If it
> has not been set then the session.getEffectivePrincipal() value is returned
> by a context.
>
> Need for Controls
> -------------------------
>
> There is really very little work that remains to implement this great
> control. It's great because it facilitates a single connection to issue
> requests as another user.  This is obviously a huge plus when dealing with
> connection pooling. But more importantly it's a plus when dealing with
> bringing a replica online and up to speed with the contents of it's peers in
> a cluster.  It will allow the a user with the proper authorization power to
> write entries to the DIT with the identity that was originally used to
> perform the operation hence preserving the creatorsName and the
> modifiersName.  This is important to do since these attributes can impact
> auditing, and access controls [4].
>   
We also need this to deal with the DSML gateway, as authentication won't 
come with the request, it has to be deduced from another layer.
> Likewise we should preserve modifyTimestamp and the createTimestamp
> operational attribute.  There is no specification for doing this as far as I
> know but a control which carries with it the timestamps to use can be very
> useful here.  Perhaps this is also something we can explore.
>   
Yep. At the same time, we may optimize the way we are creating or 
modifying those AT, as it's currently done in two steps : first we 
create the entry, and when it's stored into the backend, we create those 
AT and update the created entry (IFAIR)
> Now all these operationalAttributes have the directoryOperation USAGE and
> not distributedOperation or dSAOperation. This is somewhat confusing.  If
> the dSAOperation were used then that would tell us that these values can be
> different for each server.  If distributedOperation was used then it's
> something I would imagine would need to be the same across replicas.
> Although confusing I think these operational attributes must line up across
> replicas in the cluster otherwise you have divergence.
>   
We can bypass the AT type while replicating.
> Stored Procedures and Triggers
> ----------------------------------------------
>
> When we get the SP and trigger story right, the RunAs code will come in very
> handy. For example, an administrator installs a trigger to fire a SP
> whenever an entry is deleted in some region of the DIT. The SP updates
> groups by removing references to the deleted entry.  The groups are
> protected from ACI to prevent anyone but the administrator to make changes.
> When a normal user raises the trigger, that trigger will need to execute the
> SP with the authorization rights of the administrator.  The procedure will
> then execute as the administrator.
>
> Summary
> --------------
>
> This control as well as another to support the preservation of timestamps is
> needed to do several things correctly.  Thankfully we already have some
> foundation to build on so their implementation would not be that involved.
>   
Whatever we do, we need this control. Let's implement the base 
mechanism. I can handle it easily.


-- 
--
cordialement, regards,
Emmanuel L├ęcharny
www.iktek.com
directory.apache.org



Mime
View raw message