directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject svn commit: r329360 - in /directory/apacheds/trunk/xdocs: developers/ users/
Date Sat, 29 Oct 2005 03:08:09 GMT
Author: akarasulu
Date: Fri Oct 28 20:07:59 2005
New Revision: 329360

URL: http://svn.apache.org/viewcvs?rev=329360&view=rev
Log:
generated xdocs

Added:
    directory/apacheds/trunk/xdocs/developers/aci_aciitemabnf.xml   (with props)
    directory/apacheds/trunk/xdocs/developers/aci_aciitemasn1.xml   (with props)
    directory/apacheds/trunk/xdocs/developers/aci_implnotes.xml   (with props)
    directory/apacheds/trunk/xdocs/developers/aci_notesfromx501   (with props)
    directory/apacheds/trunk/xdocs/developers/interceptor_interactions.xml   (with props)
    directory/apacheds/trunk/xdocs/developers/interceptor_mechanism.xml   (with props)
    directory/apacheds/trunk/xdocs/users/aci.xml   (with props)
    directory/apacheds/trunk/xdocs/users/aci_addpermsanyuser.xml   (with props)
    directory/apacheds/trunk/xdocs/users/aci_modifypermsforpasswords.xml   (with props)
    directory/apacheds/trunk/xdocs/users/aci_userclasses.xml   (with props)

