directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: ACLs questions
Date Tue, 17 May 2005 23:23:06 GMT
Tony Blanchard wrote:

> I have no idea on  how to do those things now but a thing that I can 
> do is to point out the security requirement  that I told about in a 
> mail on this thread.
> A duplication of the tree should duplicate ACLs.

Exactly!  It has to otherwise replication becomes a nightmare.  This 
however is not a problem for a virtual directory.

> So subentries look better for this.

Subentries are the standard but as Marc points out there might be 
problems.  I have always had intentions for using some of the ou=system 
space to manage alternate forms of ACL information as well as other 
things like schema info while keeping things standard.

Let me give a clear example.  In LDAP up until some recent changes an 
LDAP DSA often had a single subschemaSubEntry.  Meaning it had one place 
(a single entry) to store all its schema information.  This made LDAP 
directories pretty darn weak because there was a single schema for the 
entire DIT.  By default in IPlanet this has been cn=schema.  It is an 
entry with a bunch of attributes describing attributeTypes, 
objectClasses etc. Some servers obviously found ways around this but 
X.500 solved it long before LDAP existed.  There are several problems 
with this approach but the most severe problem is having to parse schema 
information and lots of it.  There could easily be hundreds even 
thousands of schema attributes cramed into this entry.  Pulling the 
entire entry down accidentally can mess up a client pretty bad since the 
entry is huge.

So searching schema info is virtually impossible to do efficiently.  
Even indexing is tough with substring matches being the only savior for 
sellecting the attributes with schema objects you may need.  For example 
asking a question like give me all attributeTypes extending the "name" 
attribute is not such an efficient search to perform even though its on 
a single entry.  There's lots of bloat, its ugly and just shows how poor 
schema handling is in LDAP.

To be compliant we have to expose the schemaSubentry as it is expected.  
However this need not be the primary representation but one that is 
generated.  We intend to create a structured view of schema information 
under the ou=system context where the system partition hangs.  If schema 
objects are designed as entries then they can be searched and indices 
can be taken advantage of to quickly make schema decisions.  Right now 
the system partition uses the default jdbm based implementation but I 
would like to implement this as an in memory backend for speed.  However 
I find if I bump the cache i get the same result for the system partition.

Regardless the moral of the story ... we can use the expected means to 
represent the ACI/ACL using subentries however this need not be the 
operational representation used to evaluate them.  Another more optimal 
form can be used.  Subentry information can then still be replicated and 
the optimal structure can be regenerated upon replicating the ACI.   So 
we can use the system partition and structures there in to make 
evaluation very quick while keeping the information within the subentry. 

> Marc Boorshtein a écrit :
>>>X.500 subentries are recommended to store various
>>>information for an 
>>>autonomous administrative area.  The area can be for
>>>schema, ACLs, or 
>>>collective attributes.  The area of coverage for the
>>>information in the subentry is defined by the
>>>subtree specification 
>>>which includes parameters for chop before, chop
>>>after, and subtree 
>>>refinements.  This is all X.500 stuff that the LDAP
>>>community is 
>>>reintroducing today.  One can almost say there is a
>>>subtle convergence 
>>>going on. 
>>Well, there's allways a difference between
>>"theoretical" truths and "practical" truths.  While it
>>might seem that it makes the most sence to store ACL
>>entries in a subtree, the implementation and
>>performace is not practical.  
Good points but I think we can make up for this with the mechanisms I've 
described above.  Also an AAA need not be additive with clear 
demarcations where the cost of evaluating these ACLs does not cost that 

>>For instance, what if you have an ACL that defines a
>>restriction on reads of the "sn" attribute for
>>anything subtree of "dc=domain,dc=com".  When
>>processing the entry
>>"uid=test,ou=Users,dc=test,dc=domain,dc=com".  You
>>could allways travers the DN backworkds to get all the
>>ACLs and cache those acls so you don't need to find
>>them again in the request, but that seems like a lot
>>of overhead (on top of the ACL processing overhead).
This is where X.500 has already solved some problems for us.  There are 
ways to avoid these problems.  Also there is a big convergence going on 
between the LDAP and X.500 communities now.  LDAP people are admiting 
that not enough of X.500 was adopted and so changes and new RFCs are 
appearing like the one for subentries.  These are within the past couple 
years - still late for LDAP.

The X.500 people have finally given up on OSI and are now looking 
towards simplifying some of the concepts.

>>A second practical issue is managment.  Instead of
>>managing all your ACLs in one place, now you have to
>>manage it on each node.  Seaches could show you all of
>>the acls in a single report, but now it makes
>>management a bit harder.
True but again a single "view" is something that can easily be provided.

>>Finally, what about custom partitions and remote
>>services? (LDAP Proxy, DB Partition).  Now you need
>>each partition to be responsible for it's own ACL
Not at all.  You can define a subentry for the whole partition using the 
base context.  That's why you explicitly must define the base context to 
attach a ContextPartition.

>>So while in a stand alone directory environment with
>>simple ACLs using a sub entry may be the easiest way
>>to go, but when you have a large envuronment with
>>other types of partitions this could become combersome
Marc, I agree the problems are adding up.  However there just does not 
seem to be an easier solution out there at the moment.  It takes more 
than LDAP has given us but we must do it without breaking with the 
protocol.  It is a fine line to walk.  I'm truely all ears for any other 
ideas you or other folks may have on this matter.

>>>If you want to commit to something we can explore
>>>subentries together first.  Next we need to include
>>>support for schema 
>>>structures for subtree specifications and algorithms
>>>for subtree entry 
>>>set inclusion evaluation.  Finally we can begin
>>>talking about 
>>>implementing the actual ACL mechanism - IMO the ACL
>>>mechanism can be 
>>>developed in parallel and stored somewhere else
>>>until we complete these 
>>>components in parallel.  This way Tony can begin
>>>working with us as well.
>>As much as I would like to contribute, I simply don't
>>have time to share anything but my experience.
That's too bad.


View raw message