directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject [AdminPoint] introduction
Date Fri, 17 Dec 2010 13:35:31 GMT
Hi guys,

instead of one big mail, I'll post many small ones, otherwise it will be 
a major PITA for us to comment it and even to read it.

This mail is an introduction about the AP management, as I see it.

Introduction
------------
Note : the X.500 Administrative Model tells that even the subentries are 
controlled by the AdministrativeModel. ADS in this current version does 
not do such a control. Manipulating a Subentry and an 
AdministrativePoint is an administrator task, and then an administrator 
can do anything on those elements.

Subentries can be read by all the users, except of course if the use 
can't access its parent entries, or one of its parent's parents.

 From the security POV, allowing a normal user to read a Subentry is not 
very good, but there is a way to forbid such action, defining a specific 
Subentry with some exclusion applied on a subtree selecting only the 
entries containing a Subentry ObjectClass. It my be a good policy to 
define such an ACI-SAP at the top level.

One more thing : for every operation, we must deal with each role 
separately. That means an AP for CollectiveAttribute does not span on 
the same area than the AP for a AccessControl, and the associated areas 
may overlap. If the operation is done on a AAP,  as an AAP is an AP 
representing all the SAP, then we have to consider we have an operation 
applied on all the SAPs.

NOTE : An AP may have more than one subentry for a specific role. X.500 
also says that a subentry can also be used to handle more than one 
specific role, which is done by having more than one auxiliary 
ObjectClass being added in the subentry. That complexify the management 
of subentries...

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message