directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From akaras...@apache.org
Subject svn commit: r329915 - in /directory/apacheds/trunk/xdocs/users: acareas.xml authentication.xml building.xml configuration.xml partitions.xml plugin.xml subentries.xml userclasses.xml
Date Mon, 31 Oct 2005 21:29:02 GMT
Author: akarasulu
Date: Mon Oct 31 13:28:28 2005
New Revision: 329915

URL: http://svn.apache.org/viewcvs?rev=329915&view=rev
Log:
latest xdoc generation from confluence pages

Modified:
    directory/apacheds/trunk/xdocs/users/acareas.xml
    directory/apacheds/trunk/xdocs/users/authentication.xml
    directory/apacheds/trunk/xdocs/users/building.xml
    directory/apacheds/trunk/xdocs/users/configuration.xml
    directory/apacheds/trunk/xdocs/users/partitions.xml
    directory/apacheds/trunk/xdocs/users/plugin.xml
    directory/apacheds/trunk/xdocs/users/subentries.xml
    directory/apacheds/trunk/xdocs/users/userclasses.xml

Modified: directory/apacheds/trunk/xdocs/users/acareas.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/acareas.xml?rev=329915&r1=329914&r2=329915&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/acareas.xml (original)
+++ directory/apacheds/trunk/xdocs/users/acareas.xml Mon Oct 31 13:28:28 2005
@@ -8,11 +8,11 @@
   <body>
     <section heading="h1" name="Introduction">
       <p>
-This guide will show you how to create an Access Control Specific Area and inner
-areas for administering access controls within ApacheDS.  Basic knowledge of the
-X.500 administrative model is presumed along with an understanding of the Basic
-Access Control Scheme in X.501.  For quick primers please take a look at the
-following
+This guide will show you how to create an Access Control Specific Area and
+Access Control Inner Areas for administering access controls within ApacheDS.
+Basic knowledge of the X.500 administrative model is presumed along with an
+understanding of the Basic Access Control Scheme in X.501. For quick primers
+please take a look at the following
 documentation:</p>
       <ul nesting="1">
         <li>
@@ -28,15 +28,15 @@
     <section heading="h1" name="Creating Access Control Specific Areas (ACSA)">
       <p>
 An access control specific area is an Autonomous Administrative Area (AAA) for
-managing access control specific aspects of a subtree within the DIT.  Like all
+managing access control specific aspects of a subtree within the DIT. Like all
 administrative areas, an access control specific area is rooted at a vertex
-entry called the Administrative Point (AP).  The ACSA spans down until leaf
-entries are encountered or until another ACSA is encountered.  Access control
+entry called the Administrative Point (AP). The ACSA spans down until leaf
+entries are encountered or until another ACSA is encountered. Access control
 specific areas do not
 overlap.</p>
       <p>
-Under the AP, you can add subentries that contain prescriptiveACI attributes. 
-Zero or more subentries can be added, each with one or more prescriptiveACI. 
+Under the AP, you can add subentries that contain prescriptiveACI attributes.
+Zero or more subentries can be added, each with one or more prescriptiveACI.
 These subentries apply access control information (ACI) in these prescriptiveACI
 attributes to collections of entries within the
 ACSA.</p>
@@ -51,14 +51,14 @@
         </p>
         <p>
 Most of the time users will create partitions in the server and set the root
