src/site/xdoc/docs/developers/aci_notesfromx501 - directory-server - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>

 <document>
   <properties>
     <author email="akarasulu">akarasulu</author>
     <title>Access Control Notes from X.501</title>
   </properties>
   <body>
     <section heading="h2" name="Access Control Scheme Operational Attribute: accessControlScheme">
       <p>
 Below is a snipet from X.501 which talks about an accessControlScheme
 attribute:</p>
       <p>
 The Directory provides a means for the access control scheme in force in a
 particular portion of the DIB to be identified through the use of the
 operational attribute accessControlScheme. The scope of such a scheme is defined
 by an Access Control Specific Area (ACSA), which is a specific administrative
 area that is the responsibility of the corresponding Security Authority. This
 attribute is placed in the Administrative Entry for the corresponding
 Administrative Point. Only administrative entries for Access Control Specific
 Points are allowed to contain an accessControlScheme
 attribute.</p>
       <p>
 This translates to having an operational attribute, *accessControlScheme*,
 within the entry at the administrative point.  This value of this attribute is
 an OID.  The ASN.1 for the attribute is defined below within section 17.2.2.  We
 specifically need an LDAP attributeType specification for this ASN.1 definition
 for the attribute so we can add it to the Administrative
 Point.</p>
       <source>accessControlScheme ATTRIBUTE ::= {
        WITH SYNTAX                                  OBJECT IDENTIFIER
        EQUALITY MATCHING RULE                       objectIdentifierMatch
        SINGLE VALUE                                 TRUE
        USAGE                                        directoryOperation
        ID                                           id-aca-accessControlScheme }
 </source>
       <p>
 For basic access control the X.501 attribute will contains the value
 *basic-access-control*.  However for LDAP we can represent the value as
 *basicAccessControl* and assign it an OID to specifically identify this value.
 Below is the definition for the LDAP
 attributeType:</p>
       <source>attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.14 NAME 'accessControlScheme'
   DESC 'Access control scheme in force for a ACSA'
   EQUALITY objectIdentifierMatch
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
   USAGE directoryOperation )
 </source>
     </section>
     <section heading="h2" name="Protected Items">
       <table>
         <tr>
           <th>
 Protected
 Items</th>
         </tr>
         <tr>
           <td>
 Entries</td>
         </tr>
         <tr>
           <td>
 Attributes</td>
         </tr>
         <tr>
           <td>
 Attribute
 Values</td>
         </tr>
         <tr>
           <td>
 Names</td>
         </tr>
       </table>
     </section>
     <section heading="h2" name="Aspects of permission categories">
       <ol nesting="0">
         <li>
 All operations except delete and modifyDn operations need both entry and
 attribute level
 access.</li>
         <li>
 To perform Directory operations that require access to attributes or attribute
 values, it is necessary to have entry access permission to the entry or entries
 that contain those attributes or values.  Note the removal of an entry or an
 attribute does not require access to the values of an
 attribute.</li>
         <li>
 Without an explicit grant access is denied.  Everything is closed from the
 start.  Denials override grants if precedence is the
 same.</li>
       </ol>
     </section>
     <section heading="h2" name="Permission Categories for Entry Access"/>
     <section heading="h2" name="Subentry Access Control: subentryACI">
       <p>
 The subentryACI operational attribute would reside within entries of
 administrative points and applies only to immediately subordinate subentries.
 This is specified within section 18.5.3 of
 X.501.</p>
       <p>
 Conversely perscriptiveACIs in subentries never apply to subentries of the same
 administrative point however they may apply to the subentries of inner areas.
 See section 18.5.3 of X.501.  This section is small enough to include
 here:</p>
       <p>
 Subentry ACI attributes are defined as operational attributes of administrative
 entries, and provide access control information that applies to each of the
 subentries of the corresponding administrative point. Prescriptive ACI within
 the subentries of a particular administrative point never applies to the same or
 any other subentry of that administrative point, but can be applicable to the
 subentries of subordinate administrative points. Subentry ACI attributes are
 contained only in administrative points and do not affect any element of the DIT
 other than immediately subordinate
 subentries.</p>
       <p>
 In evaluating access control for a specific subentry, the ACI that shall be
 considered
 is:</p>
       <ul nesting="1">
         <li>
 the entryACI within the subentry itself (if
 any);</li>
         <li>
 the subentryACI within the associated administrative entry (if
 any);</li>
         <li>
 prescriptiveACI associated with other relevant administrative points within the
 same access control specific area (if
 any).</li>
       </ul>
       <source>subentryACI  ATTRIBUTE  ::=  {
  WITH SYNTAX    ACIItem
  EQUALITY MATCHING RULE    directoryStringFirstComponentMatch
  USAGE     directoryOperation
  ID      id-aca-subentryACI }
 </source>
       <p>
 What this means is we have to process access controls differently for
 subentries.  So for a subentry we apply the entryACI as we do with other entry
 types.  Then we need to apply the subentyACI within the parent which is the
 administrative point
 entry.</p>
       <p>
 Now how we apply perscriptiveACI to subentries is a bit ambiguous.  The subentry
 subsystem does not inject operational attributes into subentries as it does for
 regular entries.  Regular entries included by the subtree specification of
 subentries have the operational attributes associated with administrativeRoles
 added to the included entry.  These opattrs hold a DN to the including subentry.
 This will not occur for entries that are subentries.  At a cursory glance
 imposes some
 problems.</p>
       <p>
 First of all, we cannot link a subentry A in an outter administrative point to a
 target subentry B included by the subtreeSpecification of the first subentry A.
 This however may not really be necesary to do.  This is why the X.501 spec is
 somewhat ambiguous when things boil down to an implementation.  Technically a
 subentry is at the same context as its superior administrative point.  If that
 is the case, then all subentries including the administrative point also
 includes the subentries.  Effectively for our implementation, this means that
 subentries can use the accessControlSubentries operational attribute (if
 present) within the administrative entry to discover perscriptiveACI's effecting
 subentries.</p>
     </section>
   </body>
 </document>
	<?xml version="1.0" encoding="UTF-8"?>

	<document>
	<properties>
	<author email="akarasulu">akarasulu</author>
	<title>Access Control Notes from X.501</title>
	</properties>
	<body>
	<section heading="h2" name="Access Control Scheme Operational Attribute: accessControlScheme">
	<p>
	Below is a snipet from X.501 which talks about an accessControlScheme
	attribute:</p>
	<p>
	The Directory provides a means for the access control scheme in force in a
	particular portion of the DIB to be identified through the use of the
	operational attribute accessControlScheme. The scope of such a scheme is defined
	by an Access Control Specific Area (ACSA), which is a specific administrative
	area that is the responsibility of the corresponding Security Authority. This
	attribute is placed in the Administrative Entry for the corresponding
	Administrative Point. Only administrative entries for Access Control Specific
	Points are allowed to contain an accessControlScheme
	attribute.</p>
	<p>
	This translates to having an operational attribute, accessControlScheme,
	within the entry at the administrative point. This value of this attribute is
	an OID. The ASN.1 for the attribute is defined below within section 17.2.2. We
	specifically need an LDAP attributeType specification for this ASN.1 definition
	for the attribute so we can add it to the Administrative
	Point.</p>
	<source>accessControlScheme ATTRIBUTE ::= {
	WITH SYNTAX OBJECT IDENTIFIER
	EQUALITY MATCHING RULE objectIdentifierMatch
	SINGLE VALUE TRUE
	USAGE directoryOperation
	ID id-aca-accessControlScheme }
	</source>
	<p>
	For basic access control the X.501 attribute will contains the value
	basic-access-control. However for LDAP we can represent the value as
	basicAccessControl and assign it an OID to specifically identify this value.
	Below is the definition for the LDAP
	attributeType:</p>
	<source>attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.14 NAME 'accessControlScheme'
	DESC 'Access control scheme in force for a ACSA'
	EQUALITY objectIdentifierMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
	USAGE directoryOperation )
	</source>
	</section>
	<section heading="h2" name="Protected Items">
	<table>
	<tr>
	<th>
	Protected
	Items</th>
	</tr>
	<tr>
	<td>
	Entries</td>
	</tr>
	<tr>
	<td>
	Attributes</td>
	</tr>
	<tr>
	<td>
	Attribute
	Values</td>
	</tr>
	<tr>
	<td>
	Names</td>
	</tr>
	</table>
	</section>
	<section heading="h2" name="Aspects of permission categories">
	<ol nesting="0">
	<li>
	All operations except delete and modifyDn operations need both entry and
	attribute level
	access.</li>
	<li>
	To perform Directory operations that require access to attributes or attribute
	values, it is necessary to have entry access permission to the entry or entries
	that contain those attributes or values. Note the removal of an entry or an
	attribute does not require access to the values of an
	attribute.</li>
	<li>
	Without an explicit grant access is denied. Everything is closed from the
	start. Denials override grants if precedence is the
	same.</li>
	</ol>
	</section>
	<section heading="h2" name="Permission Categories for Entry Access"/>
	<section heading="h2" name="Subentry Access Control: subentryACI">
	<p>
	The subentryACI operational attribute would reside within entries of
	administrative points and applies only to immediately subordinate subentries.
	This is specified within section 18.5.3 of
	X.501.</p>
	<p>
	Conversely perscriptiveACIs in subentries never apply to subentries of the same
	administrative point however they may apply to the subentries of inner areas.
	See section 18.5.3 of X.501. This section is small enough to include
	here:</p>
	<p>
	Subentry ACI attributes are defined as operational attributes of administrative
	entries, and provide access control information that applies to each of the
	subentries of the corresponding administrative point. Prescriptive ACI within
	the subentries of a particular administrative point never applies to the same or
	any other subentry of that administrative point, but can be applicable to the
	subentries of subordinate administrative points. Subentry ACI attributes are
	contained only in administrative points and do not affect any element of the DIT
	other than immediately subordinate
	subentries.</p>
	<p>
	In evaluating access control for a specific subentry, the ACI that shall be
	considered
	is:</p>
	<ul nesting="1">
	<li>
	the entryACI within the subentry itself (if
	any);</li>
	<li>
	the subentryACI within the associated administrative entry (if
	any);</li>
	<li>
	prescriptiveACI associated with other relevant administrative points within the
	same access control specific area (if
	any).</li>
	</ul>
	<source>subentryACI ATTRIBUTE ::= {
	WITH SYNTAX ACIItem
	EQUALITY MATCHING RULE directoryStringFirstComponentMatch
	USAGE directoryOperation
	ID id-aca-subentryACI }
	</source>
	<p>
	What this means is we have to process access controls differently for
	subentries. So for a subentry we apply the entryACI as we do with other entry
	types. Then we need to apply the subentyACI within the parent which is the
	administrative point
	entry.</p>
	<p>
	Now how we apply perscriptiveACI to subentries is a bit ambiguous. The subentry
	subsystem does not inject operational attributes into subentries as it does for
	regular entries. Regular entries included by the subtree specification of
	subentries have the operational attributes associated with administrativeRoles
	added to the included entry. These opattrs hold a DN to the including subentry.
	This will not occur for entries that are subentries. At a cursory glance
	imposes some
	problems.</p>
	<p>
	First of all, we cannot link a subentry A in an outter administrative point to a
	target subentry B included by the subtreeSpecification of the first subentry A.
	This however may not really be necesary to do. This is why the X.501 spec is
	somewhat ambiguous when things boil down to an implementation. Technically a
	subentry is at the same context as its superior administrative point. If that
	is the case, then all subentries including the administrative point also
	includes the subentries. Effectively for our implementation, this means that
	subentries can use the accessControlSubentries operational attribute (if
	present) within the administrative entry to discover perscriptiveACI's effecting
	subentries.</p>
	</section>
	</body>
	</document>