Added: directory/apacheds/trunk/xdocs/developers/aci_aciitemabnf.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/developers/aci_aciitemabnf.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/developers/aci_aciitemabnf.xml (added)
+++ directory/apacheds/trunk/xdocs/developers/aci_aciitemabnf.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,183 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="ersiner">ersiner</author>
+    <title>ABNF syntax for LDAP ACIItem</title>
+  </properties>
+  <body>
+    <p>
+The ABNF syntax for LDAP ACIItem is as
+follows:</p>
+    <source>ACIItem = "{" sp aci_identificationTag
+              sep sp aci-precedence
+              sep sp aci-authenticationLevel
+              sep sp aci-itemOrUserFirst sp "}"
+
+aci_identificationTag   = id-identificationTag msp DirectoryString
+
+aci-precedence          = id-precedence msp Precedence
+
+aci-authenticationLevel = id-authenticationLevel msp AuthenticationLevel
+
+aci-itemOrUserFirst = id-itemOrUserFirst msp aci-itemOrUserFirst
+
+aci-itemOrUserFirst = aci-itemFirst / aci-userFirst
+
+aci-itemFirst       = id-itemFirst ":" ItemFirst
+
+aci-userFirst       = id-userFirst ":" UserFirst
+
+ItemFirst = "{" sp aci-protectedItems
+                sep sp aci-itemPermissions sp "}"
+
+UserFirst = "{" sp aci-userClasses
+                sep sp aci-userPermissions sp "}"
+
+aci-protectedItems    = id-protectedItems msp ProtectedItems
+
+aci-itemPermissions   = id-itemPermissions msp ItemPermissions
+
+aci-userClasses       = id-userClasses msp UserClasses
+
+aci-userPermissions   = id-userPermissions msp UserPermissions
+
+ProtectedItems = "{" [ sp aci-entry]
+                     [ sep sp aci-allUserAttributeTypes ]
+                     [ sep sp aci-attributeType ]
+                     [ sep sp aci-allAttributeValues ] 
+                     [ sep sp aci-allUserAttributeTypesAndValues ]
+                     [ sep sp aci-attributeValue ]
+                     [ sep sp aci-selfValue ]
+                     [ sep sp aci-rangeOfValues ]
+                     [ sep sp aci-maxValueCount ]
+                     [ sep sp aci-maxImmSub ]
+                     [ sep sp aci-restrictedBy ]
+                     [ sep sp aci-classes ] sp "}"
+
+ItemPermissions = "{" [ sp ItemPermission
+                        *( sep sp ItemPermission ) sp "}"
+
+ItemPermission = "{" [ sp aci-precedence ]
+                       sep sp aci-userClasses
+                       sep sp aci-grantsAndDenials sp "}"
+
+UserClasses = "{" [ sp aci-allUsers ]
+                  [ sep sp aci-thisEntry ]
+                  [ sep sp aci-Name ]
+                  [ sep sp aci-userGroup ]
+                  [ sep sp aci-subtree ] sp "}"
+
+UserPermissions = "{" [ sp UserPermission
+                        *( sep sp UserPermission ) ] sp "}" 
+
+UserPermission = "{" [ sp aci-precedence ]
+                       sep sp aci-protectedItems
+                       sep sp aci-grantsAndDenials sp "}"
+
+aci-entry                          = id-entry
+
+aci-allUserAttributeTypes          = id-allUserAttributeTypes
+
+aci-attributeType                  = id-attributeType msp AttributeTypes
+
+aci-allAttributeValues             = id-allAttributeValues msp AttributeTypes
+
+aci-allUserAttributeTypesAndValues = id-allUserAttributeTypesAndValues
+
+aci-attributeValue                 = id-attributeValue msp AttributeTypeAndValues
+
+aci-selfValue                      = id-selfValue msp AttributeTypes
+
+aci-rangeOfValues                  = id-rangeOfValues msp Filter
+
+aci-maxValueCount                  = id-maxValueCount msp MaxValueCount
+
+aci-maxImmSub                      = id-maxImmSub msp INTEGER
+
+aci-restrictedBy                   = id-restrictedBy msp RestrictedBy
+
+aci-classes                        = id-classes msp Refinement
+
+aci-grantsAndDenials               = id-grantsAndDenials msp GrantsAndDenials
+
+aci-allUsers                       = id-allUsers
+
+aci-thisEntry                      = id-thisEntry
+
+aci-name                           = id-name msp DistinguishedNames
+
+aci-userGroup                      = id-userGroup msp DistinguishedNames
+
+aci-subtree                        = id-subtree msp SubtreeSpecifications
+
+AttributeTypes = "{" sp AttributeType
+                     *( sep sp AttributeType ) sp "}"
+                     
+AttributeTypeAndValues = "{" sp AttributeTypeAndValue
+                             *( sep sp AttributeTypeAndValue ) sp "}"
+
+MaxValueCount = "{" sp AttributeType
+                    sep sp INTEGER sp "}"
+
+RestrictedBy = "{" sp RestrictedValue
+                   *( sep sp RestrictedValue ) sp "}"
+
+GrantsAndDenials = "{" [ sp GrantAndDenialsBit
+                         *( sep sp GrantAndDenialsBit ) ] sp "}"
+                   ; WARNING: There SHALL NOT be any duplicates
+
+DistinguishedNames = "{" sp DistinguishedName
+                         *( sep sp DistinguishedName ) sp "}"
+                        
+
+SubtreeSpecifications = "{" sp SubtreeSpecification
+                            *( sep sp SubtreeSpecification ) sp "}"
+
+RestrictedValue = "{" sp aci-type
+                      sep sp aci-valuesIn "}"
+
+aci-type     = id-type msp AttributeType
+
+aci-valuesIn = id-valuesIn msp AttributeType
+
+Precedence   = INTEGER(1..255) ; FIXME: How shall we show this ?
+
+AuthenticationLevel = id-none / id-simple / id-strong
+
+GrantAndDenialsBit = id-grantAdd
+                     / id-denyAdd
+                     / id-grantDiscloseOnError
+                     / id-denyDiscloseOnError
+                     / id-grantRead
+                     / id-denyRead
+                     / id-grantRemove
+                     / id-denyRemove
+                     / id-grantBrowse
+                     / id-denyBrowse
+                     / id-grantExport
+                     / id-denyExport
+                     / id-grantImport
+                     / id-denyImport
+                     / id-grantModify
+                     / id-denyModify
+                     / id-grantRename
+                     / id-denyRename
+                     / id-grantReturnDN
+                     / id-denyReturnDN
+                     / id-grantCompare
+                     / id-denyCompare
+                     / id-grantFilterMatch
+                     / id-denyFilterMatch
+                     / id-grantInvoke
+                     / id-denyInvoke
+
+;MYRULE
+;id-X = "X"
+</source>
+    <p>
+Apache Directory Server allows a fully flexible version of this grammar where
+order of named components and amount of spaces (where applicable) do not
+matter.</p>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/developers/aci_aciitemabnf.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/developers/aci_aciitemasn1.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/developers/aci_aciitemasn1.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/developers/aci_aciitemasn1.xml (added)
+++ directory/apacheds/trunk/xdocs/developers/aci_aciitemasn1.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,546 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="ersiner">ersiner</author>
+    <title>ASN.1 syntax for X.501 ACIItem</title>
+  </properties>
+  <body>
+    <section heading="h1" name="ACIItem grammar">
+      <subsection heading="h2" name="ASN.1 Grammar">
+        <p>
+The ASN.1 syntax for ACIItem of X.501 as given in the specificiation is as
+follows</p>
+        <source>ACIItem ::= SEQUENCE {
+	identificationTag DirectoryString { ub-tag },
+	precedence Precedence,
+	authenticationLevel AuthenticationLevel,
+	itemOrUserFirst CHOICE {
+		itemFirst [0] SEQUENCE {
+			protectedItems ProtectedItems,
+			itemPermissions SET OF ItemPermission },
+		userFirst [1] SEQUENCE {
+			userClasses UserClasses,
+			userPermissions SET OF UserPermission } } }
+
+Precedence ::= INTEGER (0..255)
+
+ProtectedItems ::= SEQUENCE {
+	entry                          [0] NULL OPTIONAL,
+	allUserAttributeTypes          [1] NULL OPTIONAL,
+	attributeType                  [2] SET SIZE (1..MAX) OF AttributeType OPTIONAL,
+	allAttributeValues             [3] SET SIZE (1..MAX) OF AttributeType OPTIONAL,
+	allUserAttributeTypesAndValues [4] NULL OPTIONAL,
+	attributeValue                 [5] SET SIZE (1..MAX) OF AttributeTypeAndValue OPTIONAL,
+	selfValue                      [6] SET SIZE (1..MAX) OF AttributeType OPTIONAL,
+	rangeOfValues                  [7] Filter OPTIONAL,
+	maxValueCount                  [8] SET SIZE (1..MAX) OF MaxValueCount OPTIONAL,
+	maxImmSub                      [9] INTEGER OPTIONAL,
+	restrictedBy                   [10] SET SIZE (1..MAX) OF RestrictedValue OPTIONAL,
+	contexts                       [11] SET SIZE (1..MAX) OF ContextAssertion OPTIONAL,
+	classes                        [12] Refinement OPTIONAL }
+
+MaxValueCount ::= SEQUENCE {
+	type AttributeType,
+	maxCount INTEGER }
+
+RestrictedValue ::= SEQUENCE {
+	type AttributeType,
+	valuesIn AttributeType }
+
+UserClasses ::= SEQUENCE {
+	allUsers  [0] NULL OPTIONAL,
+	thisEntry [1] NULL OPTIONAL,
+	name      [2] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
+	userGroup [3] SET SIZE (1..MAX) OF NameAndOptionalUID OPTIONAL,
+		-- dn component shall be the name of an
+		-- entry of GroupOfUniqueNames
+	subtree   [4] SET SIZE (1..MAX) OF SubtreeSpecification OPTIONAL }
+
+ItemPermission ::= SEQUENCE {
+	precedence Precedence OPTIONAL,
+		-- defaults to precedence in ACIItem
+	userClasses UserClasses,
+	grantsAndDenials GrantsAndDenials }
+
+UserPermission ::= SEQUENCE {
+	precedence Precedence OPTIONAL,
+		-- defaults to precedence in ACIItem
+	protectedItems ProtectedItems,
+	grantsAndDenials GrantsAndDenials }
+
+AuthenticationLevel ::= CHOICE {
+	basicLevels SEQUENCE {
+	level ENUMERATED { none (0), simple (1), strong (2) },
+	localQualifier INTEGER OPTIONAL,
+	signed BOOLEAN DEFAULT FALSE },
+	other EXTERNAL }
+
+GrantsAndDenials ::= BIT STRING {
+	-- permissions that may be used in conjunction
+	-- with any component of ProtectedItems
+	grantAdd             (0),
+	denyAdd              (1),
+	grantDiscloseOnError (2),
+	denyDiscloseOnError  (3),
+	grantRead            (4),
+	denyRead             (5),
+	grantRemove          (6),
+	denyRemove           (7),
+	-- permissions that may be used only in conjunction
+	-- with the entry component
+	grantBrowse          (8),
+	denyBrowse           (9),
+	grantExport          (10),
+	denyExport           (11),
+	grantImport          (12),
+	denyImport           (13),
+	grantModify          (14),
+	denyModify           (15),
+	grantRename          (16),
+	denyRename           (17),
+	grantReturnDN        (18),
+	denyReturnDN         (19),
+	-- permissions that may be used in conjunction
+	-- with any component, except entry, of ProtectedItems
+	grantCompare         (20),
+	denyCompare          (21),
+	grantFilterMatch     (22),
+	denyFilterMatch      (23),
+	grantInvoke          (24),
+	denyInvoke           (25) }
+
+AttributeTypeAndValue ::= SEQUENCE {
+	type ATTRIBUTE.&amp;id ({SupportedAttributes}),
+	value ATTRIBUTE.&amp;Type({SupportedAttributes}{@type}) }
+</source>
+      </subsection>
+      <subsection heading="h2" name="BNF grammar">
+        <p>
+Here is the BNF grammar of this ASN.1 grammar
+:</p>
+        <source>&lt;wrapperEntryPoint&gt; ::= &lt;theACIItem&gt; EOF
+
+&lt;theACIItem&gt; ::= 
+    '{'
+        &lt;spse&gt; &lt;aci_identificationTag&gt; &lt;spse&gt;
+        ',' &lt;spse&gt; &lt;aci_precedence&gt; &lt;spse&gt;
+        ',' &lt;spse&gt; &lt;aci_authenticationLevel&gt; &lt;spse&gt;
+        ',' &lt;spse&gt; &lt;aci_itemOrUserFirst&gt; &lt;spse&gt;
+    '}'
+
+&lt;aci_identificationTag&gt; ::= "identificationTag" &lt;sps&gt; SAFEUTF8STRING
+
+&lt;aci_precedence&gt; ::= "precedence" &lt;sps&gt; INTEGER
+
+&lt;aci_authenticationLevel&gt; ::= "authenticationLevel" &lt;sps&gt; &lt;basicLevels&gt;
+
+&lt;basicLevels&gt; ::= "basicLevels" &lt;spse&gt; ':' &lt;spse&gt; '{' &lt;spse&gt; &lt;level&gt; &lt;spse&gt; &lt;level_follower&gt; '}'
+
+&lt;level&gt; ::= "level" &lt;sps&gt; &lt;levels&gt;
+
+&lt;levels&gt; ::= "none" | "simple" | "strong"
+
+&lt;level_follower&gt; ::= ',' &lt;spse&gt; &lt;localQualifier_signed&gt; | e
+
+&lt;localQualifier_signed&gt; ::= 
+    "localQualifier" &lt;sps&gt; INTEGER &lt;spse&gt; &lt;signed_e&gt;
+    | "signed" &lt;sps&gt; &lt;booleanValue&gt; &lt;spse&gt; 
+
+&lt;signed_e&gt; ::= ',' &lt;spse&gt; "signed" &lt;sps&gt; &lt;booleanValue&gt; &lt;spse&gt; | e
+
+&lt;booleanValue&gt; ::= "FALSE" | "TRUE"
+
+&lt;aci_itemOrUserFirst&gt; ::= "itemOrUserFirst" &lt;sps&gt; &lt;itemOrUserFirst&gt;
+
+&lt;itemOrUserFirst&gt; ::= &lt;itemFirst&gt; | &lt;userFirst&gt;
+
+&lt;itemFirst&gt; ::= "itemFirst" ':' '{' &lt;spse&gt; &lt;protectedItems&gt; ',' &lt;spse&gt; &lt;itemPermissions&gt; &lt;spse&gt; '}'
+
+&lt;userFirst&gt; ::= "userFirst" ':' '{' &lt;spse&gt; &lt;userClasses&gt; ',' &lt;spse&gt; &lt;userPermissions&gt; &lt;spse&gt; '}'
+
+&lt;protectedItems&gt; ::= "protectedItems" &lt;spse&gt; '{' &lt;spse&gt; &lt;protectedItems_e&gt; &lt;spse&gt; '}'
+
+&lt;protectedItems_e&gt; ::= "entry" &lt;entry_follower_e&gt;
+                	| "allUserAttributeTypes" &lt;allUserAttributeTypes_follower_e&gt;
+                	| &lt;attributeType&gt; &lt;attributeType_follower_e&gt;
+                	| &lt;allAttributeValues&gt; &lt;allAttributeValues_follower_e&gt;
+                	| &lt;allUserAttributeTypesAndValues&gt; &lt;allUserAttributeTypesAndValues_follower_&gt;
+                	| ATTRIBUTE_VALUE_CANDIDATE &lt;attributeValue_follower_e&gt;
+                	| &lt;selfValue&gt; &lt;selfValue_follower_e&gt;
+                	| RANGE_OF_VALUES_CANDIDATE &lt;rangeOfValues_follower_e&gt;
+                	| &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+                	| &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+                	| &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+                	| &lt;classes&gt;
+			| e
+
+&lt;entry_follower_e&gt; ::= ',' &lt;spse&gt; &lt;entry_follower&gt; | e
+
+&lt;entry_follower&gt; ::= 
+	"allUserAttributeTypes" &lt;allUserAttributeTypes_follower_e&gt;
+            | &lt;attributeType&gt; &lt;attributeType_follower_e&gt;
+            | &lt;allAttributeValues&gt; &lt;allAttributeValues_follower_e&gt; 
+            | &lt;allUserAttributeTypesAndValues&gt; &lt;allUserAttributeTypesAndValues_follower_e&gt;
+            | ATTRIBUTE_VALUE_CANDIDATE &lt;attributeValue_follower_e&gt;
+            | &lt;selfValue&gt; &lt;selfValue_follower_e&gt;
+            | RANGE_OF_VALUES_CANDIDATE &lt;rangeOfValues_follower_e&gt;
+            | &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+            | &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;allUserAttributeTypes_follower_e&gt; ::= ',' &lt;spse&gt; &lt;allUserAttributeTypes_follower&gt; | e
+
+&lt;allUserAttributeTypes_follower&gt; ::=
+            &lt;attributeType&gt; &lt;attributeType_follower_e&gt;
+            | &lt;allAttributeValues&gt; &lt;allAttributeValues_follower_e&gt;
+            | &lt;allUserAttributeTypesAndValues&gt; &lt;allUserAttributeTypesAndValues_follower_e&gt;
+            | ATTRIBUTE_VALUE_CANDIDATE &lt;attributeValue_follower_e&gt;
+            | &lt;selfValue&gt; &lt;selfValue_follower_e&gt;
+            | RANGE_OF_VALUES_CANDIDATE &lt;rangeOfValues_follower_e&gt;
+            | &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+            | &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;attributeType_follower_e&gt; ::= ',' &lt;spse&gt; &lt;attributeType_follower&gt; | e
+&lt;attributeType_follower&gt; ::= 
+            &lt;allAttributeValues&gt; &lt;allAttributeValues_follower_e&gt;
+            | &lt;allUserAttributeTypesAndValues&gt; &lt;allUserAttributeTypesAndValues_follower_e&gt;
+            | ATTRIBUTE_VALUE_CANDIDATE &lt;attributeValue_follower_e&gt;
+            | &lt;selfValue&gt; &lt;selfValue_follower_e&gt;
+            | RANGE_OF_VALUES_CANDIDATE &lt;rangeOfValues_follower_e&gt;
+            | &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+            | &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&lt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;allAttributeValues_follower_e&gt; ::= ',' &lt;spse&gt; &lt;allAttributeValues_follower&gt; | e
+
+&lt;allAttributeValues_follower&gt; ::= 
+            &lt;allUserAttributeTypesAndValues&gt; &lt;allUserAttributeTypesAndValues_follower_e&gt;
+            | ATTRIBUTE_VALUE_CANDIDATE &lt;attributeValue_follower_e&gt;
+            | &lt;selfValue&gt; &lt;selfValue_follower_e&gt;
+            | RANGE_OF_VALUES_CANDIDATE &lt;rangeOfValues_follower_e&gt;
+            | &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+            | &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;allUserAttributeTypesAndValues_follower_e&gt; ::= ',' &lt;spse&gt; &lt;allUserAttributeTypesAndValues_follower&gt; | e
+
+&lt;allUserAttributeTypesAndValues_follower&gt; ::= 
+            ATTRIBUTE_VALUE_CANDIDATE &lt;attributeValue_follower_e&gt;
+            | &lt;selfValue&gt; &lt;selfValue_follower_e&gt;
+            | RANGE_OF_VALUES_CANDIDATE &lt;rangeOfValues_follower_e&gt;
+            | &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+            | &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;attributeValue_follower_e&gt; ::= ',' &lt;spse&gt; &lt;attributeValue_follower&gt; | e
+
+&lt;attributeValue_follower&gt; ::= 
+            &lt;selfValue&gt; &lt;selfValue_follower_e&gt;
+            | RANGE_OF_VALUES_CANDIDATE &lt;rangeOfValues_follower_e&gt;
+            | &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+            | &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;selfValue_follower&gt; ::= ',' &lt;spse&gt; &lt;selfValue_follower&gt; | e
+
+&lt;selfValue_follower&gt; ::= 
+            RANGE_OF_VALUES_CANDIDATE &lt;rangeOfValues_follower_e&gt;
+            | &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+            | &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;rangeOfValues_follower&gt; ::= ',' &lt;spse&gt; &lt;rangeOfValues_follower&gt; | e
+
+&lt;rangeOfValues_follower&gt; ::= 
+            &lt;maxValueCount&gt; &lt;maxValueCount_follower_e&gt;
+            | &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;maxValueCount_follower&gt; ::= ',' &lt;spse&gt; &lt;maxValueCount_follower&gt; | e
+
+&lt;maxValueCount_follower&gt; ::= 
+            &lt;maxImmSub&gt; &lt;maxImmSub_follower_e&gt;
+            | &lt;restrictedBy&gt; &lt;restrictedBy_follower_e&gt;
+            | &lt;classes&gt;
+
+&lt;maxImmSub_follower&gt; ::= ',' &lt;spse&gt; &lt;maxImmSub_follower&gt; | e
+
+&lt;maxImmSub_follower&gt; ::= 
+	    &lt;restrictedBy&gt; &lt;restrictedBy_follower&gt;
+            | &lt;classes&gt;
+
+&lt;restrictedBy_follower&gt; ::= ',' &lt;spse&gt; &lt;classes&gt; | e
+
+&lt;attributeType&gt; ::= "attributeType" &lt;sps&gt; &lt;attributeTypeSet&gt;
+
+&lt;allAttributeValues&gt; ::= "allAttributeValues" &lt;sps&gt; &lt;attributeTypeSet&gt;
+
+&lt;allUserAttributeTypesAndValues&gt; ::= "allUserAttributeTypesAndValues"
+
+&lt;selfValue&gt; ::= "selfValue" &lt;sps&gt; &lt;attributeTypeSet&gt;
+
+&lt;maxValueCount&gt; ::= "maxValueCount" &lt;sps&gt; '{' &lt;spse&gt; &lt;aMaxValueCount&gt; &lt;spse&gt; &lt;aMaxValueCounts&gt; '}'
+
+&lt;aMaxValueCounts&gt; ::= ',' &lt;spse&gt; &lt;aMaxValueCount&gt; &lt;spse&gt; &lt;aMaxValueCounts&gt; | e
+
+&lt;aMaxValueCount&gt; ::= '{' &lt;spse&gt; "type" &lt;sps&gt; &lt;oid&gt; &lt;spse&gt; ',' &lt;spse&gt; "maxCount" &lt;sps&gt; INTEGER &lt;spse&gt; '}'
+
+&lt;maxImmSub&gt; ::= "maxImmSub" &lt;sps&gt; INTEGER
+
+&lt;restrictedBy&gt; ::= "restrictedBy" &lt;sps&gt; '{' &lt;spse&gt; &lt;restrictedValue&gt; &lt;spse&gt; &lt;restrictedValues&gt; '}'
+
+&lt;restrictedValues&gt; ::= ',' &lt;spse&gt; &lt;restrictedValue&gt; &lt;spse&gt; &lt;restrictedValues&gt; | e
+
+&lt;restrictedValue&gt; ::= '{' &lt;spse&gt; "type" &lt;sps&gt; &lt;oid&gt; &lt;spse&gt; ',' &lt;spse&gt; "valuesIn" &lt;sps&gt; &lt;oid&gt; &lt;spse&gt; '}'
+
+&lt;attributeTypeSet&gt; ::= '{' &lt;spse&gt; &lt;oid&gt; &lt;spse&gt; &lt;attributeTypeSets&gt; '}'
+
+&lt;attributeTypeSets&gt; ::= ',' &lt;spse&gt; &lt;oid&gt; &lt;spse&gt; &lt;attributeTypeSet&gt; | e
+
+&lt;classes&gt; ::= "classes" &lt;sps&gt; &lt;refinement&gt;
+
+&lt;itemPermissions&gt; ::= "itemPermissions" &lt;sps&gt; '{' &lt;spse&gt; &lt;itemPermission_e&gt; '}'
+
+&lt;itemPermission_e&gt; ::= &lt;itemPermission&gt; &lt;spse&gt; &lt;itemPermissions_e&gt; | e
+
+&lt;itemPermissions_e&gt; ::= ',' &lt;spse&gt; &lt;itemPermission&gt; &lt;spse&gt; &lt;itemPermissions_e&gt; | e
+
+&lt;itemPermission&gt; ::= '{' &lt;spse&gt; &lt;precedence_e&gt; &lt;spse&gt; '}'
+
+&lt;precedence_e&gt; ::= 
+    "precedence" &lt;sps&gt; INTEGER &lt;spse&gt; ',' &lt;spse&gt; &lt;userClasses&gt; &lt;spse&gt; ',' &lt;spse&gt; &lt;grantsAndDenials&gt;
+    | &lt;userClasses&gt; &lt;spse&gt; ',' &lt;spse&gt; &lt;grantsAndDenials&gt;
+
+&lt;grantsAndDenials&gt; ::= "grantsAndDenials" &lt;sps&gt; '{' &lt;spse&gt; &lt;grantAndDenialsBit_e&gt; '}'
+
+&lt;grantAndDenialsBit_e&gt; ::= &lt;grantAndDenialsBit&gt; &lt;spse&gt; &lt;grantAndDenialsBits_e&gt; | e
+
+&lt;grantAndDenialsBits_e&gt; ::= ',' &lt;spse&gt; &lt;grantAndDenialsBit&gt; &lt;spse&gt; &lt;grantAndDenialsBits_e&gt; | e
+
+&lt;grantAndDenialsBit&gt; ::= 
+    "grantAdd" // (0),
+    | "denyAdd" // (1),
+    | "grantDiscloseOnError" // (2),
+    | "denyDiscloseOnError" // (3),
+    | "grantRead" // (4),
+    | "denyRead" // (5),
+    | "grantRemove" // (6),
+    | "denyRemove" // (7),
+    | "grantBrowse" // (8),
+    | "denyBrowse" // (9),
+    | "grantExport" // (10),
+    | "denyExport" // (11),
+    | "grantImport" // (12),
+    | "denyImport" // (13),
+    | "grantModify" // (14),
+    | "denyModify" // (15),
+    | "grantRename" // (16),
+    | "denyRename" // (17),
+    | "grantReturnDN" // (18),
+    | "denyReturnDN" // (19),
+    | "grantCompare" // (20),
+    | "denyCompare" // (21),
+    | "grantFilterMatch" // (22),
+    | "denyFilterMatch" // (23),
+    | "grantInvoke" // (24),
+    | "denyInvoke" // (25)
+
+&lt;userClasses&gt; ::= "userClasses" &lt;sps&gt; '{' &lt;spse&gt; &lt;userClasses_e&gt; '}'
+
+&lt;userClasses_e&gt; ::= 
+            "allUsers" &lt;allUsers_follower_e&gt; &lt;spse&gt;
+            | "thisEntry" &lt;thisEntry_follower_e&gt; &lt;spse&gt;
+            | &lt;name&gt; &lt;name_follower_e&gt; &lt;spse&gt;
+            | &lt;userGroup&gt; &lt;userGroup_follower_e&gt; &lt;spse&gt;
+            | &lt;subtree&gt; &lt;spse&gt;
+	    | e
+
+&lt;allUsers_follower_e&gt; ::= ',' &lt;spse&gt; &lt;allUsers_follower&gt; | e
+
+&lt;allUsers_follower&gt; ::= 
+             "thisEntry" &lt;thisEntry_follower_e&gt;
+             | &lt;name&gt; &lt;name_follower_e&gt;
+             | &lt;userGroup&gt; &lt;userGroup_follower_e&gt;
+             | &lt;subtree&gt;
+
+&lt;thisEntry_follower_e&gt; ::= ',' &lt;spse&gt; &lt;thisEntry_follower&gt; | e
+
+&lt;thisEntry_follower&gt; ::= 
+            &lt;name&gt; &lt;name_follower_e&gt;
+            | &lt;userGroup&gt; &lt;userGroup_follower_e&gt;
+            | &lt;subtree
+
+&lt;name_follower&gt; ::= ',' &lt;spse&gt; &lt;name_follower&gt; | e
+
+&lt;name_follower&gt; ::= 
+            &lt;userGroup&gt; &lt;userGroup_follower_e&gt;
+            | &lt;subtree&gt;
+
+&lt;userGroup_follower_e&gt; ::= ',' &lt;spse&gt; &lt;subtree&gt; | e
+
+&lt;name&gt; ::= "name" &lt;sps&gt; '{' &lt;spse&gt; SAFEUTF8STRING &lt;spse&gt; &lt;names_e&gt; '}'
+
+&lt;names_e&gt; ::= ',' &lt;spse&gt; SAFEUTF8STRING &lt;spse&gt; &lt;names_e&gt; | e
+
+&lt;userGroup&gt; ::= "userGroup" &lt;sps&gt; '{' &lt;spse&gt; SAFEUTF8STRING &lt;spse&gt; &lt;userGroups_e&gt; '}'
+
+&lt;userGroups_e&gt; ::= ',' &lt;spse&gt; SAFEUTF8STRING &lt;spse&gt; &lt;userGroups_e&gt; | e
+
+&lt;subtree&gt; ::= "subtree" &lt;sps&gt; '{' &lt;spse&gt; &lt;subtreeSpecification&gt; &lt;spse&gt; &lt;subtrees_e&gt; '}'
+
+&lt;subtrees_e&gt; ::= ',' &lt;spse&gt; &lt;subtreeSpecification&gt; &lt;spse&gt; &lt;subtrees_e&gt; | e
+
+&lt;userPermissions&gt; ::= "userPermissions" &lt;sps&gt; '{' &lt;spse&gt; &lt;userPermissions_ee&gt; '}'
+
+&lt;userPermissions_ee&gt; ::= &lt;userPermission&gt; &lt;spse&gt; &lt;userPermissions_e&gt; | e
+
+&lt;userPermissions_e&gt; ::= ',' &lt;spse&gt; &lt;userPermission&gt; &lt;spse&gt; &lt;userPermissions_e&gt; | e
+
+&lt;userPermission&gt; ::= '{' &lt;spse&gt; &lt;precedence_ee&gt; &lt;spse&gt; '}'
+
+&lt;precedence_ee&gt; ::= 
+    "precedence" &lt;sps&gt; INTEGER &lt;spse&gt; ',' &lt;spse&gt; &lt;protectedItems&gt; &lt;spse&gt; ',' &lt;spse&gt; &lt;grantsAndDenials&gt;
+    | &lt;protectedItems&gt; &lt;spse&gt; ',' &lt;spse&gt; &lt;grantsAndDenials&gt;
+
+&lt;subtreeSpecification&gt; ::= '{' &lt;spse&gt; &lt;subtreeSpecification_e&gt; '}'
+
+&lt;subtreeSpecification_e&gt; ::= 
+	&lt;ss_base&gt; &lt;ss_base_follower_e&gt; &lt;spse&gt;
+        | &lt;ss_specificExclusions&gt; &lt;ss_specificExclusions_follower_e&gt; &lt;spse&gt;
+        | &lt;ss_minimum&gt; &lt;ss_minimum_follower_e&gt; &lt;spse&gt;
+        | &lt;ss_maximum&gt; &lt;ss_maximum_follower_e&gt; &lt;spse&gt;
+        | &lt;ss_specificationFilter&gt; &lt;spse&gt;
+	| e
+
+&lt;ss_base_follower_e&gt; ::= ',' &lt;spse&gt; &lt;ss_base_follower&gt; | e
+
+&lt;ss_base_follower&gt; ::= 
+            &lt;ss_specificExclusions&gt; &lt;ss_specificExclusions_follower_e&gt;
+            | &lt;ss_minimum&gt; &lt;ss_minimum_follower_e&gt;
+            | &lt;ss_maximum&gt; &lt;ss_maximum_follower_e&gt;
+            | &lt;ss_specificationFilter&gt;
+
+&lt;ss_specificExclusions_follower_e&gt; ::= ',' &lt;spse&gt; &lt;ss_specificExclusions_follower&gt; | e
+
+&lt;ss_specificExclusions_follower&gt; ::= 
+            &lt;ss_minimum&gt; &lt;ss_minimum_follower_e&gt;
+            | &lt;ss_maximum&gt; &lt;ss_maximum_follower_e&gt;
+            | &lt;ss_specificationFilter&gt;
+
+&lt;ss_minimum_follower_e&gt; ::= ',' &lt;spse&gt; &lt;ss_minimum_follower&gt; | e
+
+&lt;ss_minimum_follower&gt; ::= 
+            &lt;ss_maximum&gt; &lt;ss_maximum_follower_e&gt;
+            | &lt;ss_specificationFilter&gt;
+
+&lt;ss_maximum_follower_e&gt; ::= ',' &lt;spse&gt; &lt;ss_specificationFilter&gt; | e
+
+&lt;ss_base&gt; ::= "base" &lt;sps&gt; SAFEUTF8STRING
+
+&lt;ss_specificExclusions&gt; ::= "specificExclusions" &lt;sps&gt; &lt;specificExclusions&gt;
+
+&lt;specificExclusions&gt; ::= '{' &lt;spse&gt; &lt;specificExclusions_e&gt; '}'
+
+&lt;specificExclusions_e&gt; ::= &lt;specificExclusion&gt; &lt;spse&gt; &lt;specificExclusions_ee&gt; | e
+
+&lt;specificExclusions_ee&gt; ::= ',' &lt;spse&gt; &lt;specificExclusion&gt; &lt;spse&gt; &lt;specificExclusions_ee&gt; | e
+
+&lt;specificExclusion&gt; ::= "chopBefore" ':' SAFEUTF8STRING | "chopAfter" ':' SAFEUTF8STRING
+
+&lt;ss_minimum&gt; ::= "minimum" &lt;sps&gt; INTEGER
+
+&lt;ss_maximum&gt; ::= "maximum" &lt;sps&gt; INTEGER
+
+&lt;ss_specificationFilter&gt; ::= "specificationFilter" &lt;sps&gt; &lt;refinement&gt;
+
+&lt;oid&gt; ::= DESCR | NUMERICOID
+
+&lt;refinement&gt; ::= &lt;item&gt; | &lt;and&gt; | &lt;or&gt; | &lt;not&gt;
+
+&lt;item&gt; ::= "item" ':' &lt;oid&gt;
+
+&lt;and&gt; ::= "and" ':' &lt;refinements&gt;
+
+&lt;or&gt; ::= "or" ':' &lt;refinements&gt;
+
+&lt;not&gt; ::= "not" ':' &lt;refinements&gt;
+
+&lt;refinements&gt; ::= '{' &lt;spse&gt; &lt;refinements_e&gt; '}'
+
+&lt;refinements_e&gt; ::= &lt;refinement&gt; &lt;spse&gt; &lt;refinements_ee&gt; | e
+
+&lt;refinements_ee&gt; ::= ',' &lt;spse&gt; &lt;refinement&gt; &lt;spse&gt; &lt;refinements_ee&gt; | e
+
+&lt;sps&gt; ::= ' ' &lt;spse&gt;
+
+&lt;spse&gt; ::= ' ' &lt;spse&gt; | e
+
+
+
+
+// Lexer
+protected SAFEUTF8CHAR :
+    '\u0001'..'\u0021' |
+    '\u0023'..'\u007F' |
+    '\u00c0'..'\u00d6' |
+    '\u00d8'..'\u00f6' |
+    '\u00f8'..'\u00ff' |
+    '\u0100'..'\u1fff' |
+    '\u3040'..'\u318f' |
+    '\u3300'..'\u337f' |
+    '\u3400'..'\u3d2d' |
+    '\u4e00'..'\u9fff' |
+    '\uf900'..'\ufaff' ;
+
+',' : ',' ;
+
+' ' : ' ' ;
+
+':' : ':' ;
+
+protected DIGIT : '0' | LDIGIT ;
+
+protected LDIGIT : '1'..'9' ;
+
+protected ALPHA : 'A'..'Z' | 'a'..'z' ;
+
+protected INTEGER : DIGIT | ( LDIGIT ( DIGIT )+ ) ;
+
+protected HYPHEN : '-' ;
+
+protected NUMERICOID : INTEGER ( DOT INTEGER )+ ;
+
+protected DOT : '.' ;
+
+INTEGER_OR_NUMERICOID
+    :
+    ( INTEGER DOT ) =&gt; NUMERICOID
+    |
+    INTEGER
+    ;
+
+SAFEUTF8STRING : '"'! ( SAFEUTF8CHAR )* '"'! ;
+
+DESCR 
+    :
+    ( "attributeValue" ( ' '! )+ '{' ) =&gt;
+      "attributeValue"! ( ' '! )+ '{'! (options { greedy=false;}:. )* '}'!
+    | ( "rangeOfValues" ( ' '! )+ '(') =&gt;
+      "rangeOfValues"! ( ' '! )+ '(' (options { greedy=false;}:. )* ')'
+    | ALPHA ( ALPHA | DIGIT | HYPHEN )*
+    ;
+</source>
+      </subsection>
+    </section>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/developers/aci_aciitemasn1.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/developers/aci_implnotes.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/developers/aci_implnotes.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/developers/aci_implnotes.xml (added)
+++ directory/apacheds/trunk/xdocs/developers/aci_implnotes.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,281 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="akarasulu">akarasulu</author>
+    <title>Access Control Implementation Notes</title>
+  </properties>
+  <body>
+    <section heading="h2" name="Introduction">
+      <p>
+Do not take this document as the final description of how we implement access
+controls within ApacheDS (yet).  It is just some notes that have been taken as
+we started implementing the access control subsystem.  Eventually it can be
+compiled into developer documentation on how the access control subsystem is
+implemented.</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+Too follow the JIRA tasks that lead to this feature take a look
+at
+        <a href="http://issues.apache.org/jira/browse/DIREVE-204">DIREVE-204</a>
+.
+      </p>
+    </section>
+    <section heading="h2" name="Access Control Subentry Operational Attribute">
+      <p>
+Although two kinds of subentry types exist for access control administrative
+areas (accessControlSpecificAreas and accessControlInnerAreas) we will still be
+using a single operational attribute within entries to reference the subentries
+of these areas.  We will use _accessControlSubentries_ as the identifier for the
+operational attribute containing the DN of subentries which the entry is within
+the scope of: meaning the subtreeSpecification associated with the referenced
+subentries select the entry.  Below is the schema definition for this new
+operational attribute which we have assigned off of the apache OID
+space:</p>
+      <source>attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.26 NAME 'accessControlSubentries'
+    DESC 'Used to track a subentry associated with access control areas'
+    SUP distinguishedName
+    EQUALITY distinguishedNameMatch
+    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
+    SINGLE-VALUE
+    NO-USER-MODIFICATION
+    USAGE directoryOperation )
+</source>
+      <p>
+The subentry subsystem will automatically handle the injection of this attribute
+into normal entries as new subentries are added and altered.  This house keeping
+also tracks newly added normal entries making sure they have these operational
+attributes pointing to the appropriate
+subentries.</p>
+    </section>
+    <section heading="h2" name="Performance Considerations">
+      <p>
+An LDAP server should be read optimized.  Hence we cannot expect to parse
+lengthy ACIs into ACIITems then transform them into ACITuples for evaluation
+during a search operation.  This would considerably slow down search
+operations.</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+Instead of repeatedly preparing ACI information during search request processing
+the server will cache ACI information in the form of ACITuples.   ACI Tuples are
+an intermediate representation of ACIItems designed for the sake of making
+access control decisions within the Access Control Decision Function
+(ACDF).</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+A set of ACITuples are generated from an ACIItem.  Sets of ACITuples can be
+mixed and evaluated together to represent the combined access control affects of
+one or more
+ACIItems.</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+ApacheDS will use the multivalued perscriptiveACI attribute within access
+control subentries to contain multiple ACIItems.  The server can generate and
+combine the ACITuple sets of these ACITems within a single subentry to represent
+the next access control effects of that subentry.  This superset of ACITuples
+can be cached and associated with the DN of the subentry containing their
+respective ACIItems.  Hence during solidstate operation prescriptive ACIItems
+need not be parsed or transformed into ACITuple sets.  A simple lookup retrieves
+the ACITuple set for each access control subentry influencing an entry candidate
+to be returned to the client.  The ACDF is invoked with this ACITuple set
+(possibly combined with entryACI Tuplesets) and other information to quickly
+determine whether or not access is allowed during any operation not just a
+search
+operation.</p>
+    </section>
+    <section heading="h2" name="Cache Initialization and Upkeep">
+      <p>
+On startup the server must populate the cache with the set of ACITuples from
+respective access control subentries.  A search must be conducted for all access
+contol subentries in all namingContexts to discover the set of prescriptiveACIs
+defined within the
+server.</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+After initialization, during solid state operation, the cache must be kept up to
+date with prescriptiveACI deletions, modifications, and additions.  With the
+current interceptor based architecture we can easily keep track of these
+alterations by trapping add, delete, and modify operations on access control
+subentries.</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+Check out the following JIRA issues and commits for more information on how this
+was
+implemented:</p>
+      <ul nesting="1">
+        <li>
+          <a href="http://svn.apache.org/viewcvs.cgi?view=rev&amp;rev=290038">Commit 290038</a>
+        </li>
+        <li>
+          <a href="http://issues.apache.org/jira/browse/DIREVE-258">DIREVE-258</a>
+        </li>
+        <li>
+          <a href="http://issues.apache.org/jira/browse/DIREVE-259">DIREVE-259</a>
+        </li>
+      </ul>
+    </section>
+    <section heading="h2" name="Marker ObjectClass for Access Control Subentries">
+      <p>
+A marker objectClass is needed for tracking subentries containing
+prescriptiveACI attributes.  Looking at various drafts, RFCs and the X.500
+specifications there was very little to go on.  However we decided on the
+following
+objectClass:</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <source>objectclass ( 1.2.6.1.4.1.18060.1.1.1.4.100
+    NAME 'accessControlSubentry'
+    AUXILIARY 
+    MUST prescriptiveACI )
+</source>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+We chose the name because it matches the pattern used
+in
+        <a href="http://www.faqs.org/rfcs/rfc3671.html">RFC 3671</a>
+where the operational attribute used was collectiveAttributeSubentries and the
+marker objectClass was collectiveAttributeSubentry.  This makes the access
+control specific analogs consistent with this naming
+pattern.
+      </p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+A perscriptiveACI attribute is included in the must list suggesting that at
+least one ACIItem must be contained by such an entry.  This is consistent with
+X.501 where at least one ACIITem is required for an access control subentry. 
+This leads us to have to define a prescriptiveACI
+attribute:</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <source>attributetype ( 1.2.6.1.4.1.18060.1.1.1.3.100 NAME 'prescriptiveACI'
+  DESC 'Access control information that applies to a set of entries'
+  EQUALITY directoryStringFirstComponentMatch
+  SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
+  USAGE directoryOperation
+)
+</source>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+Note that in the above attributetype description for the prescriptiveACI we have
+to include the syntax for ACIItem.  The syntax will need to be added to ApacheDS
+along with the new matching rule directoryStringFirstComponentMatch which is
+defined within section 2.6
+of
+        <a href="http://www.faqs.org/rfcs/rfc3698.html">RFC 3698</a>
+.  Note that RFC 2251 presumes the ACI Item syntax is not human readable.  We
+shall presume that it is human readable.  Here's the JIRA issue and commit
+revision that added these schema objects to the
+server:
+      </p>
+      <p>
+        <a href="http://svn.apache.org/viewcvs.cgi?view=rev&amp;rev=289953">Commit 289953</a>
+      </p>
+      <p>
+        <a href="http://issues.apache.org/jira/browse/DIREVE-257">DIREVE-257</a>
+      </p>
+    </section>
+    <section heading="h2" name="Adding Permission Check Guards to Interceptor Methods">
+      <p>
+To properly check access to an entry we must also check to see if the entry has
+ACIItems associated with it using the entryACI operational attribute.  This
+means for each entry we must check for the presence of this attribute and
+perform checks accordingly.  Entry ACIITems have tuples generated for them and
+those are combined to form s super ACITuple collection.  This collection is fed
+into the ACDF engine to determine if permission is to be
+granted.</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+Another aspect to this is to determine which grants are required to grant
+permission to an operation.  Unfortunately we loose some resolution regarding
+the correspondance of interceptor operations to protocol operations.  There
+needs to be a way to correlate LDAP protocol operations when interceptor
+operations are invoked so we can make sure the proper permissions are checked
+for.  Presently we have no way to do this.  One thing to research is a means to
+stuff protocol operation information into the environment of each JNDI
+operation.  There has even been some talk about using some sort of session
+object.</p>
+    </section>
+    <section heading="h2" name="UserGroup for ACI evaluation">
+      <p>
+Group membership is included in access control information and is taken into
+account within the ACDF.  The group membership is with respect to the LDAP
+principal the operation is executing as.  This means LDAP principals must either
+track this information or the Authorization subsystem must determine this
+information on the
+fly.</p>
+      <p>
+Question: Should we add group membership information to the LdapPrincipal class
+or should we just let the authorization subsystem track this
+info?</p>
+      <p>
+For the sake of performance it might be best to add group membership information
+to the LdapPrincipal so this information is not looked up every time access
+control decisions need to be made.  Adding the info to the LdapPrincipal however
+will require Authenticator implementations to have to populate this information.
+A base class can automatically populate this information or some utility class
+can also be provided.  Another potential problem is how to update the group
+membership information for LdapPrincipals while they are bound to the directory
+and updates to groups occur.  This however is a problem that can be solved
+later.</p>
+      <p>
+If group membership information is cached and updated within
+the</p>
+      <p>
+authorization module these problems can be minimized.  The interceptor can also
+update membership information as changes occur.  Really there is no other place
+where this info needs to be accessed.  It might not pay to put this fuctionality
+into the LdapPrincipal.  It's cut to have it there but it may not be required
+anywhere but in the authz
+subsystem.</p>
+    </section>
+    <section heading="h2" name="Special User Handling: Administrator">
+      <p>
+It is very easy for users to lock out the administrator from being able to
+access the directory.  This however is not that much of a problem if the access
+control mechanism can be turned off via the configuration.  However note that
+most of the configuration of the server is being pushed back into the DIT
+itself.  This may cause a problem.  In general the administrator of the server
+should have special consideration.  Meaning they should have full access and
+should bypass the access control
+mechanism.</p>
+      <p>
+This is why our implementation will detect this special user and bypass access
+control restrictions.  In effect the admin can perform any
+operation.</p>
+    </section>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/developers/aci_implnotes.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/developers/aci_notesfromx501
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/developers/aci_notesfromx501?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/developers/aci_notesfromx501 (added)
+++ directory/apacheds/trunk/xdocs/developers/aci_notesfromx501 Fri Oct 28 20:07:59 2005
@@ -0,0 +1,166 @@
+<?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>

