directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ersin Er" <>
Subject Re: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Date Thu, 03 May 2007 09:48:21 GMT
On 5/3/07, Alex Karasulu <> wrote:
> Hi,
> On 5/2/07, Ersin Er <> wrote:
> > Alex,
> >
> > Bringing this mail again to your attention. Please let me know is
> > there is any pb.
> OK more in line ...
> >
> > So, now, regarding to subtreeSpecification related components in ACIs.
> So these are the subterms in the perscriptiveACI attribute syntax and not
> the subtreeSpecification attribute in the ACI subentry.  This I think is
> where
> the confusion lies.
> What I am saying is the subtreeSpecification attribute in the ACI subentry
> supports refinements using the full LDAP filter which you extended.  However
> the inner elements for classes and subtree inside the prescriptiveACI do
> not.
> This is what I would like to clarify.
> > They have not been effected by this change because they cannot be and
> > we did not want also.
> Can you explain why we should not do this?

Well, here is what X.501 says:

SubtreeSpecification does not allow subtree refinement because a
refinement might require a DSA
to use a distributed operation in order to determine if a given user
is in a particular user class. Basic Access
Control is designed to avoid remote operations in the course of making
an access control decision. Membership
in a subtree whose definition includes only base and chop can be
evaluated locally, whereas membership in a
subtree definition using specificationFilter can only be evaluated by
obtaining information from the user's entry
which is potentially in another DSA.

I am not totally sure if this applies to ApacheDS but by trusting the
completeness of the spec we did never tried to extend the 'subtree'
user class to include specification filter.

> > There are two components that may come to mind
> > about this change. First is the "classes" protected item and the
> > second one is "subtree" user class. The "classes" protected item has
> > the refinement syntax and it is really used for specifying a boolean
> > combination of object classes. It can never include regular attributes
> > other than object class values.
>  I know X.500 syntax does not allow it but what prevents us from extending
> it as well to use the full LDAP filter instead?  Just curious btw and not
> suggesting
> that we do it.

"classes" is really used for what refinements are intended to be used.
We can still allow regular LDAP filters here but it will just relax
the grammar, it won't provide any more power. Because "classes" is
only used for specifying a logical combination of objectClass values.

> Alex


View raw message