You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Ersin Er <er...@gmail.com> on 2007/04/06 18:50:44 UTC
[ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Hi all,
As PAM and Stefan are close to finishing the ACI editor, they have
asked me a few questions about the "extended" subtree specification I
introduced in 1.5. Although I have explained these changes on JIRA and
IRC, I wanted to record them here on the list also.
What we did in 1.5 branch about Subentries and subtreeSpecifications
in particular is allowing regular LDAP filters to be used in the
specification instead of refinements. Refinements can only be used to
specify boolean combinations of object classes. However it is obvious
that in this new "flat" directory world, people would like to "select"
portions of the DIT via any entry attributes as well as objectClass.
So people would like to be able to specify a set of entries to protect
via ACIs not only saying "those persons (according to objectClass
attribute)" but also saying "those persons who are from X department
(according to some user attribute)". This is what we provided.
So, now, regarding to subtreeSpecification related components in ACIs.
They have not been effected by this change because they cannot be and
we did not want also. 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. So it does not have to support the
LDAP filter syntax. The "subtree" user class, although it has
subtreeSpecification syntax (particularly), it does not even support
refinements; so there is nothing to be replaced with ldap filters.
I hope it's clear.
--
Ersin
Re: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Posted by Ersin Er <er...@gmail.com>.
You'are totally right. I will update it this weekend.
Thanks!
On 4/6/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> Ersin,
>
> This is an important mail, so I thank you for sharing those informations
> with us.
>
> Just a question : is this also possible that the wiki be updated ? I don't
> really know if it reflects all what you have put in the code, but as pam and
> stefan are working on it, it seems to be good timing to feed the wiki if
> it's not up to date.
>
> Just to be sure that more and more people get the information about ACIs, as
> ACIEditor will be one of he most interesting feature we are providing with
> ADS 1.5/LS 0.8
>
> Thanks !
>
> Regards,
> --
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
--
Ersin
Re: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Posted by Emmanuel Lecharny <el...@gmail.com>.
Ersin,
This is an important mail, so I thank you for sharing those informations
with us.
Just a question : is this also possible that the wiki be updated ? I don't
really know if it reflects all what you have put in the code, but as pam and
stefan are working on it, it seems to be good timing to feed the wiki if
it's not up to date.
Just to be sure that more and more people get the information about ACIs, as
ACIEditor will be one of he most interesting feature we are providing with
ADS 1.5/LS 0.8
Thanks !
Regards,
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS][Core] About the "extended" subtree specifications
w.r.t. several ACI components
Posted by Stefan Seelmann <se...@apache.org>.
Ersin, thanks for the clear explanation.
As you are our ACI expert, could you please test the current version of
the ACI editor and give PAM and me some feedback?
Here is a confluence page with the implemented and missing features:
http://cwiki.apache.org/confluence/display/DIRxSTUDIO/ACI+Editor+Plugin+Developer+Discussion
Thanks,
Stefan
Ersin Er schrieb:
> Hi all,
>
> As PAM and Stefan are close to finishing the ACI editor, they have
> asked me a few questions about the "extended" subtree specification I
> introduced in 1.5. Although I have explained these changes on JIRA and
> IRC, I wanted to record them here on the list also.
>
> What we did in 1.5 branch about Subentries and subtreeSpecifications
> in particular is allowing regular LDAP filters to be used in the
> specification instead of refinements. Refinements can only be used to
> specify boolean combinations of object classes. However it is obvious
> that in this new "flat" directory world, people would like to "select"
> portions of the DIT via any entry attributes as well as objectClass.
> So people would like to be able to specify a set of entries to protect
> via ACIs not only saying "those persons (according to objectClass
> attribute)" but also saying "those persons who are from X department
> (according to some user attribute)". This is what we provided.
>
> So, now, regarding to subtreeSpecification related components in ACIs.
> They have not been effected by this change because they cannot be and
> we did not want also. 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. So it does not have to support the
> LDAP filter syntax. The "subtree" user class, although it has
> subtreeSpecification syntax (particularly), it does not even support
> refinements; so there is nothing to be replaced with ldap filters.
>
> I hope it's clear.
>
Re: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Posted by Alex Karasulu <ak...@apache.org>.
On 5/3/07, Ersin Er <er...@gmail.com> wrote:
>
> On 5/3/07, Alex Karasulu <ak...@apache.org> wrote:
> > Hi,
> >
> > On 5/2/07, Ersin Er <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
Re: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Posted by Ersin Er <er...@gmail.com>.
On 5/3/07, Alex Karasulu <ak...@apache.org> wrote:
> Hi,
>
> On 5/2/07, Ersin Er <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. 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
>
--
Ersin
Re: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Posted by Alex Karasulu <ak...@apache.org>.
Hi,
On 5/2/07, Ersin Er <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?
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.
Alex
Fwd: [ApacheDS][Core] About the "extended" subtree specifications w.r.t. several ACI components
Posted by Ersin Er <er...@gmail.com>.
Alex,
Bringing this mail again to your attention. Please let me know is
there is any pb.
---------- Forwarded message ----------
From: Ersin Er <er...@gmail.com>
Date: Apr 6, 2007 7:50 PM
Subject: [ApacheDS][Core] About the "extended" subtree specifications
w.r.t. several ACI components
To: Apache Directory Developers List <de...@directory.apache.org>
Hi all,
As PAM and Stefan are close to finishing the ACI editor, they have
asked me a few questions about the "extended" subtree specification I
introduced in 1.5. Although I have explained these changes on JIRA and
IRC, I wanted to record them here on the list also.
What we did in 1.5 branch about Subentries and subtreeSpecifications
in particular is allowing regular LDAP filters to be used in the
specification instead of refinements. Refinements can only be used to
specify boolean combinations of object classes. However it is obvious
that in this new "flat" directory world, people would like to "select"
portions of the DIT via any entry attributes as well as objectClass.
So people would like to be able to specify a set of entries to protect
via ACIs not only saying "those persons (according to objectClass
attribute)" but also saying "those persons who are from X department
(according to some user attribute)". This is what we provided.
So, now, regarding to subtreeSpecification related components in ACIs.
They have not been effected by this change because they cannot be and
we did not want also. 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. So it does not have to support the
LDAP filter syntax. The "subtree" user class, although it has
subtreeSpecification syntax (particularly), it does not even support
refinements; so there is nothing to be replaced with ldap filters.
I hope it's clear.
--
Ersin
--
Ersin