Propchange: directory/apacheds/trunk/xdocs/developers/aci_notesfromx501
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/developers/interceptor_interactions.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/developers/interceptor_interactions.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/developers/interceptor_interactions.xml (added)
+++ directory/apacheds/trunk/xdocs/developers/interceptor_interactions.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,164 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="akarasulu">akarasulu</author>
+    <title>Interceptor Interactions</title>
+  </properties>
+  <body>
+    <p>
+Interceptors will perform operations on behalf of the user/context making calls
+against the proxy.  Interceptors will often need to access or alter the DIT. 
+Interceptors have several options for DIT
+access/alteration.</p>
+    <ol nesting="0">
+      <li>
+operate directly against the
+nexus</li>
+      <li>
+operate against the nexus
+proxy</li>
+      <li>
+operate against the next Interceptor in the
+chain</li>
+      <li>
+operate against JNDI
+interfaces</li>
+      <li>
+operate against the nexus proxy with selective
+bypass</li>
+      <li>
+out of band support methods on
+Interceptors</li>
+    </ol>
+    <p>
+A combination of these approaches can be taken.  Each one has side effects and
+ramifications when used.  We will discuss the ramifications of each option as it
+relates to Interceptor interactions.  Interceptor interactions (coupling)
+undermine the overall goal of having orthogonal independent
+services.</p>
+    <section heading="h2" name="Direct Operations Against the Nexus">
+      <p>
+Direct operations against the system nexus retrieves or alters raw entries
+stored within partitions.  Sometimes this is absolutely necessary and sometimes
+it could lead to serious
+problems.</p>
+      <subsection heading="h3" name="Direct operations on the nexus bypass the Interceptor Mechanism">
+        <p>
+Direct operations on the nexus bypass the Interceptor mechanism.  No Invocation
+object is pushed onto the InvocationStack, and no Interceptors intercept the
+call.  If the Interceptor code calling the nexus relies on pre or post
+processing by any other Interceptor there will be a
+problem.</p>
+        <p>
+A good example is the reliance of upstream Interceptors on the Mitosis
+replication Interceptor.  Upstream Interceptors ironically don't even know of
+the presence of the Mitosis Interceptor, nor that they rely on it.  Mitosis does
+not actually delete entries but marks them deleted.  The Mitosis Interceptor
+filters out deleted entries from searches and responds according with
+NameNotFoundExceptions when other operations are performed on entries marked for
+deletion.  Interceptors before the Mitosis Interceptor don't have to worry about
+whether or not an entry is deleted because this is handled already.  This is not
+the case for downstream Interceptors so positioning is critical.  Direct access
+to the nexus however bypasses the Mitosis Interceptor along with all others and
+makes deleted entries
+reappear.</p>
+      </subsection>
+      <subsection heading="h3" name="Raw access to partition entries may be required">
+        <p>
+Raw access to partition entries should be done with extreme caution.  But at
+times this access may be absolutely necessary.  The Interceptor, it's position
+and the effects of bypassing other possibly unknown Interceptors must be taking
+into
+consideration.</p>
+      </subsection>
+    </section>
+    <section heading="h2" name="Operations on the Nexus Proxy">
+      <p>
+Interceptors that have intercepted an operation, may use the proxy to perform
+other operations.  These other operations performed to satisfy the first
+intercepted operation will also traverse the
+InterceptorChain.</p>
+      <subsection heading="h3" name="There is a risk for infinate recursion">
+        <p>
+The danger here is an infinite recursion.  Let's suppose the first intercepted
+operation, Invocation *A*, performs operations *A'* (that's A prime) and *B*
+against the nexus.  Invocation *A'* by the way is the same operation as the
+intercepted operation but with different parameters. The same operation does not
+mean the same Invocation.  In this case *A'* may incur another set of Invocation
+*A"* and *B'* all invoked within the same Interceptor.  This chain reaction
+could continue unabated to blow out the stack without
+regulation.</p>
+        <p>
+A good example of an Interceptor prone to an infinite recursion is the
+AuthorizationService.  It needs to lookup and search for other other entries to
+determine access rights to perform operations.  Those lookup and search
+operations in turn trigger the AuthorizationService again to issue another set
+of lookup and search operations and so on.  An infinate recursion is the
+result.</p>
+        <p>
+If the AuthorizationService could call lookup and search on the nexus proxy
+while bypassing itself then the recursion can be avoided.  This raises the
+question of whether or not sub-operations excecuted by Interceptors are really
+considered to be performed by the user of the intercepted
+call.</p>
+      </subsection>
+      <subsection heading="h3" name="Effects on the InvocationStack">
+        <p>
+Calls against the nexus proxy are not presently possible.  They can however be
+enabled.  The foreseeable mechanism would be to just call the proxy object of
+the current intercepted operation.  This could be done by peeking at the
+InvocationStack to get a handle on the Invocation object for the current
+operation.  From there the calling Context can be accessed.  An accessor in the
+Context implementation can expose access to the nexus proxy
+object.</p>
+        <p>
+Calling this nexus proxy will push a new Invocation object on top of the current
+operation's Invocation object.  This is good  even though the Context is used to
+issue yet another Invocation.  The key advantage though is that we can
+diffentiate between the two Invocations even if the caller Context, operation
+and the parameters are the
+same.</p>
+      </subsection>
+      <subsection heading="h3" name="Identity Lock-in">
+        <p>
+Because the same Context object is used, the identity performing the operation
+is the same.  This may be good and
+bad.</p>
+        <p>
+It's good because we are associating the sub-operations with the user performing
+the primary operation.  Although if we peek onto the stack the bottom most
+Invocation tells us who the original Invocation was issued by.  Even if
+sub-operations are performed as another user like the super-user we can tell who
+the original user was that this sub-operation was issued on behalf
+of.</p>
+        <p>
+There will be situations when we want a setUid like mechanism to access
+protected information on behalf of the current user.  Even if the current user
+does not have access to protected resources, the Interceptor should be able to
+access these resources to satisfy the current intercepted operation.  Meaning
+the Interceptor will need to perform operations as if it were the admin user to
+satisfy an operation on behalf of the current user.  Doing this is no simple
+matter: authentication must be bypassed to enable an operation as the admin
+user.  Otherwise we would need access to the admin's credentials.  Plus
+re-authentication as the admin is unnecesary since the Interceptor is trusted
+with admin rights.  If we trust the Interceptor and give it the ability to
+access the DIT as the admin, we must be sure this is done without compromising
+security.</p>
+        <p>
+Another alternative to access protected resources would be to disable access
+controls for select sub-operations performed by an Interceptor.  Perhaps even if
+an operation's associated identity is unchanged, another parameter can be used
+to provide access as another user.  This would be a special cue to the
+Authorization
+subsystem.</p>
+        <p>
+These limitations just show us that we're missing something in the design of the
+Interceptor Mechanism.  Whether we need to handle sub-operations with special
+authorization measures, selectively bypass or require specific Interceptors
+something is
+required.</p>
+      </subsection>
+    </section>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/developers/interceptor_interactions.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/developers/interceptor_mechanism.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/developers/interceptor_mechanism.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/developers/interceptor_mechanism.xml (added)
+++ directory/apacheds/trunk/xdocs/developers/interceptor_mechanism.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,115 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="akarasulu">akarasulu</author>
+    <title>Interceptor Mechanism</title>
+  </properties>
+  <body>
+    <section heading="h2" name="What is it?">
+      <p>
+The mechanism is a means for injecting and isolating orthogonal services into
+calls against the nexus.  The nexus is the hub used to route calls to partitions
+to perform CRUD operations upon entries.  By injecting these services at this
+level, partition implementators need not duplicate fuctionality.  Services such
+as authentication, authorization, schema checking, normalization, operational
+attribute maintenance and more are introduced using Interceptors.  By using
+interceptors partition implementors need not be concerned with these aspects and
+can focus on raw CRUD operations against their backing stores what ever they may
+be.</p>
+    </section>
+    <section heading="h2" name="How does it work?">
+      <p>
+Before we talk more about interceptors we must quickly cover the JNDI provider
+implementation since it is somewhat
+related.</p>
+      <subsection heading="h3" name="JNDI Implementation">
+        <p>
+The JNDI implementation is composed of a set of JNDI Context implementations, a
+ContextFactory implementation and a set of helper
+classes.</p>
+        <ul nesting="1">
+          <li>
+DeadContext</li>
+          <li>
+JavaLdapSupport</li>
+          <li>
+ServerContext</li>
+          <li>
+ServerDirContext</li>
+          <li>
+ServerLdapContext</li>
+          <li>
+AbstractContextFactory</li>
+          <li>
+CoreContextFactory</li>
+          <li>
+ServerDirObjectFactory</li>
+          <li>
+ServerDirStateFactory</li>
+        </ul>
+        <p>
+Every JNDI Context implementation in the provider holds a dedicated reference to
+a nexus proxy object.  This proxy contains all the operations that the nexus
+contains.  The proxy  object is at the heart of the mechanism.  We will disuss
+it more after covering the rest of the JNDI
+provider.</p>
+        <p>
+Calls made against JNDI Contexts take relative names as arguments.  These names
+are relative to the distinguished name of the JNDI Context.  Within the Context
+implementations these relative names are transformed into absolute distinguished
+names.  The transformed names are used to make calls against the
+proxy.</p>
+        <p>
+Additional processing may occur before or after a call is made by a context on
+its proxy to manage JNDI provider specific functions.  One such example is the
+handling of Java objects for serialization and the use of object and state
+factories.</p>
+      </subsection>
+      <subsection heading="h3" name="The nexus proxy object">
+        <p>
+As mentioned above, each Context that is created has a nexus proxy.  The proxy
+maintains a handle on the context as
+well.</p>
+        <p>
+The primary job of the proxy is to inject Interceptor based services.  It does
+so by invoking a chain of Interceptors managed by the system.  Interceptors
+mirror the methods that are intercepted on the nexus interface.  When an
+intercepted method is invoked on the proxy, the proxy pushes an Invocation
+object on to the InvocationStack associated with the current executing Thread. 
+The proxy then calls the same method on a chain of Interceptors.  The results of
+the call are returned after the InvocationStack is
+popped.</p>
+        <p>
+The InvocationStack is used to track the calls being intercepted.  Invocation
+objects pushed onto the stack track the context making the call to the proxy,
+the name of the intercepted call and its arguments.  A stack is used because in
+the case of Triggers, stored procedures may be invoked which operate against the
+DIT using JNDI.  These JNDI calls will also be intercepted.  Their Invocation
+object will be stacked on top of the Invocation which raised the Trigger.  This
+way identities and context of operations can be tracked and used by the Trigger
+management system to prevent runnaway cascades or to limit the cascade depth. 
+There are other areas besides just triggers where this stack will serve a
+purpose.</p>
+        <p>
+The InterceptorChain is a container of Interceptors which has the same or
+analogous methods as do Interceptors.  These are for the interceptable methods. 
+A call against the chain invokes the first Interceptor which then usually
+invokes the next interceptor in the chain.  An Interceptor need not call the
+next interceptor however.  It can raise an exception before making the call to
+the next interceptor or it can completely bypass the rest of the chain by just
+returning before calling the next Interceptor.  Interceptors can preprocess the
+arguments, or perform other tasks before they invoke the next Interceptor.  They
+can also catch exceptions raised by other downstream interceptors and respond to
+them to handle errors.  Finally they can perform post processing operations on
+the results of returned values from downstream
+Interceptors.</p>
+        <p>
+One might ask when is the call made against the actual nexus.  This happens
+using a special Interceptor which resides at the end of the chain.  It actually
+makes the call against the nexus and returns the
+results.</p>
+      </subsection>
+    </section>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/developers/interceptor_mechanism.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/users/aci.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/aci.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/users/aci.xml (added)
+++ directory/apacheds/trunk/xdocs/users/aci.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,137 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="akarasulu">akarasulu</author>
+    <title>Using ApacheDS Access Controls</title>
+  </properties>
+  <body>
+    <p>
+ApacheDS uses an adaptation of the X.500 basic access control scheme in
+combination with X.500 subentries to control access to entries and attributes
+within the DIT.  This wiki page will show you how to enable the basic access
+control mechanism and how to define access control information to enable or
+disable access to protected
+resources.</p>
+    <section heading="h2" name="Enabling Basic Access Controls">
+      <p>
+By default the access control subsystem is turned off.  Once enabled everything
+is tightly locked down.  Only the special admin user, *uid=admin,ou=system*, is
+not affected by permissions.  Access to all operations are denied by default
+until enabled using an ACIItem.  For this reason enabling basic access controls
+is a configuration
+option.</p>
+      <p>
+\\</p>
+      <p>
+\\</p>
+      <p>
+To turn on the basic access control mechanism you need to set the
+*accessControlEnabled* property in the configuration to true.  This can be set
+programatically on the StartupConfiguration or via the
+server.xml.</p>
+    </section>
+    <section heading="h2" name="Types of ACI (Access Control Information)">
+      <p>
+Three different kinds of ACI types exist.  All types use the same specification
+syntax for an ACIITem.  These types differ in their placement and manner of use
+within the
+directory.</p>
+      <subsection heading="h3" name="Entry ACI">
+        <p>
+Entry ACI are access controls added to entries to protect that specific entry. 
+Meaning the protoected entry is the entry where the ACI resides.  When
+performing an operation on an entry, ApacheDS checks for the presence of the
+multivalued operational attribute, *entryACI*.  The values of the entryACI
+attribute contain
+ACIItems.</p>
+        <p>
+There is one exception to the rule of consulting entryACI attributes within
+ApacheDS: add operations do not consult the entryACI within the entry being
+added.  This is a security precaution.  If allowed users can arbitrarily add
+entries where they wanted by putting entryACI into the new entry being added. 
+This could comprimise the
+DSA.</p>
+      </subsection>
+      <subsection heading="h3" name="Perscriptive ACI">
+        <p>
+Perscriptive ACI are access controls that are applied to a collection of
+entries, not just to a single entry.  Collections of entries are defined by the
+subtreeSpecifications of subentries.  Hence perscriptive ACI are added to
+subentries as attributes and are applied by ApacheDS to the entries selected by
+the subentry's subtreeSpecification.  ApacheDS uses the *perscriptiveACI*
+multivalued operational attribute within subentries to contain ACIItems that
+apply to the entry
+collection.</p>
+        <p>
+Perscriptive ACI can save much effort when trying to control access to a
+collection of resources.  Perscriptive ACI can even be specified to apply access
+controls to entries that do not yet exist within the DIT.  They are a very
+powerful mechanism and for this reason they are the prefered mechanism for
+managing access to protected resources.  ApacheDS is optimized specifically for
+managing access to collections of entries rather than point entries
+themselves.</p>
+        <p>
+Users should try to avoid entry ACIs whenever possible, and use persriptive ACIs
+instead.  Entry ACIs are more for managing exceptional cases and should not be
+used
+excessively.</p>
+        <p>
+For every type of LDAP operation ApacheDS checks to see if any access control
+subentries include the protected entry in their collection.  The set of
+subentries which include the protected entry are discovered very rapidly by the
+subentry subsystem.  The subentry subsystem caches subtreeSpecifications for all
+subentries within the server so inclusion checks are
+fast.</p>
+        <p>
+For each access control subentry in the set, ApacheDS checks within a
+perscriptive ACI cache for ACI tuples.  ApacheDS also caches perscriptive ACI
+information in a special form called ACI tuples.  This is done so ACIItem
+parsing and conversion to an optimal representations for evaluation is not
+required at access time.  This way access based on perscriptive ACIs is
+determined very
+rapidly.</p>
+      </subsection>
+      <subsection heading="h3" name="Subentry ACI">
+        <p>
+Access to subentries also needs to be controlled.  Subentries are special in
+ApacheDS.  Although they subordinate to an administrative entry (entry of an
+Administrative Point), they are technically considered to be in the same context
+as their administrative entry.  ApacheDS considers the perscriptive ACI applied
+to the administrative entry, to also apply to its
+subentries.</p>
+        <p>
+This however is not the most intuitive mechanism to use for explicitly
+controlling access to subentries.  A more explicit mechanism is used to specify
+ACIs specifically for protecting subentries.  ApacheDS uses the multivalued
+operational attribute, *subentryACI*, within administrative entries to control
+access to immediately subordinate
+subentries.</p>
+        <p>
+Protection policies for ACIs themselves can be managed within the entry of an
+administrative
+point.</p>
+      </subsection>
+    </section>
+    <section heading="h2" name="Simple User Based ACIItem Examples">
+      <p>
+The ACIItem syntax is very expressive and that makes it extremely powerful for
+specifying complex access control policies.  However the syntax is not very easy
+to grasp for beginners.  For this reason we start with simple examples that
+focus on different protection mechanisms offered by the ACIItem syntax.  We do
+this instead of specifying the grammar which is not the best way to learn a
+language.</p>
+      <ul nesting="1">
+        <li>
+          <a href="./granting add permissions to any user.html">Granting ADD Permissions to Any User</a>
+        </li>
+        <li>
+          <a href="./granting add permissions to users in a group.html">Granting ADD Permissions to Users in a Group</a>
+        </li>
+        <li>
+          <a href="./granting modify permissions for password maintenance.html">Granting MODIFY Permissions for Password Maintenance</a>
+        </li>
+      </ul>
+    </section>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/users/aci.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/users/aci_addpermsanyuser.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/aci_addpermsanyuser.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/users/aci_addpermsanyuser.xml (added)
+++ directory/apacheds/trunk/xdocs/users/aci_addpermsanyuser.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,59 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="akarasulu">akarasulu</author>
+    <title>Granting ADD Permissions to Any User</title>
+  </properties>
+  <body>
+    <section heading="h2" name="Granting ADD Permissions to Any User">
+      <p>
+Add operations for regular entries (not subentries) are special in that only
+perscriptive ACI are consulted when determining a requestors ability to add an
+entry.  When the following ACIItem below is added as a perscriptiveACI attribute
+value of a subentry, it allows any user to perform add operations within the
+subtree specified by that
+subentry:</p>
+      <source>{ 
+  identificationTag "allowAddByAnyUser", 
+  precedence 14,
+  authenticationLevel none,
+  itemOrUserFirst userFirst: 
+    { 
+      userClasses { allUsers },
+      userPermissions 
+        { { 
+            protectedItems {entry, allUserAttributeTypesAndValues},
+            grantsAndDenials { grantAdd } 
+        } }
+    } 
+}
+</source>
+      <subsection heading="h3" name="Components Explained">
+        <subsection heading="h4" name="identificationTag">
+          <p>
+It has a unique identification tag so it can easily be retrieved by lookups
+using substring expressions on the id
+tag.</p>
+        </subsection>
+        <subsection heading="h4" name="precedence">
+          <p>
+It has a precedence value which is used to determine the prevailing permission
+when conflicting ACIItems are
+present.</p>
+        </subsection>
+        <subsection heading="h4" name="authenticationLevel">
+          <p>
+The authenticationLevel is the minimum authentication requirement for requestor
+for the ACI to by applied:  According to
+X.501:</p>
+          <p>
+... Strong authentication of the requestor is considered to exceed a requirement
+for simple or no authentication, and simple authentication exceeds a requirement
+for no authentication
+...</p>
+        </subsection>
+      </subsection>
+    </section>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/users/aci_addpermsanyuser.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/users/aci_modifypermsforpasswords.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/aci_modifypermsforpasswords.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/users/aci_modifypermsforpasswords.xml (added)
+++ directory/apacheds/trunk/xdocs/users/aci_modifypermsforpasswords.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,43 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="akarasulu">akarasulu</author>
+    <title>Granting MODIFY Permissions for Password Maintenance</title>
+  </properties>
+  <body>
+    <source>{
+  identificationTag "allowSelfAccessAndModification",
+  precedence 14,
+  authenticationLevel none,
+  itemOrUserFirst userFirst: 
+  {
+    userClasses { thisEntry },
+    userPermissions 
+    { 
+      { protectedItems {entry}, grantsAndDenials { grantModify, grantBrowse, grantRead } },
+      { protectedItems {allAttributeValues {userPassword}}, grantsAndDenials { grantAdd, grantRemove } }
+    } 
+  } 
+}
+</source>
+    <section heading="h2" name="Commentary">
+      <p>
+Note that two different user permissions are used to accurately specify self
+access and self modification of the *userPassword* attribute within the entry. 
+So with the first userPermission of this ACI a user would be able to read all
+attributes and values within his/her entry.  They also have the ability to
+modify the entry but this is moot since they cannot add, remove or replace any
+attributes within their entry.  The second user permission completes the picture
+by granting add and remove permissions to all values of userPassword.  This
+means the user can replace the
+password.</p>
+      <p>
+Modify operations either add, remove or replace attributes and their values in
+LDAP.  X.500 seems to have overlooked the replace capability.  Hence there is no
+such thing as a *grantReplace* permission.  However grantAdd and grantDelete on
+an attribute and its values are both required for a replace operation to take
+place.</p>
+    </section>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/users/aci_modifypermsforpasswords.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: directory/apacheds/trunk/xdocs/users/aci_userclasses.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/aci_userclasses.xml?rev=329360&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/users/aci_userclasses.xml (added)
+++ directory/apacheds/trunk/xdocs/users/aci_userclasses.xml Fri Oct 28 20:07:59 2005
@@ -0,0 +1,147 @@
+<?xml version="1.0" encoding="UTF-8"?>
+
+<document>
+  <properties>
+    <author email="akarasulu">akarasulu</author>
+    <title>User Classes</title>
+  </properties>
+  <body>
+    <section heading="h2" name="What are User Classes?">
+      <p>
+A large part of managing access control information involves the specification
+of *who* can perform *which* operation on *what* protected resource (entries,
+attributes, values etc).  At evaluation time a requestor of an operation is
+known.  The identity of the requestor is checked to see if it falls into the set
+of users authorized to perform the operation.  User classes are hence
+definitions of a set of zero or more users permissions apply to.  Several
+constructs exist for specifying a user
+class.</p>
+    </section>
+    <section heading="h2" name="Simple User Classes">
+      <p>
+There are 3 really simple constructs for specifying the user.  These constructs
+are listed in the table
+below:</p>
+      <table>
+        <tr>
+          <th>
+User Class
+Construct</th>
+          <th>
+Meaning</th>
+          <th>
+Example</th>
+        </tr>
+        <tr>
+          <td>
+allUsers</td>
+          <td>
+Any user w/ possible reqs for
+AuthenticationLevel</td>
+          <td>
+*allUsers*</td>
+        </tr>
+        <tr>
+          <td>
+thisEntry</td>
+          <td>
+The user with the same DN as the entry being
+accessed</td>
+          <td>
+*thisEntry*</td>
+        </tr>
+        <tr>
+          <td>
+name</td>
+          <td>
+The user with the specified
+DN</td>
+          <td>
+*name* \{ "uid=admin, ou=system"
+\}</td>
+        </tr>
+      </table>
+      <p>
+These are pretty intuitive.  Two other user classes may be a bit less easy to
+understand or may require some explanation.  For these we discuss them in the
+sections
+below.</p>
+    </section>
+    <section heading="h2" name="User Class: userGroup">
+      <p>
+The *userGroup* user class specification construct is also pretty intuitive.  It
+does however require some background information about how group membership is
+determined for this
+purpose.</p>
+      <p>
+ApacheDS associates users within a group using the *groupOfNames* and
+*groupOfUniqueNames* objectClasses.  To define groups an entry of either of
+these objectClasses is added anywhere in the server's DIT.  *member* or
+*uniqueMember* attributes whose values are the DN of user entries are present
+within the entry to represent membership within the
+group.</p>
+      <p>
+Although such group entries can be added anywhere within the DIT to be
+recognized by the Authorization subsystem, a recommended convention exists.  Use
+the ou=groups container under a namingContext/partition within the server to
+localize groups.  Most of the time group information can be stored under
+ou=groups,ou=system.</p>
+      <p>
+Just like the *name* construct, the *userGroup* construct takes a single
+parameter: the DN of the group entry.  During ACI evaluation ApacheDS checks to
+see if the requestor's DN is contained within the group.  Below is a section
+from X.501 which explains just how this is
+done:</p>
+      <p>
+In order to determine whether the requestor is a member of a userGroup user
+class, the following criteria
+apply:</p>
+    </section>
+    <section heading="h2" name="User Class: subtree">
+      <p>
+Here the user class specification construct is a subtree specification without a
+refinement filter.  Such a specification is simple yet very powerful.  The
+subtree defined a collection of entries.  During ACI evaluation, ApacheDS will
+check to see if the requestor's DN is included by this
+collection.</p>
+      <p>
+For more information on how to define a subtreeSpecification please
+see
+        <a href="./defining subtree specifications.html">Defining Subtree Specifications</a>
+.
+      </p>
+      <p>
+For this purpose a subtree is not refined.  Meaning it does not evaluate
+refinement filters.  This is to restrict the information needed to make a
+determination to just the DN of the requestor and not the entry of the
+requestor.</p>
+    </section>
+    <section heading="h2" name="Combining Multiple UserClass Specification Mechanisms">
+      <p>
+The same userClass mechanism can be specified more than once if it makes sense. 
+There is no reason to specify allUsers more than one time.  More than one type
+of user class mechanism can be used as well.  Again some combinations just will
+not make sense like having a name based userClass then allUsers.  The following
+ACIItem grants delete abilities to a set of users using more than one machanism.
+It allows jbean, jdoe, all users in the Administrators group to delete entries. 
+It also allows requestors to delete their own user
+entry.</p>
+      <source>{ identificationTag "deleteAci"
+  precedence 255,
+  authenticationLevel simple,
+  itemOrUserFirst userFirst: 
+    {
+      userClasses 
+        { 
+           thisEntry, 
+           name { "uid=jbean,ou=users,ou=system" }, 
+           name { "uid=jdoe,ou=users,ou=system" }, 
+           userGroup { "cn=Administrators,ou=groups,ou=system" } 
+        },
+      userPermissions { { protectedItems {entry}, grantsAndDenials { grantRemove } } } 
+    } 
+}
+</source>
+    </section>
+  </body>
+</document>

Propchange: directory/apacheds/trunk/xdocs/users/aci_userclasses.xml
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message