directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Date Thu, 03 May 2007 10:30:15 GMT
On 5/3/07, Ersin Er <ersin.er@gmail.com> wrote:
>
> On 5/3/07, Alex Karasulu <akarasulu@apache.org> wrote:
> > Hi,
> >
> > On 5/2/07, Ersin Er <ersin.er@gmail.com> 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.


Ahhhh yes yes this is important ... it would seriously make ACI calculations
slow down the server.

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.


Ok np it is now clear to me.  Thanks for being such a good student of X.500
.

> > 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.


Right it would  be senseless to do so.

Alex

Mime
View raw message