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