-context of the partition (it's suffix) to be the AP for a ACSA.  For example the
+context of the partition (its suffix) to be the AP for a ACSA. For example the
 default server.xml for ApacheDS ships with a partition with the suffix,
-dc=example,dc=com.  We can use this suffix entry as the AP and our ACSA can
+'dc=example,dc=com'. We can use this suffix entry as the AP and our ACSA can
 cover all entries under and including
-dc=example,dc=com.</p>
+'dc=example,dc=com'.</p>
         <p>
-The code below binds to the server as admin (uid=admin,ou=system) and modifies
-the suffix entry to become an ACSA.  Note that we check to make sure the
+The code below binds to the server as admin ('uid=admin,ou=system') and modifies
+the suffix entry to become an ACSA. Note that we check to make sure the
 attribute does not already exist before attempting the add
 operation.</p>
         <source>  ...
@@ -85,16 +85,16 @@
 </source>
         <p>
 This simple modification of adding the value 'accessControlSpecificArea' to the
-administrativeRole makes the suffix entry dc=example,dc=com an AP for an access
-control specific area. Now you can add subentries to your heart's content which
-subordinate to the
+administrativeRole makes the suffix entry 'dc=example,dc=com' an AP for an
+access control specific area. Now you can add subentries to your heart's content
+which subordinate to the
 AP.</p>
       </subsection>
     </section>
     <section heading="h1" name="Creating an Access Control Inner Administrative Area">
       <p>
-Creating an inner area involves the same process.  In fact the same code can be
-used by changing the value added to the administrativeRole attribute.  To create
+Creating an inner area involves the same process. In fact the same code can be
+used by changing the value added to the administrativeRole attribute. To create
 the inner area just add 'accessControlInnerArea' for the administrativeRole
 within the AP: same steps, same code, different value for the
 administrativeRole.</p>
@@ -102,10 +102,10 @@
     <section heading="h1" name="Access Control Subentries">
       <p>
 After creating the access control area you can create subentries that
-subordinate to this AP for managing access to it and anything below.  Access
+subordinate to this AP for managing access to it and anything below. Access
 control subentries are entries with the objectClasses: 'subentry' and
-'accessControlSubentry'.  An access control subentry must contain 3 attributes
-other than the obvious objectClass attribute.  These required attributes are
+'accessControlSubentry'. An access control subentry must contain 3 attributes
+other than the obvious objectClass attribute. These required attributes are
 listed
 below:</p>
       <table>

Modified: directory/apacheds/trunk/xdocs/users/authentication.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/authentication.xml?rev=329915&r1=329914&r2=329915&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/authentication.xml (original)
+++ directory/apacheds/trunk/xdocs/users/authentication.xml Mon Oct 31 13:28:28 2005
@@ -46,26 +46,26 @@
 .
         </p>
       </subsection>
-      <subsection heading="h3" name="How do I bind as the admin superuser after initial
startup?">
+      <subsection heading="h3" name="How to bind as the admin superuser after initial
startup?">
         <p>
 You just downloaded the server and started it up for the first time. Now you're
 wondering how to bind to the server using an LDAP client like jxplorer, gq, or
 ldapbrowser.</p>
         <p>
 By default the super user or admin account is created when the system partition
-is created under the ou=system naming context. This occurs when the server is
+is created under the 'ou=system' naming context. This occurs when the server is
 started for the first time. The admin user can be found under the following
 DN:</p>
         <source>          uid=admin,ou=system
 </source>
         <p>
 The password is initially set to 'secret'. You definately want to change this
-after starting the server.  For the first time you can bind to the server as
-this user with 'secret' as the
+after starting the server. For the first time you can bind to the server as this
+user with 'secret' as the
 password.</p>
         <p>
 To change the password for the admin user you'll have to make changes to two
-places.  First you'll have to change the password in the directory for the user.
+places. First you'll have to change the password in the directory for the user.
 Second you'll have to change the password in the server.xml configuration file
 for the java.naming.security.credentials
 property.</p>
@@ -77,7 +77,7 @@
         <p>
 Even when anonymous binds are disabled anonymous users can still bind to the
 RootDSE as required by the protocol to lookup supported SASL mechanisms before
-attempting a bind.  Don't worry the RootDSE is read
+attempting a bind. Don't worry the RootDSE is read
 only.</p>
       </subsection>
       <subsection heading="h3" name="Adding and authenticating normal users">
@@ -85,9 +85,9 @@
 By default a user in the server can be just about any entry with a userPassword
 attribute that contains a clear text password. The DN can be anything reachable
 within one of the directory partitions. So if you add a partition to hang off of
-dc=example,dc=com then you can add user entries anywhere under this naming
-context or just add user entries under the ou=system naming context. Below is an
-LDIF of a user you can add to the directory as a test
+'dc=example,dc=com' then you can add user entries anywhere under this naming
+context or just add user entries under the 'ou=system' naming context. Below is
+an LDIF of a user you can add to the directory as a test
 user.</p>
         <source>dn: uid=jdoe,ou=users,ou=system
 cn: John Doe
@@ -133,24 +133,24 @@
       <subsection heading="h3" name="Protecting user passwords">
         <p>
 Without access controls enabled userPasswords and user entries are accessible
-and alterable by all: even anonymous users.  There are however some minimal
+and alterable by all: even anonymous users. There are however some minimal
 built-in rules for protecting users and groups within the server without having
 to turn on the ACI
 subsystem.</p>
         <p>
 Without ACIs the server automatically protects, hides, the admin user from
-everyone but the admin user.  Users cannot see other user entries under the
-'ou=users,ou=system' entry.  So placing new users there automatically protects
-them.  Placing new users anywhere else exposes them.  Groups defined using
+everyone but the admin user. Users cannot see other user entries under the
+'ou=users,ou=system' entry. So placing new users there automatically protects
+them. Placing new users anywhere else exposes them. Groups defined using
 groupOfNames or groupOfUniqueNames under the 'ou=groups,ou=system' are also
-protected from access or alteration by anyone other than the admin user.  Again
+protected from access or alteration by anyone other than the admin user. Again
 this protection is not allowed anywhere else but under these
 entries.</p>
         <p>
 For simple configurations this should provide adequate protection but it lacks
-flexibility.  For advanced configurations users should enable the ACI subsystem.
+flexibility. For advanced configurations users should enable the ACI subsystem.
 This however shuts down access to everything by everyone except the admin user
-which bypasses the ACI subsystem.  Directory administrators should look at the
+which bypasses the ACI subsystem. Directory administrators should look at the
 docomentation on how to specify access control information
 here:
           <a href="./authorization.html">Authorization</a>
@@ -162,7 +162,7 @@
 Anonymous binds come enabled out of the box. So you might want to turn off this
 feature especially if you're not using a version of ApacheDS that is 0.9.3 or
 higher with ACI support. To do so you're going to have to restart the server
-after settting the allowAnonymousAccess property to false in the server.xml
+after setting the allowAnonymousAccess property to false in the server.xml
 configuration
 file.</p>
       </subsection>

Modified: directory/apacheds/trunk/xdocs/users/building.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/building.xml?rev=329915&r1=329914&r2=329915&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/building.xml (original)
+++ directory/apacheds/trunk/xdocs/users/building.xml Mon Oct 31 13:28:28 2005
@@ -32,9 +32,9 @@
       <p>
 When you start the server without a xml conf file arguement default settings are
 used. It tries to bind to 389 but this non-root user does not have the needed
-privledges so it tries to bind on the next available port which is 1024. You may
-like a conf file that can be used to override and set server specific properties
-to control its behavoir. Below we use
+priviledges so it tries to bind on the next available port which is 1024. You
+may like a conf file that can be used to override and set server specific
+properties to control its behavoir. Below we use
 the
         <a href="http://valpithy.notlong.com/">xml configuration</a>
 file that comes preconfigured for Apache under the server/trunk/main

Modified: directory/apacheds/trunk/xdocs/users/configuration.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/configuration.xml?rev=329915&r1=329914&r2=329915&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/configuration.xml (original)
+++ directory/apacheds/trunk/xdocs/users/configuration.xml Mon Oct 31 13:28:28 2005
@@ -8,14 +8,14 @@
   <body>
     <p>
 The Apache Directory team introduced new configuration interface of ApacheDS
-from the version 0.9.1.  This page introduces
+from the version 0.9.1. This page introduces
 it.</p>
     <section heading="h1" name="The Configuration API">
       <p>
 ApacheDS provides its configuration API in the
-org.apache.ldap.server.configuration package.  This package contains concrete
+org.apache.ldap.server.configuration package. This package contains concrete
 configuration instruction classes that you can instantiate and specify in your
-JNDI environment variable.  To put your configuration instruction class into the
+JNDI environment variable. To put your configuration instruction class into the
 JNDI environment
 variable:</p>
       <source>Properties env = new Properties();
@@ -37,23 +37,23 @@
 ApacheDS.</p>
       <subsection heading="h2" name="StartupConfiguration">
         <p>
-This instruction starts up the ApacheDS if it is not started.  Here's the list
-of known
+This instruction starts up the ApacheDS if it is not started. Here's the list of
+known
 properties:</p>
         <ul nesting="1">
           <li>
-authenticatorConfigurations - a collection of AuthenticatorConfigurations. 
+authenticatorConfigurations - a collection of AuthenticatorConfigurations.
 AuthenticatorConfiguration specifies Authenticators that authenticate a user who
-accesses the ApacheDS DIT.  (Default: &lt;all default
+accesses the ApacheDS DIT. (Default: &lt;all default
 authenticators&gt;)</li>
           <li>
 bootstrapSchemas - a set of BootstrapSchemas which are loaded at the first time
 ApacheDS starts up (Default: &lt;all default
 schemas&gt;)</li>
           <li>
-contextPartitionConfigurations - a collection of ContextPartitionConfigurations.
+contextPartitionConfigurations - A collection of ContextPartitionConfigurations.
 ContextPartitionConfiguration specified ContextPartitions that consist the
-ApacheDS DIT.  (Default: no context partitions except system
+ApacheDS DIT. (Default: no context partitions except system
 partition)</li>
           <li>
 accessControl - Set to true if you want to enable access control support of the
@@ -78,41 +78,41 @@
         </ul>
         <p>
 You don't need to specify any properties because all properties have the
-default.  Please use MutableStartupConfiguration to modify any properties
+default. Please use MutableStartupConfiguration to modify any properties
 above.</p>
       </subsection>
       <subsection heading="h2" name="ShutdownConfiguration">
         <p>
-This instruction shuts down the ApacheDS if it is not already shut down. 
-There's no property to
+This instruction shuts down the ApacheDS if it is not already shut down. There's
+no property to
 configure.</p>
       </subsection>
       <subsection heading="h2" name="SyncConfiguration">
         <p>
-This instruction flushes out any I/O buffer or write cache.  There's no property
+This instruction flushes out any I/O buffer or write cache. There's no property
 to
 configure.</p>
       </subsection>
       <subsection heading="h2" name="AddContextPartitionConfiguration">
         <p>
 This instruction adds a new context partition on-the-fly while the ApacheDS is
-running.  There is only one property, 'contextPartitionConfiguration'.  You can
+running. There is only one property, 'contextPartitionConfiguration'. You can
 specify an appropriate ContextPartitionConfiguration to plug a context partition
 into the
 ApacheDS.</p>
       </subsection>
       <subsection heading="h2" name="RemoveContextPartitionConfiguration">
         <p>
-This instruction remove an existing context partition on-the-fly while the
-ApacheDS is running.  There is only one property, 'suffix'.  You can specify the
+This instruction removes an existing context partition on-the-fly while the
+ApacheDS is running. There is only one property, 'suffix'. You can specify the
 suffix of the partition you want to remove from the
 ApacheDS.</p>
       </subsection>
       <subsection heading="h2" name="Running and Choosing Multiple Instances">
         <p>
 You can run multiple instances of ApacheDS by specifying {{instanceId}} to all
-Configuration instructions.  InstanceId can be specified as a constructor
-parameter.  Please take a look at the APi documentation (JavaDoc) for more
+Configuration instructions. InstanceId can be specified as a constructor
+parameter. Please take a look at the API documentation (JavaDoc) for more
 details.</p>
         <source>// Create a configuration instruction that affects an ApacheDS instance
'instance4'.
 Configuration cfg = new MutableStartupConfiguration( "instance4" );
@@ -131,7 +131,7 @@
 The configuration API is designed to fit tightly
 with
         <a href="http://www.springframework.org/">Spring Framework</a>
-.  Here is an example beans xml
+. Here is an example beans xml
 file:
       </p>
       <source>&lt;?xml version="1.0" encoding="UTF-8"?&gt;

Modified: directory/apacheds/trunk/xdocs/users/partitions.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/partitions.xml?rev=329915&r1=329914&r2=329915&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/partitions.xml (original)
+++ directory/apacheds/trunk/xdocs/users/partitions.xml Mon Oct 31 13:28:28 2005
@@ -22,9 +22,12 @@
 entries.
         </p>
         <p>
-Other implementations are possible. I'm particularly interested in memory based
-partitions either BTree based or based on something like
-Prevayer.</p>
+Other implementations are possible like in memory based partitions either BTree
+based or based on something
+like
+          <a href="http://www.prevayler.org/wiki.jsp">Prevayler</a>
+.
+        </p>
         <p>
 Partitions have simple interfaces that can be used to align any data source to
 the LDAP data model thereby accessing it via JNDI or via LDAP over the wire.
@@ -35,26 +38,26 @@
       <subsection heading="h2" name="System Partitions">
         <p>
 The system partition is a very special partition that is hardcoded to hang off
-of the ou=system naming context. It is always present and contains
-administrative and operational information needed by the server to operate.
+of the *ou=system* naming context. It is always present and contains
+administrative and operational informations needed by the server to operate.
 Hence its
 name.</p>
         <p>
-The server's subsystems will use this partition to store information critical to
-its
+The server's subsystems will use this partition to store informations critical
+to its
 operation.</p>
       </subsection>
       <subsection heading="h2" name="Root Nexus">
         <p>
 Several partitions can be assigned to different naming contexts within the
 server so long as their names do not overlap such that one partition's naming
-context is contained within anothers. The root nexus is a fake partition that
+context is contained within another's. The root nexus is a fake partition that
 does not really store entries. It maps other entry storing partitions to naming
 contexts and routes backing store calls to the partition containing the entry
 associated with the
 operation.</p>
       </subsection>
-      <subsection heading="h2" name="User Paritions">
+      <subsection heading="h2" name="User Partitions">
         <p>
 User partitions are partitions added by users. When you download and start using
 the server you may want to create a separate partition to store the entries of
@@ -64,17 +67,17 @@
 server.</p>
       </subsection>
     </section>
-    <section heading="h1" name="Adding User Paritions">
+    <section heading="h1" name="Adding User Partitions">
       <p>
 Adding new application partitions to the server is a matter of adding
 DirectoryPartitionConfiguration objects to the StartupConfigration added to the
 JNDI environment. These properties are used in both standalone and in embedded
-configurations. We will show you how to configure partitions by example using
-xml configuration files with the standalone application and programatically for
+configurations. You'll see how to configure partitions by example using xml
+configuration files with the standalone application and programatically for
 embedding.</p>
       <p>
-Until we fill in this section with more specific examples just geared towards
-the configuration of partitions please
+Until this section is filled with more specific examples just geared towards the
+configuration of partitions please
 see
         <a href="./configuration.html">Configuration</a>
 .
@@ -84,7 +87,7 @@
       <p>
 Things we'd like to do with the existing partitioning scheme and
 beyond.</p>
-      <subsection heading="h2" name="Paritition Nesting">
+      <subsection heading="h2" name="Partition Nesting">
         <p>
 Today we have some limitations to the way we can partition the DIB. Namely we
 can't have a partition within a partition and sometimes this makes sense.
@@ -97,7 +100,7 @@
 goal.
         </p>
       </subsection>
-      <subsection heading="h2" name="Paritition Implementations">
+      <subsection heading="h2" name="Partition Implementations">
         <p>
 Obviously we want as many different kinds of partitions as possible. Some really
 cool ideas have floated around out there for a while. Here's a list of
@@ -112,7 +115,7 @@
 virtualization.</li>
           <li>
 Partitions using other LDAP servers to store their entries. Why do this when
-introducing latency. Perhaps you want to proxy other servers or make other
+introducing latency? Perhaps you want to proxy other servers or make other
 servers behave like the personality of another server all
 together.</li>
           <li>
@@ -126,24 +129,27 @@
 staging data between memory and
 disk.</li>
           <li>
-A partition based on Prevalyer. This is like an in-memory partition but you can
-save it at the end of the day. This might be really useful especially for things
-the system partition which almost always need to be in memory. The system
-partition can do this by using really large caches equal to the number of
-entries in the system
-partition.</li>
+A partition based
+on
+            <a href="http://www.prevayler.org/wiki.jsp">Prevayler</a>
+. This is like an in-memory partition but you can save it at the end of the day.
+This might be really useful especially for things the system partition which
+almost always need to be in memory. The system partition can do this by using
+really large caches equal to the number of entries in the system
+partition.
+          </li>
         </ul>
       </subsection>
       <subsection heading="h2" name="Partitioning Entries Under a Single Context">
         <p>
 Other aspirations include entry partitioning within a container context. Imagine
-having 250 million entries under ou=citizens,dc=census,dc=gov. You don't want
-all 250 million in one partition but would like to sub partition these entries
-under the same context based on some attribute. Basically we will be using the
-attribute's value to implement sub partitioning where within a single context we
-are partitioning entries. The value is used to hash entries across buckets (the
-buckets are other partitions). Yeah this is a bit on the heavy duty end but it
-would be useful in several
+having 250 million entries under '*ou=citizens,dc=census,dc=gov*'. You don't
+want all 250 million in one partition but would like to subpartition these
+entries under the same context based on some attribute. Basically we will be
+using the attribute's value to implement subpartitioning where within a single
+context we are partitioning entries. The value is used to hash entries across
+buckets (the buckets are other partitions). Yes, this is a bit on the heavy duty
+end but it would be useful in several
 situations.</p>
       </subsection>
     </section>

Modified: directory/apacheds/trunk/xdocs/users/plugin.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/plugin.xml?rev=329915&r1=329914&r2=329915&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/plugin.xml (original)
+++ directory/apacheds/trunk/xdocs/users/plugin.xml Mon Oct 31 13:28:28 2005
@@ -20,7 +20,7 @@
         <li>
 Published schemas never really change so why do they need to be in a human
 readable
-form.</li>
+form?</li>
         <li>
 Eventually, schema changes made through LDAP will be preserved through
 restarts.</li>
@@ -134,7 +134,7 @@
 maven:</p>
       <ol nesting="0">
         <li>
-Place your schema files (i.e. foo.schema) with the schema extension into
+Place your schema files (i.e. *foo.schema*) with the schema extension into
 $\{basedir\}/src/main/schema. If you opt to store it in another location you
 must override the maven.ldap.server.schema.dir property in your
 project.properties file. For each schema file add the file base name to the
@@ -163,7 +163,7 @@
 list is a comma separated list of other schema names. These schemas need not be
 present in your project to generate the code for your schema. The dependent
 schema classes must however be present within the server at start up time in
-order to load and use your schema. At the end we list the the default schemas
+order to load and use your schema. At the end we list the default schemas
 already packaged into the server's jar. You can use any one of these schemas as
 dependencies needed by your schema and not worry about their presence. The
 property key base for the schema dependency list is

Modified: directory/apacheds/trunk/xdocs/users/subentries.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/subentries.xml?rev=329915&r1=329914&r2=329915&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/subentries.xml (original)
+++ directory/apacheds/trunk/xdocs/users/subentries.xml Mon Oct 31 13:28:28 2005
@@ -115,14 +115,14 @@
 departments.</p>
       <p>
 Do you really want to manage the corporate product catalog or just let the sales
-department manage it. But what do we mean by manage? You want sales people to
+department manage it? But what do we mean by manage? You want sales people to
 create, and delete entries but they may only trust a few people to do this.
 Others may just view the catelog. Who are the people with add/remove powers and
 why should you have to be involved with deciding this ever changing departmental
 policy? Instead you can delegate the management of access controls in this area
 to a administrative contact in the sales department. The sales contact can then
 administer access controls for their department. They're closer to the people in
-sales then you are and they probably have more bandwidth to handle sales related
+sales than you are and they probably have more bandwidth to handle sales related
 needs than you do. Delegating authority in this fashion is what X.500 engineers
 pioneered in the early 80's with the telecom boom in Europe. They knew different
 authorities will want to manage different aspects of directory administration
@@ -134,35 +134,37 @@
 An administrative area is some part of the directory tree that is arbitrarily
 defined. The tree can be split into different administrative areas to delegate
 authority for managing various aspects of administration. For example you can
-have a partition hanging off of 'dc=example,dc=com' with an 'ou=product catalog'
-area. You may want this area to be managed by the sales department with respect
-to the content, schema, it's visibility, and collective attributes. Perhaps you
-only want to delegate only one aspect of administration , access control, since
-you don't want people messing around with schema. To do so you can define
-everything under 'ou=product catalog' to be an administrative area specifically
-for access control and delegate that aspect only. In that case the entry,
-'ou=product catalog,dc=example,dc=com' becomes an administrative entry. It is
-also the administrative point for the area which is the tree rooted at this
+have a partition hanging off of *'dc=example,dc=com'* with an *'ou=product
+catalog'* area. You may want this area to be managed by the sales department
+with respect to the content, schema, it's visibility, and collective attributes.
+Perhaps you only want to delegate only one aspect of administration , access
+control, since you don't want people messing around with schema. To do so you
+can define everything under *'ou=product catalog'* to be an administrative area
+specifically for access control and delegate that aspect only. In that case the
+entry, *'ou=product catalog,dc=example,dc=com'* becomes an administrative entry.
+It is also the administrative point for the area which is the tree rooted at
+this
 entry.</p>
       <p>
-Not all administrative areas are equal. There are really two kinds. Autonomous
-and inner areas. Autonomous areas are areas of administration that cannot
-overlap. Meaning someone is assigned as the supreme authority for that subtree.
-Inner areas are, as their name suggests, nested administrative areas within
-autonomous areas and other inner areas. Yes, you can nest these inner areas as
-deep as you like. You may be asking yourself what the point to all this is.
-Well, say you're the supreme admin of admins. You delegate the authority to
-manage access control for the corporate catalog to the sales admin. That admin
-may in turn decide to delegate yet another area of the catalog to another
-contact within a different department. You delegate access control management to
-the sales admin over the product catalog. The sales admin realizes that the job
-is way bigger than he can manage so he delegates administration of subtrees in
-the catalog to various contacts in different departments. For example regions of
-the catalog under 'ou=electronics' and 'ou=produce' may be delegated to
-different contacts in their respective departments. However the sales admin
-still reserves the ability to override access controls in the catalog. The sales
-admin can change who manages access controls for different parts of the catalog.
-This chain of delegation is possible using inner administrative
+Not all administrative areas are equal. There are really two kinds :
+*autonomous* and *inner* areas. Autonomous areas are areas of administration
+that cannot overlap. Meaning someone is assigned as the supreme authority for
+that subtree. Inner areas are, as their name suggests, nested administrative
+areas within autonomous areas and other inner areas. Yes, you can nest these
+inner areas as deep as you like. You may be asking yourself what the point to
+all this is. Well, say you're the supreme admin of admins. You delegate the
+authority to manage access control for the corporate catalog to the sales admin.
+That admin may in turn decide to delegate yet another area of the catalog to
+another contact within a different department. You delegate access control
+management to the sales admin over the product catalog. The sales admin realizes
+that the job is way bigger than he can manage so he delegates administration of
+subtrees in the catalog to various contacts in different departments. For
+example regions of the catalog under *'ou=electronics' and 'ou=produce'* may be
+delegated to different contacts in their respective departments. However the
+sales admin still reserves the ability to override access controls in the
+catalog. The sales admin can change who manages access controls for different
+parts of the catalog. This chain of delegation is possible using inner
+administrative
 areas.</p>
     </section>
     <section heading="h2" name="How are administrative areas defined?">
@@ -216,14 +218,14 @@
         </tr>
       </table>
       <p>
-As you can see, 3 aspects, schema, collective attributes, and access control are
-considered. An autonomous administrative area can hence be considered with
-respect to all three specific aspect of administration. If an AP is marked as an
-autonomousArea it generally means that administration of all aspects are allowed
-by the authority. If marked with a specific aspect then only that aspect of
-administration is delegated. The administrativeRole operational attribute is
-multivalued so the uber admin can delegate any number of specific administration
-aspects as he
+As you can see, 3 aspects, *schema*, *collective attributes*, and *access
+control* are considered. An autonomous administrative area can hence be
+considered with respect to all three specific aspect of administration. If an AP
+is marked as an autonomousArea it generally means that administration of all
+aspects are allowed by the authority. If marked with a specific aspect then only
+that aspect of administration is delegated. The administrativeRole operational
+attribute is multivalued so the uber admin can delegate any number of specific
+administration aspects as he
 likes.</p>
       <p>
 Also notice that two aspects, collective attribute and access controls, allow
@@ -248,7 +250,7 @@
       <p>
 Subentries hold administrative information for an IAA or an AAA. These entries
 are of the objectClass 'subentry'. The subentry must contain two attributes: a
-commonName and a subtreeSpecification. The commonName (or cn) is used as the
+*commonName* and a *subtreeSpecification*. The commonName (or cn) is used as the
 subentry's rdn attribute. The subtreeSpecification describes the collection of
 entries within the AA (IAA or AAA) that the administrative instruction applies
 to.</p>
@@ -260,10 +262,10 @@
       <subsection heading="h3" name="Base parameter">
         <p>
 This is the relative name of the root vertex of the subtree relative to the AP.
-So if the AP is 'ou=system' and the base is 'ou=users', the subtree begins at
-'ou=users,ou=system'. The base can be any length of name components including 0
-where it's the empty name "". In this case, the subtree begins at the AP,
-'ou=system' in the example
+So if the AP is *'ou=system'* and the base is *'ou=users'*, the subtree begins
+at *'ou=users,ou=system'*. The base can be any length of name components
+including 0 where it's the empty name "". In this case, the subtree begins at
+the AP, *'ou=system'* in the example
 above.</p>
       </subsection>
       <subsection heading="h3" name="Chop parameters">
@@ -279,8 +281,8 @@
 and its descendants are to be excluded from the
 collection.</p>
           <p>
-When chopBefore is used, the entry specified is excluded from the collection.
-When chopAfter is used the entry is included however all descendants below the
+When *chopBefore* is used, the entry specified is excluded from the collection.
+When *chopAfter* is used the entry is included however all descendants below the
 entry are
 excluded.</p>
         </subsection>
@@ -298,8 +300,8 @@
 however its syntax and expressivity is radically different. Think of a
 specification filter as a simplified form of search filters where all terms only
 test the objectClass attribute and only equality checks can be performed. Oh and
-yes, you do have logical operators like and, or and
-not.</p>
+yes, you do have logical operators like *and*, *or* and
+*not*.</p>
         <p>
 So with a filter you have the ability to "refine" the subtree already specified
 with chop, and base parameters. This "refinement" makes it so the collection is
@@ -325,7 +327,7 @@
 subentries.</p>
         <p>
 ApacheDS does not manage schema using subentries in the formal X.500 sense right
-now. There is a single global subentry defined at 'cn=schema' for the entire
+now. There is a single global subentry defined at *'cn=schema'* for the entire
 DSA. The schema is static and cannot be updated at runtime even by the
 administrator. Pretty rough for now but it's the only lagging subsystem. We'll
 of course make sure this subsystem catches
@@ -382,9 +384,9 @@
         <source>{ base "ou=users" }
 </source>
         <p>
-If this is the subtreeSpecification under the AP, 'ou=system', then it selects
+If this is the subtreeSpecification under the AP, *'ou=system'*, then it selects
 every entry under
-'ou=users,ou=system'.</p>
+*'ou=users,ou=system'*.</p>
         <p>
 OK that was easy so now let's slice and dice the tree now using the minimum and
 maximum chop
@@ -392,17 +394,19 @@
         <source>{ minimum 3, maximum 5 }
 </source>
         <p>
-This selects all entries below 'ou=system' which have a DN size equal to 3 name
-components, but no more than 5. So for example 'uid=jdoe,ou=users,ou=system'
-would be included but 'uid=jack,ou=do,ou=not,ou=select,ou=users,ou=system' would
-not be included. Let's continue and combine the base with just a minimum
+This selects all entries below *'ou=system'* which have a DN size equal to 3
+name components, but no more than 5. So for example
+*'uid=jdoe,ou=users,ou=system'* would be included but
+*'uid=jack,ou=do,ou=not,ou=select,ou=users,ou=system'* would not be included.
+Let's continue and combine the base with just a minimum
 parameter:</p>
         <source>{ base "ou=users", minimum 4 }
 </source>
         <p>
-Here the subtree starts at 'ou=users,ou=system' if the subentry subordinates to
-the AP at 'ou=system'. The user 'uid=jdoe,ou=deepenough,ou=users,ou=system' is
-selected by the spec where as 'uid=jbean,ou=users,ou=system' is
+Here the subtree starts at *'ou=users,ou=system'* if the subentry subordinates
+to the AP at *'ou=system'*. The user
+*'uid=jdoe,ou=deepenough,ou=users,ou=system'* is selected by the spec where as
+*'uid=jbean,ou=users,ou=system'* is
 not.</p>
         <p>
 It's time to add some chop
@@ -414,15 +418,15 @@
 }
 </source>
         <p>
-Again if placed at the AP 'ou=system' this subtree would begin at
-'ou=users,ou=system'. It would not include users that subordinate to it though
+Again if placed at the AP *'ou=system'* this subtree would begin at
+*'ou=users,ou=system'*. It would not include users that subordinate to it though
 because of the minimum constraint since these users would have 3 components in
-their DN. The specific exclusions prevent 'ou=untrusted,ou=users,ou=system' and
-all its descendants from being included in the collection. However
-'uid=jbean,ou=trusted,ou=users,ou=system' would be included since it meets the
-minimum requirement, is a descendant of 'ou=users,ou=system' and is not under
+their DN. The specific exclusions prevent *'ou=untrusted,ou=users,ou=system'*
+and all its descendants from being included in the collection. However
+*'uid=jbean,ou=trusted,ou=users,ou=system'* would be included since it meets the
+minimum requirement, is a descendant of *'ou=users,ou=system'* and is not under
 the excluded DN,
-'ou=untrusted,ou=users,ou=system'.</p>
+*'ou=untrusted,ou=users,ou=system'*.</p>
         <p>
 Note that you can add as many exclusions as you like by comma delimiting them.
 For

Modified: directory/apacheds/trunk/xdocs/users/userclasses.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/userclasses.xml?rev=329915&r1=329914&r2=329915&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/userclasses.xml (original)
+++ directory/apacheds/trunk/xdocs/users/userclasses.xml Mon Oct 31 13:28:28 2005
@@ -10,16 +10,16 @@
       <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
+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
+There are 3 really simple constructs for specifying the user. These constructs
 are listed in the table
 below:</p>
       <table>
@@ -36,7 +36,7 @@
           <td>
 allUsers</td>
           <td>
-Any user w/ possible reqs for
+Any user with possible requirements for
 AuthenticationLevel</td>
           <td>
 *allUsers*</td>
@@ -57,28 +57,28 @@
 The user with the specified
 DN</td>
           <td>
-*name* \{ "uid=admin, ou=system"
+*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
+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
+The *userGroup* user class 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
+*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>
       <table>
         <tr>
@@ -88,18 +88,18 @@
           <td>
             <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>
+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>
           </td>
         </tr>
       </table>
       <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
+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 specification which explains just how this is
 done:</p>
       <p>
 In order to determine whether the requestor is a member of a userGroup user
@@ -109,15 +109,16 @@
     <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
+refinement filter. Such a specification is simple yet very powerful. The subtree
+defines 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="./subentries.html">Subentries</a>
-.
+and the Administrative
+Model.
       </p>
       <table>
         <tr>
@@ -126,8 +127,8 @@
           </td>
           <td>
             <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
+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>
           </td>
@@ -136,12 +137,12 @@
     </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
+The same userClass mechanism can be specified more than once if it makes sense.
+There is no reason to specify allUsers more than once. 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 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"



Mime
View raw message