You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ak...@apache.org on 2005/10/29 05:08:09 UTC
svn commit: r329360 - in /directory/apacheds/trunk/xdocs: developers/ users/
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.&id ({SupportedAttributes}),
+ value ATTRIBUTE.&Type({SupportedAttributes}{@type}) }
+</source>
+ </subsection>
+ <subsection heading="h2" name="BNF grammar">
+ <p>
+Here is the BNF grammar of this ASN.1 grammar
+:</p>
+ <source><wrapperEntryPoint> ::= <theACIItem> EOF
+
+<theACIItem> ::=
+ '{'
+ <spse> <aci_identificationTag> <spse>
+ ',' <spse> <aci_precedence> <spse>
+ ',' <spse> <aci_authenticationLevel> <spse>
+ ',' <spse> <aci_itemOrUserFirst> <spse>
+ '}'
+
+<aci_identificationTag> ::= "identificationTag" <sps> SAFEUTF8STRING
+
+<aci_precedence> ::= "precedence" <sps> INTEGER
+
+<aci_authenticationLevel> ::= "authenticationLevel" <sps> <basicLevels>
+
+<basicLevels> ::= "basicLevels" <spse> ':' <spse> '{' <spse> <level> <spse> <level_follower> '}'
+
+<level> ::= "level" <sps> <levels>
+
+<levels> ::= "none" | "simple" | "strong"
+
+<level_follower> ::= ',' <spse> <localQualifier_signed> | e
+
+<localQualifier_signed> ::=
+ "localQualifier" <sps> INTEGER <spse> <signed_e>
+ | "signed" <sps> <booleanValue> <spse>
+
+<signed_e> ::= ',' <spse> "signed" <sps> <booleanValue> <spse> | e
+
+<booleanValue> ::= "FALSE" | "TRUE"
+
+<aci_itemOrUserFirst> ::= "itemOrUserFirst" <sps> <itemOrUserFirst>
+
+<itemOrUserFirst> ::= <itemFirst> | <userFirst>
+
+<itemFirst> ::= "itemFirst" ':' '{' <spse> <protectedItems> ',' <spse> <itemPermissions> <spse> '}'
+
+<userFirst> ::= "userFirst" ':' '{' <spse> <userClasses> ',' <spse> <userPermissions> <spse> '}'
+
+<protectedItems> ::= "protectedItems" <spse> '{' <spse> <protectedItems_e> <spse> '}'
+
+<protectedItems_e> ::= "entry" <entry_follower_e>
+ | "allUserAttributeTypes" <allUserAttributeTypes_follower_e>
+ | <attributeType> <attributeType_follower_e>
+ | <allAttributeValues> <allAttributeValues_follower_e>
+ | <allUserAttributeTypesAndValues> <allUserAttributeTypesAndValues_follower_>
+ | ATTRIBUTE_VALUE_CANDIDATE <attributeValue_follower_e>
+ | <selfValue> <selfValue_follower_e>
+ | RANGE_OF_VALUES_CANDIDATE <rangeOfValues_follower_e>
+ | <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+ | e
+
+<entry_follower_e> ::= ',' <spse> <entry_follower> | e
+
+<entry_follower> ::=
+ "allUserAttributeTypes" <allUserAttributeTypes_follower_e>
+ | <attributeType> <attributeType_follower_e>
+ | <allAttributeValues> <allAttributeValues_follower_e>
+ | <allUserAttributeTypesAndValues> <allUserAttributeTypesAndValues_follower_e>
+ | ATTRIBUTE_VALUE_CANDIDATE <attributeValue_follower_e>
+ | <selfValue> <selfValue_follower_e>
+ | RANGE_OF_VALUES_CANDIDATE <rangeOfValues_follower_e>
+ | <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+
+<allUserAttributeTypes_follower_e> ::= ',' <spse> <allUserAttributeTypes_follower> | e
+
+<allUserAttributeTypes_follower> ::=
+ <attributeType> <attributeType_follower_e>
+ | <allAttributeValues> <allAttributeValues_follower_e>
+ | <allUserAttributeTypesAndValues> <allUserAttributeTypesAndValues_follower_e>
+ | ATTRIBUTE_VALUE_CANDIDATE <attributeValue_follower_e>
+ | <selfValue> <selfValue_follower_e>
+ | RANGE_OF_VALUES_CANDIDATE <rangeOfValues_follower_e>
+ | <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+
+<attributeType_follower_e> ::= ',' <spse> <attributeType_follower> | e
+<attributeType_follower> ::=
+ <allAttributeValues> <allAttributeValues_follower_e>
+ | <allUserAttributeTypesAndValues> <allUserAttributeTypesAndValues_follower_e>
+ | ATTRIBUTE_VALUE_CANDIDATE <attributeValue_follower_e>
+ | <selfValue> <selfValue_follower_e>
+ | RANGE_OF_VALUES_CANDIDATE <rangeOfValues_follower_e>
+ | <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy< <restrictedBy_follower_e>
+ | <classes>
+
+<allAttributeValues_follower_e> ::= ',' <spse> <allAttributeValues_follower> | e
+
+<allAttributeValues_follower> ::=
+ <allUserAttributeTypesAndValues> <allUserAttributeTypesAndValues_follower_e>
+ | ATTRIBUTE_VALUE_CANDIDATE <attributeValue_follower_e>
+ | <selfValue> <selfValue_follower_e>
+ | RANGE_OF_VALUES_CANDIDATE <rangeOfValues_follower_e>
+ | <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+
+<allUserAttributeTypesAndValues_follower_e> ::= ',' <spse> <allUserAttributeTypesAndValues_follower> | e
+
+<allUserAttributeTypesAndValues_follower> ::=
+ ATTRIBUTE_VALUE_CANDIDATE <attributeValue_follower_e>
+ | <selfValue> <selfValue_follower_e>
+ | RANGE_OF_VALUES_CANDIDATE <rangeOfValues_follower_e>
+ | <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+
+<attributeValue_follower_e> ::= ',' <spse> <attributeValue_follower> | e
+
+<attributeValue_follower> ::=
+ <selfValue> <selfValue_follower_e>
+ | RANGE_OF_VALUES_CANDIDATE <rangeOfValues_follower_e>
+ | <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+
+<selfValue_follower> ::= ',' <spse> <selfValue_follower> | e
+
+<selfValue_follower> ::=
+ RANGE_OF_VALUES_CANDIDATE <rangeOfValues_follower_e>
+ | <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+
+<rangeOfValues_follower> ::= ',' <spse> <rangeOfValues_follower> | e
+
+<rangeOfValues_follower> ::=
+ <maxValueCount> <maxValueCount_follower_e>
+ | <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+
+<maxValueCount_follower> ::= ',' <spse> <maxValueCount_follower> | e
+
+<maxValueCount_follower> ::=
+ <maxImmSub> <maxImmSub_follower_e>
+ | <restrictedBy> <restrictedBy_follower_e>
+ | <classes>
+
+<maxImmSub_follower> ::= ',' <spse> <maxImmSub_follower> | e
+
+<maxImmSub_follower> ::=
+ <restrictedBy> <restrictedBy_follower>
+ | <classes>
+
+<restrictedBy_follower> ::= ',' <spse> <classes> | e
+
+<attributeType> ::= "attributeType" <sps> <attributeTypeSet>
+
+<allAttributeValues> ::= "allAttributeValues" <sps> <attributeTypeSet>
+
+<allUserAttributeTypesAndValues> ::= "allUserAttributeTypesAndValues"
+
+<selfValue> ::= "selfValue" <sps> <attributeTypeSet>
+
+<maxValueCount> ::= "maxValueCount" <sps> '{' <spse> <aMaxValueCount> <spse> <aMaxValueCounts> '}'
+
+<aMaxValueCounts> ::= ',' <spse> <aMaxValueCount> <spse> <aMaxValueCounts> | e
+
+<aMaxValueCount> ::= '{' <spse> "type" <sps> <oid> <spse> ',' <spse> "maxCount" <sps> INTEGER <spse> '}'
+
+<maxImmSub> ::= "maxImmSub" <sps> INTEGER
+
+<restrictedBy> ::= "restrictedBy" <sps> '{' <spse> <restrictedValue> <spse> <restrictedValues> '}'
+
+<restrictedValues> ::= ',' <spse> <restrictedValue> <spse> <restrictedValues> | e
+
+<restrictedValue> ::= '{' <spse> "type" <sps> <oid> <spse> ',' <spse> "valuesIn" <sps> <oid> <spse> '}'
+
+<attributeTypeSet> ::= '{' <spse> <oid> <spse> <attributeTypeSets> '}'
+
+<attributeTypeSets> ::= ',' <spse> <oid> <spse> <attributeTypeSet> | e
+
+<classes> ::= "classes" <sps> <refinement>
+
+<itemPermissions> ::= "itemPermissions" <sps> '{' <spse> <itemPermission_e> '}'
+
+<itemPermission_e> ::= <itemPermission> <spse> <itemPermissions_e> | e
+
+<itemPermissions_e> ::= ',' <spse> <itemPermission> <spse> <itemPermissions_e> | e
+
+<itemPermission> ::= '{' <spse> <precedence_e> <spse> '}'
+
+<precedence_e> ::=
+ "precedence" <sps> INTEGER <spse> ',' <spse> <userClasses> <spse> ',' <spse> <grantsAndDenials>
+ | <userClasses> <spse> ',' <spse> <grantsAndDenials>
+
+<grantsAndDenials> ::= "grantsAndDenials" <sps> '{' <spse> <grantAndDenialsBit_e> '}'
+
+<grantAndDenialsBit_e> ::= <grantAndDenialsBit> <spse> <grantAndDenialsBits_e> | e
+
+<grantAndDenialsBits_e> ::= ',' <spse> <grantAndDenialsBit> <spse> <grantAndDenialsBits_e> | e
+
+<grantAndDenialsBit> ::=
+ "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)
+
+<userClasses> ::= "userClasses" <sps> '{' <spse> <userClasses_e> '}'
+
+<userClasses_e> ::=
+ "allUsers" <allUsers_follower_e> <spse>
+ | "thisEntry" <thisEntry_follower_e> <spse>
+ | <name> <name_follower_e> <spse>
+ | <userGroup> <userGroup_follower_e> <spse>
+ | <subtree> <spse>
+ | e
+
+<allUsers_follower_e> ::= ',' <spse> <allUsers_follower> | e
+
+<allUsers_follower> ::=
+ "thisEntry" <thisEntry_follower_e>
+ | <name> <name_follower_e>
+ | <userGroup> <userGroup_follower_e>
+ | <subtree>
+
+<thisEntry_follower_e> ::= ',' <spse> <thisEntry_follower> | e
+
+<thisEntry_follower> ::=
+ <name> <name_follower_e>
+ | <userGroup> <userGroup_follower_e>
+ | <subtree
+
+<name_follower> ::= ',' <spse> <name_follower> | e
+
+<name_follower> ::=
+ <userGroup> <userGroup_follower_e>
+ | <subtree>
+
+<userGroup_follower_e> ::= ',' <spse> <subtree> | e
+
+<name> ::= "name" <sps> '{' <spse> SAFEUTF8STRING <spse> <names_e> '}'
+
+<names_e> ::= ',' <spse> SAFEUTF8STRING <spse> <names_e> | e
+
+<userGroup> ::= "userGroup" <sps> '{' <spse> SAFEUTF8STRING <spse> <userGroups_e> '}'
+
+<userGroups_e> ::= ',' <spse> SAFEUTF8STRING <spse> <userGroups_e> | e
+
+<subtree> ::= "subtree" <sps> '{' <spse> <subtreeSpecification> <spse> <subtrees_e> '}'
+
+<subtrees_e> ::= ',' <spse> <subtreeSpecification> <spse> <subtrees_e> | e
+
+<userPermissions> ::= "userPermissions" <sps> '{' <spse> <userPermissions_ee> '}'
+
+<userPermissions_ee> ::= <userPermission> <spse> <userPermissions_e> | e
+
+<userPermissions_e> ::= ',' <spse> <userPermission> <spse> <userPermissions_e> | e
+
+<userPermission> ::= '{' <spse> <precedence_ee> <spse> '}'
+
+<precedence_ee> ::=
+ "precedence" <sps> INTEGER <spse> ',' <spse> <protectedItems> <spse> ',' <spse> <grantsAndDenials>
+ | <protectedItems> <spse> ',' <spse> <grantsAndDenials>
+
+<subtreeSpecification> ::= '{' <spse> <subtreeSpecification_e> '}'
+
+<subtreeSpecification_e> ::=
+ <ss_base> <ss_base_follower_e> <spse>
+ | <ss_specificExclusions> <ss_specificExclusions_follower_e> <spse>
+ | <ss_minimum> <ss_minimum_follower_e> <spse>
+ | <ss_maximum> <ss_maximum_follower_e> <spse>
+ | <ss_specificationFilter> <spse>
+ | e
+
+<ss_base_follower_e> ::= ',' <spse> <ss_base_follower> | e
+
+<ss_base_follower> ::=
+ <ss_specificExclusions> <ss_specificExclusions_follower_e>
+ | <ss_minimum> <ss_minimum_follower_e>
+ | <ss_maximum> <ss_maximum_follower_e>
+ | <ss_specificationFilter>
+
+<ss_specificExclusions_follower_e> ::= ',' <spse> <ss_specificExclusions_follower> | e
+
+<ss_specificExclusions_follower> ::=
+ <ss_minimum> <ss_minimum_follower_e>
+ | <ss_maximum> <ss_maximum_follower_e>
+ | <ss_specificationFilter>
+
+<ss_minimum_follower_e> ::= ',' <spse> <ss_minimum_follower> | e
+
+<ss_minimum_follower> ::=
+ <ss_maximum> <ss_maximum_follower_e>
+ | <ss_specificationFilter>
+
+<ss_maximum_follower_e> ::= ',' <spse> <ss_specificationFilter> | e
+
+<ss_base> ::= "base" <sps> SAFEUTF8STRING
+
+<ss_specificExclusions> ::= "specificExclusions" <sps> <specificExclusions>
+
+<specificExclusions> ::= '{' <spse> <specificExclusions_e> '}'
+
+<specificExclusions_e> ::= <specificExclusion> <spse> <specificExclusions_ee> | e
+
+<specificExclusions_ee> ::= ',' <spse> <specificExclusion> <spse> <specificExclusions_ee> | e
+
+<specificExclusion> ::= "chopBefore" ':' SAFEUTF8STRING | "chopAfter" ':' SAFEUTF8STRING
+
+<ss_minimum> ::= "minimum" <sps> INTEGER
+
+<ss_maximum> ::= "maximum" <sps> INTEGER
+
+<ss_specificationFilter> ::= "specificationFilter" <sps> <refinement>
+
+<oid> ::= DESCR | NUMERICOID
+
+<refinement> ::= <item> | <and> | <or> | <not>
+
+<item> ::= "item" ':' <oid>
+
+<and> ::= "and" ':' <refinements>
+
+<or> ::= "or" ':' <refinements>
+
+<not> ::= "not" ':' <refinements>
+
+<refinements> ::= '{' <spse> <refinements_e> '}'
+
+<refinements_e> ::= <refinement> <spse> <refinements_ee> | e
+
+<refinements_ee> ::= ',' <spse> <refinement> <spse> <refinements_ee> | e
+
+<sps> ::= ' ' <spse>
+
+<spse> ::= ' ' <spse> | 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 ) => NUMERICOID
+ |
+ INTEGER
+ ;
+
+SAFEUTF8STRING : '"'! ( SAFEUTF8CHAR )* '"'! ;
+
+DESCR
+ :
+ ( "attributeValue" ( ' '! )+ '{' ) =>
+ "attributeValue"! ( ' '! )+ '{'! (options { greedy=false;}:. )* '}'!
+ | ( "rangeOfValues" ( ' '! )+ '(') =>
+ "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&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&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