Merged revisions r540837:541139 from ApacheDS trunk to SASL branch.
git-svn-id: https://svn.apache.org/repos/asf/directory/apacheds/branches/apacheds-sasl-branch@541140 13f79535-47bb-0310-9956-ffa450edef68
diff --git a/core/src/main/java/org/apache/directory/server/core/jndi/ServerLdapContext.java b/core/src/main/java/org/apache/directory/server/core/jndi/ServerLdapContext.java
index bef0287..c432a35 100644
--- a/core/src/main/java/org/apache/directory/server/core/jndi/ServerLdapContext.java
+++ b/core/src/main/java/org/apache/directory/server/core/jndi/ServerLdapContext.java
@@ -184,9 +184,18 @@
*/
public void ldapUnbind() throws NamingException
{
- String bindDn = ( String ) getEnvironment().get( Context.SECURITY_PRINCIPAL );
+ Object dn = getEnvironment().get( Context.SECURITY_PRINCIPAL );;
- super.getNexusProxy().unbind( new UnbindOperationContext( new LdapDN( bindDn ) ) );
+ if ( dn instanceof LdapDN )
+ {
+ super.getNexusProxy().unbind( new UnbindOperationContext( ( LdapDN ) dn ) );
+ }
+ else
+ {
+ String bindDn = ( String ) dn;
+
+ super.getNexusProxy().unbind( new UnbindOperationContext( new LdapDN( bindDn ) ) );
+ }
}
diff --git a/core/src/main/java/org/apache/directory/server/core/partition/AbstractPartitionStructure.java b/core/src/main/java/org/apache/directory/server/core/partition/AbstractPartitionStructure.java
new file mode 100644
index 0000000..9991966
--- /dev/null
+++ b/core/src/main/java/org/apache/directory/server/core/partition/AbstractPartitionStructure.java
@@ -0,0 +1,48 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.directory.server.core.partition;
+
+import org.apache.directory.shared.ldap.name.LdapDN;
+
+/**
+ * This abstract class is just used to implement the utility method needed to build the
+ * global partition structue used by the getBackend method.
+ *
+ * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+ */
+
+public abstract class AbstractPartitionStructure implements PartitionStructure
+{
+ /**
+ * @see PartitionStructure#buildPartitionStructure(PartitionStructure, LdapDN, int, Partition)
+ */
+ public PartitionStructure buildPartitionStructure( PartitionStructure current, LdapDN dn, int index, Partition partition )
+ {
+ if ( index == dn.size() - 1 )
+ {
+ return current.addPartitionHandler( dn.getRdn( index ).toString(), new PartitionHandler( partition ) );
+ }
+ else
+ {
+ return current.addPartitionHandler( dn.getRdn( index ).toString(),
+ buildPartitionStructure( new PartitionContainer(), dn, index + 1, partition ) );
+ }
+ }
+}
diff --git a/core/src/main/java/org/apache/directory/server/core/partition/DefaultPartitionNexus.java b/core/src/main/java/org/apache/directory/server/core/partition/DefaultPartitionNexus.java
index 6b229df..13a30d9 100644
--- a/core/src/main/java/org/apache/directory/server/core/partition/DefaultPartitionNexus.java
+++ b/core/src/main/java/org/apache/directory/server/core/partition/DefaultPartitionNexus.java
@@ -74,7 +74,6 @@
import org.apache.directory.shared.ldap.message.SubentriesControl;
import org.apache.directory.shared.ldap.message.extended.NoticeOfDisconnect;
import org.apache.directory.shared.ldap.name.LdapDN;
-import org.apache.directory.shared.ldap.name.Rdn;
import org.apache.directory.shared.ldap.schema.AttributeType;
import org.apache.directory.shared.ldap.schema.Normalizer;
import org.apache.directory.shared.ldap.schema.UsageEnum;
@@ -124,99 +123,9 @@
/** the backends keyed by normalized suffix strings */
private Map<String, Partition> partitions = new HashMap<String, Partition>();
+ /** A structure to hold all the partitions */
private PartitionStructure partitionList = new PartitionContainer();
- private interface PartitionStructure
- {
- boolean isPartition();
- public PartitionStructure addPartitionHandler( String name, PartitionStructure children );
- }
-
- private class PartitionContainer implements PartitionStructure
- {
- private Map<String, PartitionStructure> children;
-
- private PartitionContainer()
- {
- children = new HashMap<String, PartitionStructure>();
- }
-
- public boolean isPartition()
- {
- return false;
- }
-
- public PartitionStructure addPartitionHandler( String name, PartitionStructure child )
- {
- children.put( name, child );
- return this;
- }
-
- public String toString()
- {
- StringBuilder sb = new StringBuilder();
-
- sb.append( "Partition container :\n" );
-
- for ( PartitionStructure child:children.values() )
- {
- sb.append( '{' ).append( child.toString() ).append( "} " );
- }
-
- return sb.toString();
- }
- }
-
- private class PartitionHandler implements PartitionStructure
- {
- private Partition partition;
-
- private PartitionHandler( Partition partition )
- {
- this.partition = partition;
- }
-
- public boolean isPartition()
- {
- return true;
- }
-
- public PartitionStructure addPartitionHandler( String name, PartitionStructure partition )
- {
- return this;
- }
-
- public Partition getpartition()
- {
- return partition;
- }
-
- public String toString()
- {
- try
- {
- return partition.getSuffix().getUpName();
- }
- catch ( NamingException ne )
- {
- return "Unkown partition";
- }
- }
-}
-
- private PartitionStructure buildPartitionStructure( PartitionStructure current, LdapDN dn, int index, Partition partition )
- {
- if ( index == dn.size() - 1 )
- {
- return current.addPartitionHandler( dn.getRdn( index ).toString(), new PartitionHandler( partition ) );
- }
- else
- {
- return current.addPartitionHandler( dn.getRdn( index ).toString(),
- buildPartitionStructure( new PartitionContainer(), dn, index + 1, partition ) );
- }
- }
-
/** the read only rootDSE attributes */
private final Attributes rootDSE;
@@ -487,12 +396,15 @@
throw new ConfigurationException( "Duplicate partition suffix: " + key );
}
- partitions.put( key, system );
+ synchronized ( partitionList )
+ {
+ partitions.put( key, system );
- buildPartitionStructure( partitionList, system.getSuffix(), 0, system );
+ partitionList.buildPartitionStructure( partitionList, system.getSuffix(), 0, system );
- Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
- namingContexts.add( system.getUpSuffix().getUpName() );
+ Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
+ namingContexts.add( system.getUpSuffix().getUpName() );
+ }
return systemCfg;
}
@@ -662,12 +574,15 @@
partition.init( factoryCfg, config );
}
- partitions.put( partition.getSuffix().toString(), partition );
-
- buildPartitionStructure( partitionList, partition.getSuffix(), 0, partition );
+ synchronized ( partitionList )
+ {
+ partitions.put( partition.getSuffix().toString(), partition );
+
+ partitionList.buildPartitionStructure( partitionList, partition.getSuffix(), 0, partition );
- Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
- namingContexts.add( partition.getUpSuffix().getUpName() );
+ Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
+ namingContexts.add( partition.getUpSuffix().getUpName() );
+ }
}
@@ -683,10 +598,25 @@
Attribute namingContexts = rootDSE.get( NAMINGCTXS_ATTR );
namingContexts.remove( partition.getUpSuffix().getUpName() );
- partitions.remove( key );
- partition.sync();
- partition.destroy();
+ // Create a new partition list.
+ // This is easier to create a new structure from scratch than to reorganize
+ // the current structure. As this strcuture is not modified often
+ // this is an acceptable solution.
+ synchronized (partitionList)
+ {
+ partitions.remove( key );
+
+ partitionList = new PartitionContainer();
+
+ for ( Partition part:partitions.values() )
+ {
+ partitionList.buildPartitionStructure( partitionList, part.getSuffix(), 0, partition );
+ }
+
+ partition.sync();
+ partition.destroy();
+ }
}
@@ -835,19 +765,6 @@
/**
-<<<<<<< .mine
-=======
- * @see Partition#modify(org.apache.directory.shared.ldap.name.LdapDN,javax.naming.directory.ModificationItem[])
- */
- /*public void modify( LdapDN dn, ModificationItemImpl[] mods ) throws NamingException
- {
- Partition backend = getBackend( dn );
- backend.modify( dn, mods );
- }*/
-
-
- /**
->>>>>>> .r530934
* @see Partition#list(org.apache.directory.shared.ldap.name.LdapDN)
*/
public NamingEnumeration list( OperationContext opContext ) throws NamingException
@@ -1116,16 +1033,32 @@
*/
private Partition getBackend( LdapDN dn ) throws NamingException
{
- LdapDN clonedDn = ( LdapDN ) dn.clone();
+ Enumeration<String> rdns = dn.getAll();
+ PartitionStructure currentPartition = partitionList;
- while ( clonedDn.size() > 0 )
+ // This is synchronized so that we can't read the
+ // partitionList when it is modified.
+ synchronized ( partitionList )
{
- if ( partitions.containsKey( clonedDn.toString() ) )
+ // Iterate through all the RDN until we find the associated partition
+ while ( rdns.hasMoreElements() )
{
- return partitions.get( clonedDn.toString() );
+ String rdn = rdns.nextElement();
+
+ if ( currentPartition.contains( rdn ) )
+ {
+ currentPartition = currentPartition.getPartition( rdn );
+
+ if ( currentPartition.isPartition() )
+ {
+ return currentPartition.getPartition();
+ }
+ }
+ else
+ {
+ break;
+ }
}
-
- clonedDn.remove( clonedDn.size() - 1 );
}
throw new LdapNameNotFoundException( dn.getUpName() );
diff --git a/core/src/main/java/org/apache/directory/server/core/partition/PartitionContainer.java b/core/src/main/java/org/apache/directory/server/core/partition/PartitionContainer.java
new file mode 100644
index 0000000..60583e3
--- /dev/null
+++ b/core/src/main/java/org/apache/directory/server/core/partition/PartitionContainer.java
@@ -0,0 +1,133 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.directory.server.core.partition;
+
+import java.util.HashMap;
+import java.util.Map;
+
+/**
+ *
+ * The Partition Container holds entries which can be either Partitions or
+ * Containers.
+ *
+ * We can see them as directories, where Partitions are the files.
+ *
+ * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+ */
+public class PartitionContainer extends AbstractPartitionStructure
+{
+ /** Stores the list of all the descendant partitions and containers */
+ private Map<String, PartitionStructure> children;
+
+ /**
+ * Creates a new instance of PartitionContainer.
+ */
+ public PartitionContainer()
+ {
+ children = new HashMap<String, PartitionStructure>();
+ }
+
+ /**
+ * @see PartitionStructure#isPartition()
+ */
+ public boolean isPartition()
+ {
+ return false;
+ }
+
+ /**
+ * @see PartitionStructure#addPartitionHandler( String, PartitionStructure )
+ */
+ public PartitionStructure addPartitionHandler( String name, PartitionStructure child )
+ {
+ children.put( name, child );
+ return this;
+ }
+
+ /**
+ * @see PartitionStructure#contains( String )
+ */
+ public boolean contains( String name )
+ {
+ return children.containsKey( name );
+ }
+
+ /**
+ * @see PartitionStructure#getPartition()
+ *
+ * As this is a container, we just return null;
+ */
+ public Partition getPartition()
+ {
+ return null;
+ }
+
+ /**
+ * @see PartitionStructure#getPartition( String )
+ */
+ public PartitionStructure getPartition( String name )
+ {
+ if ( children.containsKey( name ) )
+ {
+ return children.get( name );
+ }
+ else
+ {
+ return null;
+ }
+ }
+
+ /**
+ * @see Object#toString()
+ */
+ public String toString()
+ {
+ StringBuilder sb = new StringBuilder();
+
+ sb.append( " { " );
+
+ boolean isFirst = true;
+
+ for ( PartitionStructure child:children.values() )
+ {
+ if ( isFirst )
+ {
+ isFirst = false;
+ }
+ else
+ {
+ sb.append( ", " );
+ }
+
+ if ( child instanceof PartitionContainer )
+ {
+ sb.append( "C:").append( child.toString() );
+ }
+ else
+ {
+ sb.append( "P: " ).append( "'" ).append( child.toString() ).append( "'" );
+ }
+ }
+
+ sb.append( " } " );
+
+ return sb.toString();
+ }
+}
diff --git a/core/src/main/java/org/apache/directory/server/core/partition/PartitionHandler.java b/core/src/main/java/org/apache/directory/server/core/partition/PartitionHandler.java
new file mode 100644
index 0000000..c57d4d4
--- /dev/null
+++ b/core/src/main/java/org/apache/directory/server/core/partition/PartitionHandler.java
@@ -0,0 +1,121 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.directory.server.core.partition;
+
+import javax.naming.NamingException;
+
+/**
+ *
+ * Stores a real Partition. This object is itself stored into a Pazrtition Container.
+ *
+ * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+ */
+public class PartitionHandler extends AbstractPartitionStructure
+{
+ /** The stored partition */
+ private Partition partition;
+
+ /**
+ *
+ * Creates a new instance of PartitionHandler.
+ *
+ * @param partition The partition to store
+ */
+ public PartitionHandler( Partition partition )
+ {
+ this.partition = partition;
+ }
+
+ /**
+ * @see PartitionStructure#isPartition()
+ */
+ public boolean isPartition()
+ {
+ return true;
+ }
+
+ /**
+ * @see PartitionStructure#contains( String )
+ */
+ public boolean contains( String name )
+ {
+ try
+ {
+ return partition.getSuffix().getNormName().equals( name );
+ }
+ catch ( NamingException ne )
+ {
+ return false;
+ }
+ }
+
+ /**
+ * @see PartitionStructure#addPartitionHandler( String, PartitionStructure )
+ */
+ public PartitionStructure addPartitionHandler( String name, PartitionStructure partition )
+ {
+ return this;
+ }
+
+ /**
+ * @see PartitionStructure#getPartition()
+ */
+ public Partition getPartition()
+ {
+ return partition;
+ }
+
+ /**
+ * @see PartitionStructure#getPartition( String )
+ */
+ public PartitionStructure getPartition( String name )
+ {
+ try
+ {
+ if ( partition.getSuffix().getNormName().equals( name ) )
+ {
+ return this;
+ }
+ else
+ {
+ return null;
+ }
+ }
+ catch ( NamingException ne )
+ {
+ return null;
+ }
+ }
+
+ /**
+ * @see Object#toString()
+ */
+ public String toString()
+ {
+ try
+ {
+ return partition.getSuffix().getUpName();
+ }
+ catch ( NamingException ne )
+ {
+ return "Unkown partition";
+ }
+ }
+}
diff --git a/core/src/main/java/org/apache/directory/server/core/partition/PartitionStructure.java b/core/src/main/java/org/apache/directory/server/core/partition/PartitionStructure.java
new file mode 100644
index 0000000..fafae27
--- /dev/null
+++ b/core/src/main/java/org/apache/directory/server/core/partition/PartitionStructure.java
@@ -0,0 +1,89 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ *
+ */
+package org.apache.directory.server.core.partition;
+
+import org.apache.directory.shared.ldap.name.LdapDN;
+
+/**
+ * An interface for PartitionStructure implementations.
+ *
+ * @author <a href="mailto:dev@directory.apache.org">Apache Directory Project</a>
+ */
+public interface PartitionStructure
+{
+ /**
+ * Tells if the implementation is a Partition object. If it's a PartitionContainer
+ * instance, it returns false.
+ *
+ * @return <code>true</code> if the class is an instance of PartitionHandler, false otherwise.
+ */
+ boolean isPartition();
+
+ /**
+ * Add a new Partition to the current container.
+ *
+ * @param name The partition name
+ * @param children The PartitionStructure object (it should be a PartitionHandler)
+ * @return The current PartitionStructure to which a Partition has been added.
+ */
+ PartitionStructure addPartitionHandler( String name, PartitionStructure children );
+
+ /**
+ * Tells if the current PartitionStructure contains the given partition.
+ *
+ * If the PartitionStructure is an instance of PartitionHandler, returns true
+ * if the partition's name equals the given name.
+ *
+ * If the PartitionStructure is an instance of PartitionContainer, returns true
+ * if the container's children contains the given name.
+ *
+ * @param name The name we are looking for
+ * @return <code>true</code> if the PartitionStructure instance contains this name
+ */
+ boolean contains( String name );
+
+ /**
+ * Returns the Partition associated with this name, if any, or null if the name is not
+ * found
+ *
+ * @param name The name we are looking for
+ * @return The associated PartitionHandler or PartitionContainer
+ */
+ PartitionStructure getPartition( String name );
+
+ /**
+ * @return Get the partition if the object is an instance of PartitionHandler, null otherwise
+ */
+ Partition getPartition();
+
+ /**
+ * Construct the global partition structure, assuming the DN passed as an argument is a partition
+ * name.
+ *
+ * This is a recursive method.
+ *
+ * @param current The current structure
+ * @param dn The DN associated with the partition
+ * @param index The current RDN being processed
+ * @param partition The associated partition
+ * @return The modified global structure.
+ */
+ PartitionStructure buildPartitionStructure( PartitionStructure current, LdapDN dn, int index, Partition partition );
+}
diff --git a/src/site/resources/docs/developers/alias-dereferencing.pdf b/src/site/resources/docs/developers/alias-dereferencing.pdf
deleted file mode 100644
index 85c4b3e..0000000
--- a/src/site/resources/docs/developers/alias-dereferencing.pdf
+++ /dev/null
Binary files differ
diff --git a/src/site/resources/docs/developers/alias-dereferencing.sxw b/src/site/resources/docs/developers/alias-dereferencing.sxw
deleted file mode 100644
index 46888c3..0000000
--- a/src/site/resources/docs/developers/alias-dereferencing.sxw
+++ /dev/null
Binary files differ
diff --git a/src/site/resources/docs/users/enablesearchforallusers.ldif b/src/site/resources/docs/users/enablesearchforallusers.ldif
deleted file mode 100644
index 0d8e2f9..0000000
--- a/src/site/resources/docs/users/enablesearchforallusers.ldif
+++ /dev/null
@@ -1,7 +0,0 @@
-dn: cn=enableSearchForAllUsers,dc=example,dc=com
-objectClass: top
-objectClass: subentry
-objectClass: accessControlSubentry
-cn: enableSearchForAllUsers
-subtreeSpecification: {}
-prescriptiveACI: { identificationTag "enableSearchForAllUsers", precedence 14, authenticationLevel simple,itemOrUserFirst userFirst: { userClasses { allUsers }, userPermissions {{protectedItems {entry, allUserAttributeTypesAndValues}, grantsAndDenials{grantRead,grantReturnDN,grantBrowse}}}}}
diff --git a/src/site/resources/images/50k-ft-architecture.png b/src/site/resources/images/50k-ft-architecture.png
deleted file mode 100644
index 6bfb0e0..0000000
--- a/src/site/resources/images/50k-ft-architecture.png
+++ /dev/null
Binary files differ
diff --git a/src/site/resources/images/apache-directory-logo.png b/src/site/resources/images/apache-directory-logo.png
deleted file mode 100644
index d67b41b..0000000
--- a/src/site/resources/images/apache-directory-logo.png
+++ /dev/null
Binary files differ
diff --git a/src/site/resources/images/asf_logo_wide.gif b/src/site/resources/images/asf_logo_wide.gif
deleted file mode 100644
index b240328..0000000
--- a/src/site/resources/images/asf_logo_wide.gif
+++ /dev/null
Binary files differ
diff --git a/src/site/resources/images/icon.png b/src/site/resources/images/icon.png
deleted file mode 100644
index 3be8bbb..0000000
--- a/src/site/resources/images/icon.png
+++ /dev/null
Binary files differ
diff --git a/src/site/sandbox/drafts/draft-ietf-ldapext-acl-model-08.txt b/src/site/sandbox/drafts/draft-ietf-ldapext-acl-model-08.txt
deleted file mode 100644
index a66f95c..0000000
--- a/src/site/sandbox/drafts/draft-ietf-ldapext-acl-model-08.txt
+++ /dev/null
@@ -1,4166 +0,0 @@
-
-
-
-
-
-
-
-Internet-Draft E. Stokes
-LDAP Extensions WG B. Blakley
-Intended Category: Standards Track Tivoli Systems
-Expires: 29 December 2001 R. Byrne
- Sun Microsystems
- R. Huber
- AT&T Laboratories
- D. Rinkevich
- Momenta
- 29 June 2001
-
- Access Control Model for LDAPv3
- <draft-ietf-ldapext-acl-model-08.txt>
-
-STATUS OF THIS MEMO
-
-This document is an Internet-Draft and is in full conformance with all
-provisions of Section 10 of RFC2026.
-
-Internet-Drafts are working documents of the Internet Engineering Task
-Force (IETF), its areas, and its working groups. Note that other groups
-may also distribute working documents as Internet-Drafts. Internet-
-Drafts are draft documents valid for a maximum of six months and may be
-updated, replaced, or obsoleted by other documents at any time. It is
-inappropriate to use Internet-Drafts as reference material or to cite
-them other than as "work in progress."
-
-The list of current Internet-Drafts can be accessed at
-http://www.ietf.org/ietf/1id-abstracts.txt
-
-The list of Internet-Draft Shadow Directories can be accessed at
-http://www.ietf.org/shadow.html.
-
-Comments and suggestions on this document are encouraged. Comments on
-this document should be sent to the LDAPEXT working group discussion
-list:
-
- ietf-ldapext@netscape.com
-
-COPYRIGHT NOTICE
-
-Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-ABSTRACT
-
-This document describes the access control model for the Lightweight
-Directory Application Protocol V3 (LDAPv3) directory service. It
-includes a description of the model, the schema for the model, and the
-LDAP control to the LDAP protocol. The current LDAP APIs are sufficient
-for the access control operations. A separate requirements document for
-access control exists [REQTS]. The access control model used the
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 1]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-requirements document as a guideline for the development of this
-specification and are reflected in this specification to the extent that
-the working group could agree on an access control model.
-
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
-"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" used in this document
-are to be interpreted as described in [Bradner97].
-
-
-
-1. Introduction
-
-The ability to securely access (replicate and distribute) directory
-information throughout the network is necessary for successful
-deployment. LDAP's acceptance as an access protocol for directory
-information is driving the need to provide an access control model
-definition for LDAP directory content among servers within an enterprise
-and the Internet. Currently LDAP does not define an access control
-model, but one is needed to ensure consistent secure access,
-replication, and management across heterogeneous LDAP implementations.
-The major objective is to provide a simple, usable, and implementable,
-but secure and efficient access control model for LDAP accessible
-directory content while also providing the appropriate flexibility to
-meet the needs of both the Internet and enterprise environments and
-policies. This document defines the model, the schema, and the LDAP
-control.
-
-This model does not (and cannot) fully specify the behavior of the
-Access Control Model in a distributed environment (e.g. propagating
-access control information across servers and ACI administration)
-because there is no LDAP standard defining how to distribute directory
-data between LDAP servers. The behavior of the Access Control Model in
-distributed environments is beyond the scope of this model.
-
-The following topics are deemed interesting and useful for future work,
-but are also beyond the scope of this model:
-
- - Permissions based on object class
-
- - Application permissions
-
- - How to get initial entryACI and subtreeACI attributes in the
- directory is server specific
-
- - Use of prescriptive ACIs and scoping via use of a ldapACISubEntry
-
- - Required permissions for LDAP extended operations and LDAP
- controls, such as a proxy permission and permission extensibility
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 2]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- - The access rights required for the creation of the first entry in
- the directory
-
- - filter use in ACI
-
- - Mapping of SASL authentication identities (whose form is mechanism
- specific) to LDAP authorization identities (which are used for
- access control purposes)
-
-
-
-2. The LDAPv3 Access Control Model
-
-Access Control mechanisms evaluate requests for access to protected
-resources and make decisions about whether those requests should be
-granted or denied. In order to make a grant/deny decision about a
-request for access to a protected resource, an access control mechanism
-needs to evaluate policy data. This policy data describes security-
-relevant characteristics of the requesting subject and the rules which
-govern the use of the target object.
-
-No mechanism is defined in this document for storage of access control
-information at the server beyond indicating that the attribute holding
-access control information is an operational attribute.
-
-The access control model defines
-
- - What flows on the wire for interoperability
-
- The existing LDAP protocol flows for ldap operations are used to
- manipulate access control information. These same flows on the wire
- apply when ACI is transmitted during replication. A set of
- permissions and their semantics with respect to ldap operations is
- defined. The permissions parallel the defined set of ldap
- operations. Encoding of access control information on the wire is
- per the LDAPv3 specifications.
-
- There is a LDAP control defined, GetEffectiveRights. LDAP clients
- use the control to manage and administer access control policy
- enforced by LDAP servers.
-
- Servers may store access control information in any way they
- choose. In particular, servers may use the access control
- mechanisms of their datastores to store and enforce LDAP access
- control, or they may implement/exploit access control managers
- external to their datastores. Datastores and external access
- control managers MAY implement any access control rule syntax and
- semantics they choose, but the semantics MUST be compatible with
- those defined in the section titled "Required Permissions for Each
- LDAP Operation".
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 3]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- - Attributes and classes for application portability of access
- control information. Portable (LDAP) applications should only use
- the ACI in this model.
-
- Two access control information attributes (entryACI and subtreeACI)
- for application portability. These attributes are used as input to
- the LDAP APIs so access control information can be addressed
- uniformly independent of how that information is accessed and
- stored at the server. These same attributes appear in LDIF output
- for interchange of access control information.
-
- An access control information subentry class (ldapACISubEntry) and
- a set of attributes (supportedAccessControlSchemes which is used in
- the rootDSE, and accessControlSchemes which is used in the subentry
- ldapACISubEntry) to identity the access control mechanisms
- supported by a server and in a given part of the namespace,
- respectively.
-
- - A mechanism to control access to access control information: The
- access control information operational attributes, entryACI and
- subtreeACI, are also used to control access to access control
- information (controls access to itself). How to get initial
- entryACI and subtreeACI attributes in the directory is server
- specific and beyond the scope of this model.
-
-Servers can support multiple access control mechanisms, but MUST be
-capable of supporting the LDAP Mechanism in the DIT scoped by the
-rootDSE (entire server's DIT) for that server and SHOULD be capable of
-supporting the LDAP mechanism in an arbitrary part (subtree) of the DIT.
-
-The accessControlSchemes attribute in the ldapACISubEntry indicates
-which access control mechanisms are in effect for the scope of that
-ldapACISubEntry. The supportedAccessControlSchemes attribute in the
-rootDSE indicates which access control mechanisms are supported by the
-server; those mechanisms are in effect in that server's DIT unless
-overridden by a mechanism defined in a ldapACISubEntry elsewhere in that
-DIT.
-
-Changing the value(s) of either the supportedAccessControlSchemes or
-accessControlSchemes attributes changes the mechanism(s) in effect for
-the scope of those attributes (where scope is either that of the rootDSE
-or ldapACISubEntry).
-
-Through the use of the supportedAccessControlSchemes attribute in the
-rootDSE and the accessControlSchemes attribute in the ldapACISubEntry,
-it is possible to run multiple mechanisms in either the same subtree or
-separate subtrees. This might occur if the underlying datastore for the
-directory was accessible via LDAP and other applications. In this case,
-LDAP access should always be subjects to the LDAP access controls
-described in this document.
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 4]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-3. Access Control Mechanism Attributes
-
-Two attributes are defined to identify which access control mechanisms
-are supported by a given server and by a given subtree:
-supportedAccessControlSchemes and accessControlSchemes. (We chose these
-names based on the X.500 attribute, AccessControlScheme which is
-single-valued and defined in X.501).
-
-
-3.1 Root DSE Attribute for Access Control Mechanism
-
-The server advertises which access control mechanisms it supports by
-inclusion of the 'supportedAccessControlSchemes' attribute in the root
-DSE. This attribute is a list of OIDs, each of which identify an access
-control mechanism supported by the server. By default, these are also
-the mechanisms in effect in subtrees beneath the root in that server
-unless overridden by a ldapACISubEntry (see section "Subentry Class
-Access Control Mechanism").
-
- (<OID to be assigned>
- NAME 'supportedAccessControlSchemes'
- DESC list of access control mechanisms supported
- by this directory server
- EQUALITY objectIdentifierMatch
- SYNTAX OID
- USAGE dSAOperation
- )
-
-The access control mechanism defined is:
- LDAPv3 <OID to be assigned>
-
-Other vendor access control mechanisms MAY be defined (by OID) and are
-the responsibility of those vendors to provide the definition and OID.
-
-
-3.2 Subentry Class Access Control Mechanism
-
-A given naming context MUST provide information about which access
-control mechanisms are in effect for that portion of the namespace.
-This information is contained in a subentry (ldapACISubEntry class),
-derived from [SUBENTRY]. ldapACISubEntry MAY be used to define the
-scope of an access control mechanism. The value(s) held in the rootDSE
-attribute, supportedAccessControlSchemes, are the mechanisms in effect
-in subtrees beneath the root in that server unless overridden in a
-ldapACISubEntry further down the tree held by that server. The scope of
-that ldapACISubEntry is to the end of the subtree held by that server or
-until another ldapACISubEntry is encountered in that subtree held by
-that server. The ldapACISubEntry class is defined as:
-
-
- ( <OID to be assigned>
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 5]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- NAME 'ldapACISubEntry'
- DESC 'LDAP ACI Subentry class'
- SUP ldapSubEntry STRUCTURAL
- MUST ( accessControlSchemes )
- )
-
-The accessControlSchemes attribute MUST be in each ldapACISubEntry entry
-associated with a naming context whose access control mechanism is
-different from adjacent naming contexts supported by that directory
-server. accessControlSchemes lists the values (list of OIDs) that
-define the access control mechanisms in effect for the scope of that
-ldap access control subentry (either until another ldapACISubEntry is
-encountered in that subtree or end of subtree is reached on the server).
-Although, in general, this attribute will define only a single mechanism
-(single value), more than one mechanism MAY be in effect for the scope
-of that subentry.
-
- (<OID to be assigned>
- NAME 'accessControlSchemes'
- DESC list of access control mechanisms supported
- in this subtree
- EQUALITY objectIdentifierMatch
- SYNTAX OID
- USAGE dSAOperation
- )
-
-
-
-4. The Access Control Information Attributes, Syntax, and Rules
-
-The access control information syntax and attributes, entryACI and
-subtreeACI, are defined as:
-
- (<OID-aci-syntax>
- DESC 'attribute syntax for LDAP access control information'
- )
-
- (<OID to be assigned>
- NAME 'entryACI'
- DESC 'ldap access control information, scope of entry'
- EQUALITY directoryComponentsMatch
- SYNTAX <OID-aci-syntax>
- USAGE directoryOperation
- )
-
- (<OID to be assigned>
- NAME 'subtreeACI'
- DESC 'ldap access control information, scope of subtree'
- EQUALITY directoryComponentsMatch
- SYNTAX <OID-aci-syntax>
- USAGE directoryOperation
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 6]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- )
-
-
-Section 4.1 defines the ABNF and ASN.1 for these attributes, entryACI
-and subtreeACI.
-
-The intent of the attribute definitions is to define a common
-interchange format and have a separation of responsibilities to allow
-different people to administer the different attribute types. (X.500
-overcomes this by allowing access control on a per-value basis, which is
-complex). Any given LDAP server should be able to translate the defined
-attribute into meaningful requests. Each server should be able to
-understand the attribute; there should not be any ambiguity into what
-any part of the syntax means.
-
-While the end goal is to have a common behavior model between different
-LDAP server implementations, the attribute definitions alone will not
-ensure identical ACL processing behavior between servers. Applicability
-and precedence rules for making access decisions are defined later in
-this section. The semantics of how a server interprets the ACI syntax
-are defined in the "Required Permissions for Each LDAP Operation"
-section of this document. Additionally, while the server must recognize
-and act on the attribute when received over the wire, there are no
-requirements for the server to physically store these attributes in this
-form.
-
-The attribute definitions maintain an assumption that the receiving
-server supports ACI inheritance within the security model. If the server
-does not support inheritance, the receiving server must expand any
-inherited information based on the scope flag.
-
-The attributes are defined so access control information (ACI) can be
-addressed in a server in an implementation independent manner. These
-attributes are used in typical LDAP APIs, in LDIF output of ACI and in
-transfer of ACI during replication. These attributes may be queried or
-set on all directory objects. The ABNF and definitions are given below.
-
-
-4.1 The ABNF and ASN.1
-
-
-4.1.1 ACI UTF-8 String Representation
-
-The LDAP string encoding of values of the ACI syntax (<OID-aci-syntax>)
-is described by the following ABNF [ABNF]. This string representation
-MUST be supported.
-
-
- ACI = rights "#" attr "#" generalSubject
-
- rights = (("grant:" / "deny:") permissions) /
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 7]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- ("grant:" permissions ";deny:" permissions)
-
- permissions = 1*(permission)
-
- permission = "a" / ; add
- "d" / ; delete
- "e" / ; export
- "i" / ; import
- "n" / ; renameDN
- "b" / ; browseDN
- "v" / ; view (entry level read permission)
- "t" / ; returnDN
- "r" / ; read
- "s" / ; search filter
- "p" / ; search filter (presence only)
- "w" / ; write (mod-add)
- "o" / ; obliterate (mod-del)
- "c" / ; compare
- "m" / ; make
- "u" / ; unveil (disclose on error permission)
- "g" ; getEffectiveRights
-
- ; permissions r, w, o, s, p, c, m work on attributes
- ; permissions a, d, e, i, n, b, v, t, u, g work on entries
- ; permissions for attributes and permissions for entries are
- ; never found in a single ACI
-
- attr = "[all]" / "[entry]" / (attribute *("," attribute))
-
- attribute = AttributeDescription
- ; The <AttributeDescription> rule is defined
- ; in Section 4.1.5 of [LDAPv3]
-
- generalSubject = context pureSubject
-
- context = "authnLevel:" authnLevel ":"
-
- pureSubject = anySubject / machineSubject / idBasedSubject
-
- anySubject = "public:"
-
- machineSubject = "ipAddress:" ipAddressRange *( "," ipAddressRange ) /
- "dns:" partialdomainname *( "," partialdomainname )
-
- partialdomainname = [ "*." ] domainname
-
-
- idBasedSubject = thisSubject /
- oneSubject /
- setOfSubjects
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 8]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- thisSubject = "this:"
- oneSubject = ( "authzId-" authzId )
- setOfSubjects = ( "role:" dn ) /
- ( "group:" dn ) /
- ( "subtree:" dn )
-
- authnLevel = "none" /
- "weak" /
- "limited" /
- "strong"
-
- ; The <authzId> rule is defined in [AuthMeth]. It is
- ; repeated below for convenience.
-
- authzId = dnAuthzId / uAuthzId
-
- ; distinguished-name-based authz id.
- dnAuthzId = "dn:" dn
-
- dn = utf8string ; with syntax defined in [UTF]
-
- ; unspecified userid, UTF-8 encoded.
- uAuthzId = "u:" userid
- userid = utf8string ; syntax unspecified
- ; A utf8string is defined to be the UTF-8 encoding of
- ; one or more ISO 10646 characters.
-
- ipAddress = IPv6address
-
- ; following is excerpted from [IPV6]
- IPv6address = hexpart [ ":" IPv4address ]
- IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT
-
- hexpart = hexseq | hexseq "::" [ hexseq ] | "::" [ hexseq ]
- hexseq = hex4 *( ":" hex4)
- hex4 = 1*4HEXDIG
-
- ipAddressRange = ipAddress [ HYPHEN ipAddress ] ; IPv6 address range
-
- domainname = domaincomponent *( "." domaincomponent )
-
- OUTER = ALPHA / DIGIT
- INNER = ALPHA / DIGIT / HYPHEN
- HYPHEN = %x2D
- domaincomponent = OUTER [ *61( INNER ) OUTER ]
-
-
-Note that the colon following the "public" and "this" subject options
-exist only to simplify string parsing.
-
-If an ACI is attempted to be added with an authz that is not understood,
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 9]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-then the server MUST reject that entryACI or subEntryACI value. This
-clarifies the statement in [AuthMeth] that allows for authzId may be
-expanded in the future.
-
-See section titled 'ACI Examples' for examples of the string
-representation.
-
-
-
-4.1.2 ACI Binary Representation
-
-The ASN.1 type ACI is used to represent this syntax when transferred in
-binary form. This binary form SHOULD be supported.
-
-
- LDAP-Access-Control-Model
- DEFINITIONS EXTENSIBILITY IMPLIED ::=
- BEGIN
-
- IMPORTS
- AttributeType, DistinguishedName, CONTEXT
- FROM InformationFramework; -- from [X501]
-
- ACI ::= SEQUENCE {
- rights SEQUENCE {
- grant Permissions OPTIONAL,
- deny [1] Permissions OPTIONAL }
- (WITH COMPONENTS { ..., grant PRESENT } |
- WITH COMPONENTS { ..., deny PRESENT }),
- -- at least one of grant or deny must be present --
- attr CHOICE {
- all NULL,
- entry [1] NULL,
- attributes SET (1..MAX) OF AttributeTypeAndOptions },
- authnLevel ::= ENUMERATED {
- none (0),
- weak (1),
- limited (2),
- strong (3)}
- subject GeneralSubject
- }
-
- -- An X.500 representation for an LDAP Attribute Description --
- AttributeTypeAndOptions ::= SEQUENCE {
- type AttributeType,
- type-name UTF8String OPTIONAL,
- -- A hint of what LDAP textual name to use when encoding an
- -- AttributeTypeAndOptions as an <AttributeDescription>.
- options SEQUENCE SIZE (1..MAX) OF CONTEXT.&Assertion OPTIONAL
- -- A future revision will constrain CONTEXT.&Assertion to be
- -- the context assertion syntax of the CONTEXT information
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 10]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- -- object defined by the X.500 working group to represent
- -- LDAP attribute options in the X.500 protocols.
- -- This is likely to be the UTF8String type.
- }
-
- GeneralSubject ::= CHOICE {
- anySubject NULL,
- machineSubject [1] MachineSubject,
- idBasedSubject [2] IDBasedSubject
- -- may be expanded per [AuthMeth] --
- }
-
- MachineSubject ::= CHOICE {
- ipAddress IPAddress,
- dns [1] DomainName
- }
-
- IPAddress ::= UTF8String
-
- -- The character contents of an IPAddress string are encoded
- -- according to the <ipAddress> rule in Section 4.1.1.
-
-
- DomainName ::= UTF8String
-
- -- The character contents of a DomainName string are encoded
- -- according to the <partialdomainname> rule in Section 4.1.1.
-
- IDBasedSubject ::= CHOICE {
- thisSubject NULL,
- oneSubject [1] OneSubject,
- setOfSubjects [2] SetOfSubjects
- }
-
- OneSubject ::= CHOICE {
- dn DistinguishedName,
- user UTF8String
- }
-
- SetOfSubjects ::= CHOICE {
- role DistinguishedName,
- group [1] DistinguishedName,
- subtree [2] DistinguishedName
- }
-
-
- Permissions ::= BIT STRING {
- add (0),
- delete (1),
- export (2),
- import (3),
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 11]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- renameDN (4),
- browseDN (5),
- viewEntry (6),
- returnDN (7),
- read (8),
- search (9),
- searchPresence (10),
- write (11),
- obliterate (12),
- compare (13),
- make (14),
- unveil (15),
- getEffectiveRights (16)
- (CONSTRAINED BY { -- at least one bit must be set -- })
- }
-
- -- permissions read, write, obliterate, search,
- -- searchPresence, compare, make work on attributes
- -- permissions add, delete, export, import, renameDN,
- -- browseDN, viewEntry, returnDN, unveil,
- -- getEffectiveRights work on entries
-
- END
-
-
-
-4.2 The Components of entryACI and subtreeACI Attributes
-
-This section defines components that comprise the access control
-information attributes, entryACI and subtreeACI.
-
-The access control information in the entryACI attribute applies only to
-the entry in which it is contained.
-
-The access control information in the subtreeACI attribute applies to
-each entry down the subtree unless it is overridden by an entry-specific
-entryACI whose values are more specific or another subtreeACI lower in
-the tree.
-
-Use of prescriptive ACIs and scoping via use of a ldapACISubEntry is
-outside the scope of this document.
-
-
-4.2.1 Access Rights and Permissions
-
-Access rights can apply to an entire object or to attributes of the
-object. Access can be granted or denied. Either or both of the actions
-"grant" | "deny" may be used when creating or updating entryACI and
-subtreeACI.
-
-Each of the LDAP access permissions are discrete. One permission does
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 12]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-not imply another permission. The permissions which apply to attributes
-and the entry parallel the type of ldap operations that can be
-performed.
-
-Permissions which apply to attributes:
-
- r Read Read attribute values
- w Write Modify-add values
- o Obliterate Modify-delete values
- s Search Search entries with specified
- attributes
- p searchPresence Presence only filters
- c Compare Compare attributes
- m Make Make attributes on a new entry below
- this entry
-
-
- 1. r Read
-
- If granted, permits attributes and values to be returned in a read
- or search operation.
-
- 2. w Write
-
- If granted, permits attributes and values to be added in a
- modify-add operation.
-
- 3. o Obliterate
-
- If granted, permits attributes and values to be deleted in a
- modify-delete operation.
-
- 4. s Search
-
- If granted, permits attributes and values to be included in the
- search filter of a search operation.
-
- 5. c Compare
-
- If granted, permits attributes and value to be used in a compare
- operation.
-
- 6. p SearchPresence
-
- If granted permits attributes and values to be included in
- presence tests in a search filter.
-
- 7. m Make
-
- The attribute permission "m" is required for all attributes that
- are placed on an object when it is created. Just as the "w" and
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 13]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- "o" permissions are used in the Modify operation, the "m"
- permission is used in the Add operation. Additionally, note that
- "w" and "o" have no bearing on the Add operation and "m" has no
- bearing on the Modify operation. Since a new object does not yet
- exist, the "a" and "m" permissions needed to create it must be
- granted on the new object's parent. This differs from "w" and "o"
- which must be granted on the object being modified. The "m"
- permission is distinct and separate from the "w" and "o"
- permissions so that there is no conflict between the permissions
- needed to add new children to an entry and the permissions needed
- to modify existing children of the same entry.
-
-Note: Modify-replace values of an attribute require both "w" and "o"
-permission.
-
-Permissions that apply to an entire entry:
-
- a Add Add an entry below this entry
- d Delete Delete this entry
- e Export Export entry & subordinates to new
- location
- i Import Import entry & subordinates below this
- entry from some location
- n RenameDN Rename an entry's DN
- b BrowseDN Browse an entry's DN
- v ViewEntry A read level entry permission
- t ReturnDN Allows DN of entry to be disclosed in
- an operation result
- u Unveil This is the discloseOnError permission
- g GetEffectiveRights This is get effective rights
- permission
-
-
- 1. a Add
-
- If granted, permits creation of an entry in the DIT subject to
- access control on all attributes and values to be placed in the
- new entry at time of creation. In order to add an entry,
- permission must also be granted to add all attributes that exist
- in the add operation.
-
- 2. d Delete
-
- If granted, permits the entry to be removed from the DIT
- regardless of controls on attributes within the entry. Delete
- only works on leaf entries (same as X.500).
-
- 3. e Export
-
- If granted, permits an entry and its subordinates (if any) to be
- exported; that is, removed from the current location and placed in
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 14]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- a new location subject to the granting of suitable permission at
- the destination. If the last RDN is changed, Rename is also
- required at the current location. In order to export an entry or
- its subordinates, there are no prerequisite permissions to
- contained attributes, including the RDN attributes; this is true
- even when the operation causes new attribute values to be added or
- removed as the result of the changes of RDN.
-
- 4. i Import
-
- If granted, permits an entry and its subordinates (if any) to be
- imported; that is, removed from some other location and placed
- below the location to which the permission applies subject to the
- granting of suitable permissions at and below the source location.
- In order to import an entry or its subordinates, there are no
- prerequisite permissions to contained attributes, including the
- RDN attributes; this is true even when the operation causes new
- attribute values to be added or removed as the result of the
- changes of RDN.
-
- 5. n RenameDN
-
- Granting Rename is necessary for an entry to be renamed with a new
- RDN. There are many cases here surrounding the use of this
- permission. See the section on 'Modify DN Operation'.
-
- 6. b BrowseDN
-
- If granted, permits entries to be accessed using directory
- operations which do not explicitly provide the name of the entry.
-
- 7. v ViewEntry
-
- If granted, permits entries to be accessed. This entry level read
- permission is useful as it is not dependent on the scope or
- aliasing properties of the entry.
-
- 8. t ReturnDN
-
- If granted, allows the distinguished name of the entry to be
- disclosed in the operation result.
-
- 9. u Unveil
-
- If granted, allows the presence of the entry to be disclosed in
- the case where access is denied to the entry according to the
- access control rules.
-
- 10. g getEffectiveRights
-
- If granted, allows the effective rights on that entry and the
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 15]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- attributes within that entry to be returned, for _any_ subject.
-
-
-4.2.2 Attributes
-
-Attribute describes an attribute name in the form of a dotted decimal
-OID for that <attr>. If the string (OID) refers to an attribute not
-defined in the given server's schema, the server SHOULD report an error.
-The use of "[entry]" or "[all]" helps to focus the permissions to either
-entry or attribute quickly, and hence helps in parsing.
-
-"[entry]" means the permissions apply to the entire object. This could
-mean actions such as delete the object, or add a child object. When
-used in subtreeACI, the specified permissions (on the entry set of
-permissions are legal here - see the ABNF) apply to each entry in the
-subtree.
-
-"[all]" means the permission set applies to all attributes of the entry.
-When used in subtreeACI, "[all]" applies to all attributes of each entry
-in the subtree.
-
-If the keyword "[all]" and another attribute are both specified within
-an ACI, the more specific permission set for the attribute overrides the
-less specific permission set for "[all]".
-
-
-4.2.3 Subjects and Associated Authentication
-
-The following subjects are defined and MUST be supported:
-
- - authzId, defined per [AuthMeth]
-
- - group, defined as the distinguished name of a groupOfNames or
- groupOfUniqueNames entry
-
- - role, asserts a subject's organizational position and entitlement
- to perform the operations appropriate to that organizational
- position. It is implementation defined how the association between
- authorization id and the role dn is made.
-
- - subtree, defined as some distinguished name of a non-leaf node in
- the DIT
-
- - ipAddress, in IPv6 text format [IPV6]
-
- - dnsName, a domain name or a wildcarded (left-most name or most
- specific part) domain name (see ABNF)
-
- - public, defined as public access
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 16]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- - this, defined as the user whose name matches that of the entry
- being accessed
-
-Other parties MAY define other subjects. It is the responsibility of
-those parties to provide the definition. Adding new subjects may
-inhibit interoperability.
-
-A subject may be qualified by the level of authentication required for
-access to a given attribute(s) or entry. authnLevel defines the minimum
-requestor authentication level required for a given ACI. For a
-requestor's authentication level to exceed a minimum requirement, the
-requestor's level must meet or exceed that specified in the ACI.
-
-The authentication levels defined, in increasing order of
-authentication, are:
-
- - none - no name and no password, or name but no password
-
- - weak - authentication mechanisms that are prone to both passive and
- active attacks [ATTACK]; for example, simple authentication (name
- and password)
-
- - limited - authentication mechanisms that protect against passive
- attacks but may be prone to active attacks; for example, DIGEST-MD5
-
- - strong - authentication mechanisms that protect against both
- passive and active attacks; for example, Kerberos with per-
- authentication or PKI authentication
-
-The authnLevel applies to a subject as follows:
-
- - If the ACI is a grant, then the authnLevel applies if the subject
- is authenticated at or above that level.
-
- - If the ACI is a deny, then the authnLevel applies to that subject
- if authenticated at that level AND to all other subjects
- authenticated with levels below that.
-
-Authentication level is always specified in an ACI. For grant, this
-means that you are granted access if you can prove your authentication
-via a strong authentication mechanism, such as a digital signature. For
-deny, the meaning of this is "you are denied access if you are Mr. X and
-you can prove it with a digital signature". If you are not Mr. X you
-are not denied access only if you can prove it (authenticate yourself)
-with a digital signature. In other words, everyone who does not
-authenticate with a digital signature is denied access. Everyone who
-authenticates with a digital signature is allowed access except Mr. X.
-
-A recommended categorization of authentication mechanisms per
-authentication level may be offered separately. For each mechanism
-categorized in the recommendations, implementations SHOULD NOT assign a
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 17]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-higher authentication level, but MAY assign a lower authentication
-level. For mechanisms not covered by the recommendation, the
-implementation SHOULD specify a conservative level. Implementations
-SHOULD provide a means for the directory administrator to disable and/or
-lower the authentication level associated with a mechanism.
-
-Two interesting subjects not explicitly included, but can be composed
-using subject and authnLevel are anonymous and authenticated.
-
- - anonymous: authnLevel=none + anySubject(public)
-
- - authenticated: authnLevel=weak + anySubject(public)
-
-
-4.3 Access Control Decision Making
-
-The ultimate goal of the Access Control Model is to define the way in
-which an LDAP server determines an access control decision for a given
-requested LDAP operation. In fact, a requestor may require several
-individual permissions in order to be authorized to carry out an LDAP
-operation and we define these in section 5. In this section we
-introduce the concepts and algorithm that allow the server to decide if
-a requestor has an individual permission on an individual resource. The
-concepts we require are firstly, the parameters which must be provided
-in order for the Access Control Decision Algorithm to determine whether
-the access is allowed or not. Secondly, we define precisely when a
-given ACI value will be involved in a given access control decision.
-Thirdly, this model defines some precedence rules which the Algorithm
-will use when dealing with more than one ACI value. Finally, we can
-define the Access Control Decision Algorithm which will determine the
-access decision. Throughout, we use the ABNF, when we need to refer to
-portions of individual ACI values.
-
-4.3.1 The Parameters to the Access Decision Algorithm
-
-The decision algorithm answers the question "Does the specified
-requestor have the specified permission on the specified resource?" The
-resource may be an entry (as for the Delete operation) or it may be an
-attribute within an entry (as for the Modify operation) so we
-characterize the resource like this: (targetEntry, targetAttribute
-OPTIONAL).
-
-The requestor is identified primarily by his authorization ID (which may
-be omitted if the requestor has bound anonymously), but also includes
-other context information about the requestor so it is represented like
-this: (authzId OPTIONAL, ipAddress, dnsName, authnLevel).
-
-The permission is one of the valid permissions defined by the model.
-
-So, the parameters to the Access Control Decision Algorithm, which we
-will refer to collectively as "the decision parameters" are:
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 18]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- - resource: (targetEntry, targetAttribute OPTIONAL)
-
- - permission: permissionParameter
-
- - requestorSubject: (authzId OPTIONAL, ipAddress, dnsName,
- authnLevel)
-
-If permissionParameter is an attribute-level parameter then
-targetAttribute must be specified; if it is an entry-level permission
-then targetAttribute is ignored.
-
-The output is either "Access Allowed" or "Access Denied".
-
-
-4.3.2 Applicability Rules
-
-The applicability rules define whether a given ACI value, or portions of
-it, apply to some given decision parameters.
-
-
-4.3.2.1 Applicability Rules for Scope Types
-
-These rules determine whether a specific ACI applies to the targetEntry
-part of the decision parameters.
-
- - If the ACI in question is an entryACI, then ACI applies to the
- resource if the ACI is an attribute of the entry targetEntry.
-
- - If the ACI in question is a subtreeACI, then ACI applies to the
- resource if targetEntry is part of the subtree defined by the entry
- containing the ACI.
-
-
-4.3.2.2 Applicability Rules for Permissions
-
-If permissionParameter is an entry-level permission, then the ACI in
-question applies if permissionParameter is mentioned in the permissions
-list of the ACI.
-
-If permissionParameter is an attribute-level permission, then the ACI in
-question applies if permissionParameter is mentioned in the permissions
-list and the ACI's attribute list applies to the target attribute per
-"Applicability Rules for Attributes".
-
-Note that for an ACI which contains both grant and deny permissions
-lists, the grant permission list may not be available for the purposes
-of this applicability rule--see point 3 in the "Applicability Rules for
-Subjects".
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 19]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-4.3.2.3 Applicability Rules for Attributes
-
-If an attribute is not specified as part of the resource, then this rule
-does not apply. If an attribute is specified, then the ACI in question
-applies if its attribute list is [all] or if targetAttribute is
-explicitly mentioned in the ACI's attribute list.
-
-In the case where targetAttribute is an attribute type with options
-(e.g. sn;lang-en;lang-uk), it is applicable if the ACI's attribute list
-mentions a less specific form of targetAttribute. For example, if the
-list contained "sn;lang-en", then that list applies to the attribute
-"sn;lang-en;lang-uk", but not the attribute "sn".
-
-4.3.2.4 Applicability Rules for Subjects
-
-Call the subject portion of the ACI in question aciSubject. Then to
-determine if aciSubject applies to requestorSubject we apply the
-following rules:
-
- 1. The ACI in question is a grant ACI. Then the ACI applies if both
- the context and pureSubject portions of aciSubject apply, as
- defined in "Applicability Rules for Context" and "Applicability
- Rules for pureSubject" below.
-
- 2. The ACI in question is a deny ACI. There are three possibilities:
-
- a. The pureSubject part applies (according to "Applicability
- Rules for pureSubject"). Then the ACI applies to
- requestorSubject.
-
- b. The pureSubject part does not apply. Then the ACI applies
- to any requestorSubject with an authnLevel less than the
- authnLevel of the ACI.
-
- c. Otherwise the ACI does not apply.
-
- 3. The ACI in question is both a deny and grant ACI. There are three
- possibilities:
-
- a. aciSubject applies when evaluated as a grant ACI (per 1
- above). Both the grant permissions and deny permissions of
- the ACI are available for the purpose of the "Applicability
- Rules for Attributes and Permissions".
-
- b. aciSubject does not apply as a grant ACI but does apply as a
- deny ACI (per 2 above). The deny permissions of the ACI are
- available for the purpose of the "Applicability Rules for
- Attributes" and the "Applicability Rules for Permissions".
-
- c. aciSubject does not apply when evaluated as either a grant
- ACI or a deny ACI. The ACI does not apply to
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 20]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- requestorSubject.
-
-Note: the deny behavior with authnLevel deserves explication. In the
-case where an ACI denies access to a given subject with a given
-authnLevel, then naturally it will deny access to that given subject
-authenticated at authnLevel or above. Similarly, another user
-authenticated at authnLevel or above, to which the pureSubject part does
-not apply, will not be denied those rights by that ACI.
-
-The interesting case is a user authenticated at a lower level than
-authnLevel. For such a user the ACM takes the view that as that user
-has not proved to the system, to a sufficient degree of confidence, that
-the pureSubject portion does not apply to him, then to be safe, he will
-be denied those rights.
-
-So if you deny access to a particular authzId with authnLevel of "none",
-then that authzId will be denied access at any authentication level, but
-it will not affect any other requestors. On the other hand, if you deny
-access to a particular authzId with an authnLevel of "strong", then that
-will deny access to that user when authenticated strongly AND deny
-access to ANY users authenticated with lower authentication levels.
-
-
-4.3.2.5 Applicability Rules for pureSubject
-
-If aciSubject is of type anySubject, then it applies to
-requestorSubject.
-
-If aciSubject is of type machineSubject, then if the ipAddress or dns
-name from requestorSubject matches the ipAddress or dns name range in
-aciSubject, then the ACI applies to requestorSubject if it is a deny ACI
-or the deny part of a grant/deny ACI. A grant ACI (or the grant part of
-a grant/deny ACI) never applies if the subject is ipAddress: or dns:.
-The note at the end of the "Precedence of Subjects within a Scope"
-explains the reasoning behind this rule.
-
-If the aciSubject is of type idBasedSubject, then it applies according
-to the definition in "Applicability Rules for idBasedSubject".
-
-4.3.2.6 Applicability Rules for Context
-
-The context of aciSubject applies to requestorSubject if authnLevel from
-requestorSubject is greater than or equal to the authnLevel specified in
-the context part of aciSubject.
-
-
-4.3.2.7 Applicability Rules for idBasedSubject
-
-If idBasedSubject is of type thisSubject, then it applies to
-requestorSubject if authzId from requestorSubject is of type "dn" and is
-equal to the DN of the resource.
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 21]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-If idBasedSubject is of type oneSubject, then it applies to
-requestorSubject if authzId from requestorSubject is equal to the
-authzId specified in aciSubject.
-
-If idBasedSubject is of type setOfSubjects, then it applies to
-requestorSubject if authzId from requestorSubject is defined to be in
-the set specified in aciSubject (i.e. is in that group, role or
-subtree). The "Precedence of Subjects within a Scope" includes rules
-for determining membership in a setOfSubjects.
-
-
-4.3.3 Precedence Rules
-
-The precedence rules allow the Access Control Decision Algorithm to
-determine which ACI values should take precedence over others.
-
-
-4.3.3.1 Precedence of Scope Types
-
-
- 1. Entry
-
- 2. Subtree
-
-
-4.3.3.2 Precedence of Position in the DIT
-
-For a given subject DN (including authentication level) and target DN,
-subtreeACI lower in the tree take precedence over those higher in the
-tree.
-
-
-4.3.3.3 Precedence of Subjects within a Scope
-
-
- 1. ipAddress or dns in a deny ACI or the deny part of a grant/deny
- ACI
-
- 2. authzId distinguished name ("authzId-dn:") or authzId userid
- ("authzId-u:")
-
- 3. this
-
- 4. role
-
- If the DN of a role or a group appears in a role (e.g. appears as
- a value of roleOccupant in an organizationalRole), it is
- recursively expanded. For determination of precedence, the
- resulting expanded collection of names is considered to have come
- from a role regardless of the original source.
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 22]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- 5. group
-
- If the DN of a role or a group appears in a group, it is
- recursively expanded. For determination of precedence, the
- resulting expanded collection of names is considered to have come
- from a group regardless of the original source.
-
- 6. subtree
-
- Subtrees may contain groups and/or roles. They should be
- recursively expanded. For determination of precedence, members of
- groups or occupants of roles that apply because (after recursive
- expansion) the group or role is contained in a subtree are
- considered to have come from the subtree regardless of the
- original source.
-
- 7. public
-
-The precedence of ipAddress and DNS names are treated specially, and
-depend on the type of ACI involved. Typical situations are:
-
- - If an ACL says to grant on the basis of IP address but deny on the
- basis of some other attribute (username, group, etc....), then the
- behavior we want is "deny". Rationale: the user is prohibited from
- access, regardless of where he's sitting.
-
- - If an ACL says to deny on the basis of IP address but grant on the
- basis of some other attribute (username, group, etc....), then the
- behavior we want is also "deny". Rationale: the user is allowed
- access, but not from where he's sitting.
-
-In addition, a grant to an ipAddress with no other applicable ACI is
-very dangerous from a security point of view, since it would grant
-permissions to ANY user who has access to the machine with the given
-address. Thus ipAddress and dns subjects can be used only to deny
-permission, not to grant them. The "Applicability Rules for
-pureSubject" enforce this.
-
-
-4.3.3.4 Precedence of Attribute Specifications
-
-Access controls specifying "[all]" attributes are of lower precedence
-than specific lists.
-
-
-4.3.3.5 Precedence of grant/deny
-
-Deny takes precedence over grant.
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 23]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-4.3.3.6 Default
-
-Deny is the default when there is no access control information or when
-evaluation of the access control information yields no result that
-allows the requester access.
-
-
-4.3.4 Access Control Decision Algorithm
-
-The Access Control Decision Algorithm takes as input the decision
-parameters defined above and produces a grant or a deny decision.
-
-In the case where we are interested in the permission set for a set of
-entries and attributes (as in the case of evaluating the effective
-rights in section 9), then we must apply the algorithm for each
-entry/attribute and permission pair we are interested in. Naturally
-implementers are free to implement any algorithm which produces the same
-decision given the same input and ACI values in a DIT.
-
-The algorithm has two phases. First, all the potentially applicable ACI
-values are sorted into an ordered list of sets of ACI values of the same
-precedence. Then this list is scanned in order to find the set of ACIs
-which will determine the access decision.
-
-Phase 1: Order the potentially applicable ACI values
-
- 1. Determine all the entryACI and subtreeACI values that apply to
- targetEntry, according to the "Applicability Rules for Scope
- Types".
-
- 2. Sort these ACIs into a list of sets of ACIs of equal precedence,
- according to the "Precedence of Scope Types" and "Precedence of
- Position in the DIT" rules.
-
- 3. Determine which of the collected ACI values from step 1 apply to
- requestorSubject using the "Applicability Rules for Subjects".
- All the ACI values which do not apply to this subject are
- discarded.
-
- 4. The list of sets is sorted according to subject type from the
- "Precedence of Subjects within a Scope" rules.
-
- 5. Now we split the list into two separate lists keeping the same
- relative ordering of sets--one list has the sets that just contain
- ACI values that refer to entry-level permissions and the other has
- the sets that just contain ACI values that refer to attribute-
- level permissions.
-
- 6. Each set in the attribute-level list of sets is further divided
- into a list of sets of equal precedence according to "Precedence
- of Attributes Specification".
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 24]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-Note: At this point we have two lists of sets of ACI values, one dealing
-with entry-level permissions the other dealing with attribute-level
-permissions. The lists have been sorted according to Scope, Position,
-Subject and (for the attribute-level list) Attribute Specification
-precedence rules.
-
-Phase 2: Scan the lists to determine the access decision:
-
- 1. If permissionParameter is an entry-level permission (so that the
- optional targetAttribute field is not specified), then scan the
- list of entry-level sets in order. The first set in the list that
- contains an ACI that applies to permissionParameter (as defined in
- the "Applicability Rules for Permissions" rules) determines the
- access decision--if an ACI in the set grants permissionParameter
- and no other denies it, then access is granted, otherwise access
- is denied.
-
- 2. If permissionParameter is an attribute-level permission then scan
- the list of attribute-level sets in order. The first set in the
- list that contains an ACI that applies to permissionParameter AND
- applies to targetAttribute (as defined in the "Applicability Rules
- for Attributes" and "Applicability Rules for Permissions")
- determines the access decision--if an ACI in the set grants
- permissionParameter and no other denies it, then access is
- granted, otherwise access is denied.
-
-
-4.3.5 Precedence/Inheritance Access Decision Example
-The examples in this section refer to the following directory tree:
-
- dc=com
- |
- +--------+---------------+
- | |
- dc=tivoli dc=sun
- | |
- cn=ellen cn=rob
-
-The ACI at dc=com:
-
- 1. subtreeACI:grant:rsc#[all]#authnLevel:none:public:
- 2. subtreeACI:deny:rsc#userPassword,subtreeACI,entryACI,salary#
- authnLevel:none:public:
- 3. subtreeACI:grant:bvt#[entry]#authnLevel:none:public:
- 4. subtreeACI:grant:rscmow#[all]#authnLevel:strong:
- authzID-dn:cn=rob,dc=sun,dc=com
- 5. subtreeACI:grant:bvtugeinad#[entry]#authnLevel:strong:
- authzID-dn:cn=rob,dc=sun,dc=com
-
-The ACI at dc=tivoli,dc=com:
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 25]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- 6. subtreeACI:grant:rsc;deny:mow#[all]#authnLevel:strong:
- authzID-dn:cn=rob,dc=sun,dc=com
- 7. subtreeACI:deny:einad#[entry]#authnLevel:strong:
- authzID-dn:cn=rob,dc=sun,dc=com
-
-The ACI at cn=ellen,dc=tivoli,dc=com
-
- 8. entryACI:grant:wo#[all]#authnLevel:strong:
- authz-ID-dn:cn=ellen,dc=tivoli,dc=com
- 9. entryACI: deny: wo#entryACI,subtreeACI,salary#authnLevel:strong:
- authz-ID-dn:cn=ellen,dc=tivoli,dc=com
-
-Example #1
-
- subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, strong):
- resource: ("cn=ellen,dc=tivoli,dc=com", salary)
- permission: "w"
-
-Phase 1: Find all applicable ACI based on the Applicability of Scope
- Types.
-
- {1, 2, 3, 4, 5, 6, 7, 8, 9}
-
- Sort by Precedence of Scope Type and Precedence of Position in
- DIT:
-
- {8, 9}, {6, 7}, {1, 2, 3, 4, 5}
-
- Determine which ACI are applicable based on the Subject:
-
- {6, 7}, {1, 2, 3, 4, 5}
-
- Sort by Precedence of Subjects within Scope:
-
- {6, 7}, {4, 5}, {1, 2, 3}
-
- Separate permissions applicable to entry and those applicable
- to attributes:
-
- Entry: {7}, {5}, {3}
- Attr: {6}, {4}, {1, 2}
-
- Sort the permissions applicable to attributes by precedence of
- attribute specification:
-
- Entry: {7}, {5}, {3}
- Attr: {6}, {4}, {2}, {1}
-
-Phase 2: Since "w" is an attribute permission, look at the Attr list.
- ACI 6 in the first sub-list mentions "w" and salary (via
- [all]) so this set defines the access--which is deny.
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 26]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-Example #2
-
- subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
- resource: ("cn=ellen,dc=tivoli,dc=com", salary)
- permission: "w"
-
-Phase 1: First the ACIs are ordered into the following sets whose
- subject matches the subject tuple:
-
- Entry: {7}, {3}
- Attr: {6}, {2}, {1}
-
-Phase 2: For ACI 6 in the first set, which matched the subject because
- of the deny portion and limited < strong, the permissions
- available are "mow". So, this ACI applies to "w" and salary
- (via [all]) and the access is "deny".
-
-Example #3
-
- subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
- resource: ("cn=ellen,dc=tivoli,dc=com", salary)
- permission: "r"
-
-Phase 1: First the ACIs are ordered into the following sets whose
- subject matches the subject tuple:
-
- Entry: {7}, {3}
- Attr: {6}, {2}, {1}
-
-Phase 2: As the grant portion of ACI 6 is not active, the first set
- that contains an ACI that applies to "r" and salary is {2}.
- As 2 denies access, access is denied.
-
-Example #4
-
- subject: ("cn=rob,dc=sun,dc=com", ipaddress, dns name, limited):
- resource: ("cn=ellen,dc=tivoli,dc=com", cn)
- permission: "r"
-
-Phase 1: First the ACIs are ordered into the following sets whose
- subject matches the subject tuple:
-
- Entry: {7}, {3}
- Attr: {6}, {2}, {1}
-
-Phase 2: As the grant portion of ACI 6 is not active, the first set
- that contains an ACI that applies to "r" and cn is {1}. As 1
- grants access, access is granted.
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 27]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-5. Required Permissions for each LDAP Operation
-
-This section defines the required permissions for each LDAP operation.
-Even if these requirements are satisfied, the server may refuse to carry
-out the operation due to other implementation specific security
-considerations. For example, a server may refuse to modify an entry
-because the database where that entry resides is in read only mode.
-Another example might be that although LDAP access control has been
-specified on the userPassword attribute a server may refuse
-modifications due to some server specific policy governing access to
-passwords.
-
-Here, we specify the rights required by a user when performing an LDAP
-operation in terms of the LDAP permissions specified above. Recall that
-"a, d, e, i, n, b, v, t, u" are permissions that apply to entries as a
-whole while permissions "r, s, p, w, o, c, m, g" apply to attributes
-within entries.
-
-Required permissions for LDAP extended operations and LDAP controls
-SHOULD be defined along with their specifications. These requirements
-could be expressed in terms of this model, for example by requiring one
-of the existing permissions on some particular entry or attribute. This
-version of the LDAP access control model does not offer any mechanism to
-extend the permission set or aci syntax to accommodate extended
-operations or controls.
-
-For the following, assume that the authorization identity of the user
-doing the operation is authzId.
-
-
-5.1 Bind Operation
-
-This model does not require any permissions to allow a bind operation to
-proceed.
-
-
-5.2 Search Operation
-
-Recall that the parameters of the Search operation per RFC 2251 [LDAPv3]
-Section 4.5 are:
-
- SearchRequest ::= [APPLICATION 3] SEQUENCE {
- baseObject LDAPDN,
- scope ENUMERATED {
- baseObject (0),
- singleLevel (1),
- wholeSubtree (2) },
- derefAliases ENUMERATED {
- neverDerefAliases (0),
- derefInSearching (1),
- derefFindingBaseObj (2),
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 28]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- derefAlways (3) },
- sizeLimit INTEGER (0 .. maxInt),
- timeLimit INTEGER (0 .. maxInt),
- typesOnly BOOLEAN,
- filter Filter,
- attributes AttributeDescriptionList }
-
-Suppose a server is processing a search request from user authzId with
-parameters as above and is processing the entry with dn candidateDN to
-decide if it may be returned or not.
-
-Then the permissions required by authzId that need to be evaluated are
-as follows:
-
-
- 1. permission "b" to the entry candidateDN if the entry is in the
- scope of the search but is not the base entry.
-
- If this permission is not granted then the dn candidateDN MUST NOT
- be returned nor any attribute type nor attribute value from this
- entry.
-
- Note: the "b" permission is included to allow different browsing
- or discovery rights to be assigned to different classes of users.
-
- 2. permission "v" to the entry candidateDN
-
- If this permission is not granted then the dn candidateDN MUST NOT
- be returned nor any attribute type nor attribute value from this
- entry.
-
- Note A: The "v" permission is the entry level read permission.
- This is included as it is useful to have one simple permission
- (not dependent on scope or aliasing) that protects all the
- components of an entry; the dn and the attributes.
-
- Note B: Disclosing the full distinguished name of an entry will
- inevitiably reveal the names of its ancestors. This issue is
- discussed in detail below.
-
- 3. permission "p" or "s" to each attribute appearing in a search
- filter presence test during the evaluation of the search filter.
- permission "s" is required on attributes appearing in non-presence
- tests (see RFC2254, section 3: equalityMatch, substrings,
- greaterOrEqual, lessOrEqual, present, approxMatch,
- extensibleMatch) during the evaluation of the search filter.
-
- The above statement covers the case where the attributes are being
- evaluated as part of an extensibleMatch (RFC 2251 section 4.5.1)
- which appears in the filter. In the case where the dnAttributes
- field of the extensibleMatch is true (and so the filter test is
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 29]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- applied to the naming attributes in the dn of the entry) then we
- do not require any access checks to the attributes of the dn as
- access to these is taken to be granted by the "v" permission,
- which has already been required above.
-
- If there is an attribute in a filter element to which the required
- permission is not granted then that filter element evaluates to
- "Undefined" of the three-valued-logic of X.511(93).
-
- Note: The motivation for the "p" permission is that if you have
- full filter rights on an attribute then in some cases that could
- be operationally the same as having read permission i.e. you could
- quickly determine the attribute value, and this may not be
- desirable. For example, if the type of the attribute was integer
- then with full filter permissions you could quickly determine the
- value by doing a sequence of binary chop style searches using ">"
- and "<". Whereas, with just the presence test ability, you would
- not have right to do those kind of searches, but you would be able
- to test for the presence of the attribute.
-
- 4. permission "r" to each attribute in the attribute list
- AttributeDescriptionList (or all attributes in the entry
- candidateDN if AttributeDescriptionList is *) whose type and/or
- value will be returned.
-
- Note A: The presence of an attribute in an entry is only ever
- volunteered by the server if "r" permission is granted to it,
- though a user may infer the presence of an attribute with "s" or
- "p" permission by using a presence test on that attribute in the
- search filter.
-
- Note B: Although both "r" and "s" permissions will typically be
- granted to attributes we keep both permissions as there are cases
- where the distinction is useful. A reverse telephone lookup is an
- example of granting "r" but not "s" permission.
-
- 5. permission "t" to the entry candidateDN
-
- If this permission is not granted then the dn candidateDN MUST NOT
- be returned. If the server knows of an alias for the entry, this
- alias may be returned instead. If no alias name is available then
- the entry candidateDN MUST be omitted from the search results.
-
- Note: Disclosing the full distinguished name of an entry will
- inevitiably reveal the names of its ancestors. This issue is
- discussed in detail below.
-
- 6. Disclose on error for the Search operation
-
- If there is no entry in the scope of the search which satisfies
- item 1 (browse right on the candidate entry) and item 2 (read
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 30]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- level permission on the entry) and item 3 (right to use the filter
- on that entry) then the "u" permission on the base entry must be
- evaluated. If "u" (disclose on error) is not granted to the base
- entry then the operation MUST fail with a "no such object error"
- and the matchedDN of the LDAPResult MUST be set to "". If "u" is
- granted to the baseObject then the empty set of results is
- returned.
-
- Note: the point here is that if you do not have the right to
- discover at least one entry in the scope of the search then the
- disclose on error mechanism is there to prevent you discovering
- the base entry of the search. The "t" permission is not
- considered here as it is not conceptually a permission involved in
- the discovery of entries but rather in how they are returned (dn
- vs. alias).
-
-
-5.2.1 Protecting the naming attributes of DNs
-
-Protecting the naming attributes in an entry's dn presents a problem for
-access control. The issue is that if access is granted to the dn of a
-given entry, then via the naming attributes this dn contains, access is
-also also granted to attribute values in other entries. In addition,
-knowledge about the existence of ancestor entries of a given entry is
-also disclosed by the entry's dn.
-
-It could be argued that there should be consistency in the ability of a
-given requestor to see attribute values in the dn of an entry and his
-ability to see those attributes in the entry where they actually reside.
-Similarly, it could be argued that there should be consistency in the
-ability of a requestor to see an entry and his ability to see its
-ancestor entries.
-
-The main reason we do not require such cross checking of permissions is
-because of the extra work it entails for the server. There is a trade
-off between the consistency this cross checking guarantees and the work
-it takes to do that cross checking.
-
-For LDAP servers the trade off has been to go in favor of speed. In
-addition there are some other points which mitigate these kind of
-inconsistencies. Firstly, it appears to be difficult to produce a real
-world example where they really cause a problem. Secondly there are
-other methods of hiding DNs (and hence protecting the naming attribute
-and ancestor information they contain) which are outside the scope of
-access control, for example aliasing and LDAP proxying.
-
-
-5.3 Modify Operation
-
-Recall that the parameters of the Modify operation per RFC2251 [LDAPv3]
-Section 4.6 are:
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 31]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- ModifyRequest ::= [APPLICATION 6] SEQUENCE {
- object LDAPDN,
- modification SEQUENCE OF SEQUENCE {
- operation ENUMERATED {
- add (0),
- delete (1),
- replace (2) },
- modification AttributeTypeAndValues } }
-
- AttributeTypeAndValues ::= SEQUENCE {
- type AttributeDescription,
- vals SET OF AttributeValue }
-
-Then the permissions required by authzId that need to be evaluated are
-as follows:
-
-
- 1. permission "w" to each attribute being added to object
-
- If this permission is not granted to such an attribute, then the
- operation MUST fail.
-
- 2. permission "o" to each attribute for which a value is being
- deleted from object
-
- If this permission is not granted to such an attribute, then the
- operation MUST fail.
-
- 3. permissions "o" and "w" to each attribute being replaced in object
-
- If each of these items is satisfied then the operation is allowed
- by the access control model. If one of these items is not
- satisfied, then the operation MUST fail. In this case, if "u"
- (discloseOnError) is granted to object, then the usual error codes
- (such as noSuchObject, attributeOrValueExists, noSuchAttribute and
- insufficientAccess) and matchedDN value may be returned; if "u" is
- not granted to object then nosuchObject MUST be returned and
- matchedDN set to "".
-
-
-5.4 Add Operation
-
-Recall that the parameters of the Add operation per RFC2251 [LDAPv3]
-Section 4.7 are:
-
- AddRequest ::= [APPLICATION 8] SEQUENCE {
- entry LDAPDN,
- attributes AttributeList }
-
- AttributeList ::= SEQUENCE OF SEQUENCE {
- type AttributeDescription,
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 32]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- vals SET OF AttributeValue }
-
-Then the permissions required by authzId that need to be evaluated are
-as follows:
-
-
- 1. permission "a" to the parent of entry
-
- The access rights required for the creation of a root entry in the
- Directory are beyond the scope of this document. They will be
- vendor specific.
-
- 2. permission "m" to the parent of entry for each attribute being
- added to entry
-
-If each of these items is satisfied then the operation is allowed by the
-access control model. If one of these items is not satisfied, then the
-operation MUST fail. In this case, if "u" (discloseOnError) is granted
-to the parent of entry, then the usual error codes (such as
-noSuchObject, entryAlreadyExists, and insufficientAccess) and matchedDN
-value may be returned; if "u" is not granted to the parent of entry,
-then nosuchObject MUST be returned and matchedDN set to "".
-
-Note A: We require "m" permission to each attribute to prevent an entry
-from acquiring "unintended" rights (via group or role membership), to
-stop a "rogue" ACI being added that would prevent even admins deleting
-the entry, and for general consistency with the MODIFY operation.
-
-
-5.5 Delete Operation
-
-Recall that the parameters of the Delete operation per RFC2251 [LDAPv3]
-Section 4.10 are:
-
- DelRequest ::= [APPLICATION 10] LDAPDN
-
-Then the permissions required by authzId that need to be evaluated are
-as follows:
-
-
- 1. permission "d" to the entry in the Delete request
-
-If each of these items is satisfied then the operation is allowed by the
-access control model. If one of these items is not satisfied, then the
-operation MUST fail. In this case, if "u" (discloseOnError) is granted
-to the entry to be deleted, then the usual error codes (such as
-noSuchObject, and insufficientAccess) and matchedDN value may be
-returned; if "u" is not granted to object then nosuchObject MUST be
-returned and matchedDN set to "".
-
-Note: One could also require the "o" permission to be granted to allow
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 33]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-the operation to proceed, but customer experience has shown that the
-requirement of the additional permission is not useful nor expected, and
-X.500 requires only the "d" permission.
-
-
-5.6 Modify DN Operation
-
-Recall that the parameters of the Modify DN operation per RFC2251
-[LDAPv3] Section 4.6 are:
-
- ModifyDNRequest ::= [APPLICATION 12] SEQUENCE {
- entry LDAPDN,
- newrdn RelativeLDAPDN,
- deleteoldrdn BOOLEAN,
- newSuperior [0] LDAPDN OPTIONAL }
-
-The variants of the ModifyDN operation are listed below. Combinations
-of the write, obliterate, import, export and renameDN permissions are
-needed for each variant.
-
- 1. Rename an entry by moving the conceptual RDN flag between two
- existing attribute values, without altering any attribute values
- at all. Permissions needed are renameDN.
-
- 2. Rename an entry by adding a new attribute value. Permissions
- needed are renameDN and write.
-
- 3. Rename an entry using an existing attribute value and delete the
- current attribute value. Permissions needed are renameDN and
- obliterate.
-
- 4. Rename an entry adding a new attribute value and deleting the
- current attribute value. Permissions needed are renameDN, write,
- and obliterate.
-
- 5. Move an entry to a new place in the DIT, keeping its existing RDN
- as is. Permissions needed are import and export.
-
- 6. Move an entry to a new place coupled with 1. above Permissions
- needed are import, export, and renameDN.
-
- 7. Move coupled with 2. above. Permissions needed are import,
- export, renameDN, and write.
-
- 8. Move coupled with 3. above. Permissions needed are import,
- export, renameDN, and obliterate.
-
- 9. Move coupled with 4. above. Permissions needed are import,
- export, renameDN, write, and obliterate.
-
-For a given case, if the required permissions are granted, then the
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 34]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-operation is allowed by the access control model. If, for a given case,
-the required permissions are not granted, then the operation MUST fail.
-If the access control failure is due to a missing attribute or entry
-permission on entry, then if "u" (discloseOnError) is granted to entry,
-then the usual error codes (such as noSuchObject, attributeOrValueExists
-and insufficientAccess) and matchedDN value may be returned; if "u" is
-not granted to entry then nosuchObject MUST be returned and matchedDN
-set to "". Similar logic applies if the access control failure was due
-to a missing permission on newSuperior.
-
-
-5.7 Compare Operation
-
-Recall that the parameters of the Compare operation per RFC2251 [LDAPv3]
-Section 4.10 are:
-
- CompareRequest ::= [APPLICATION 14] SEQUENCE {
- entry LDAPDN,
- ava AttributeValueAssertion }
-
-Then the permissions required by authzId that need to be evaluated are
-as follows:
-
-
- 1. permission "c" to the attribute in entry on which the comparison
- is being made.
-
-If each of these items is satisfied then the operation is allowed by the
-access control model. If one of these items is not satisfied, then the
-operation MUST fail. In this case, if "u" (discloseOnError) is granted
-to entry, then the usual error codes (such as noSuchObject, and
-insufficientAccess) and matchedDN value may be returned; if "u" is not
-granted to entry then nosuchObject MUST be returned and matchedDN set to
-"".
-
-
-5.8 Abandon Operation
-
-Recall that the parameters of the Abandon operation per RFC2251 [LDAPv3]
-Section 4.6 are:
-
- AbandonRequest ::= [APPLICATION 16] MessageID
-
-authzId always has the right to send an Abandon Operation for an
-operation he previously initiated.
-
-
-5.9 Extended Operation
-
-Recall that the parameters of the Extended operation per RFC2251
-[LDA{v3] Section 4.12 are:
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 35]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
- requestName [0] LDAPOID,
- requestValue [1] OCTET STRING OPTIONAL }
-
-The access required for an Extended Operation is beyond the scope of
-this document. The required access will normally be defined by the
-implementer of the extended request.
-
-
-
-6. Required Permissions for Handling Aliases and References
-
-Use of aliases and referrals are part of LDAPv3. However, neither is
-particularly well-defined. Alias objects and attributes are defined in
-RFC 2256 as derived from X.500, but LDAPv3 does not explicitly define
-their semantics or behavior. X.500 does define alias semantics and
-behavior with respect to access control; we define its behavior in
-LDAPv3 based on the X.511 (1993) [X511], section 7.11.1. Referrals and
-knowledge information are still under design in LDAPv3; they are defined
-in X.500, however, X.500 does not specify their semantics and behavior
-with respect to access control. We define their semantics and behavior
-in LDAPv3 in terms that should be independent of the future LDAPv3
-definition of referrals and knowledge information.
-
-
-6.1 ACI Distribution
-
-Currently there is no LDAP standard defining how to distribute directory
-data between LDAP servers. Consequently this model cannot fully specify
-the behavior of the Access Control Model in a distributed environment.
-The case of distribution via referrals is treated in the "Referrals"
-section below. In the case of chaining (where one LDAP server forwards a
-request to another on behalf of a client) then it is server specific how
-the access control model behaves in this environment. Similarly it is
-server specific how the server determines whether the chaining of an
-operation is permitted in the first place. For example, the
-implementation may choose to regard the local naming context and the
-remote subordinate naming context as separate Access Control Specific
-Areas, or it may regard the DIT as one Access Control Specific Area and
-implement mechanisms to propagate access control information between the
-two servers. The behavior of the Access Control Model in distributed
-environments such as these is beyond the scope of this model.
-
-
-6.2 Aliases
-
-There are two things to protect with respect to aliases: the real name
-of the aliased object and the location of the server holding it.
-
-If alias de-referencing is required in the process of locating a target
-entry, no specific permissions are necessary for alias de-referencing to
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 36]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-take place. Access control is enforced at the object pointed to by the
-alias.
-
-If alias de-referencing would result in a continuationReference (e.g.
-from a search operation), then browse permission is required to the
-alias entry and read permission is required to the attribute. Requiring
-these permission closes the hole of discovery.
-
-
-6.3 Referrals
-
-If a referral is to be followed, no specific permissions are necessary
-for the ldap client to follow the referral. Access control is enforced
-at the referenced object. If a referral is returned, then browse is
-required on the entry and read permission is required to the attribute
-containing the referral (we cannot name this attribute exactly today
-because there are no RFCs on this). If the server implements a default
-referral, then no special permissions are required to read and return
-that referral. Requiring these permissions closes the hole of
-discovery. In the default case, it is assumed that a default referral
-is public.
-
-
-
-7. Controlling Access to Access Control Information
-
-The entryACI and subtreeACI attributes are used to specify control for
-who has permission to set/change access control information (entryACI
-and subtreeACI). The entryACI and subtreeACI attributes/OIDs are just
-another attribute described with set of rights and permissions, and
-subject as a value of the entryACI and subtreeACI attributes. (See the
-example in the "ACI Examples" section).
-
-If the policy for controlling the entryACI and subtreeACI attributes are
-not specified for any object in the tree, behavior is implementation
-defined. For instance, if no object anywhere in the tree defines the
-access for entryACI/subtreeACI within the entryACI/subtreeACI
-attributes, then the server could simply assert that the 'root DN' is
-considered the policy owner (controller for controlling access control)
-for all objects.
-
-
-
-8. ACI Examples
-
-Note that in the examples, the form "OID.<attrname>" refers to the OID
-in dotted decimal form for the attribute <attrname>. This shorthand
-notation is used only for the examples. In implementation, the dotted
-decimal form of the OID is used.
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 37]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-8.1 Attribute Definition
-
-The following examples show the access required to control access to the
-entryACI and subtreeACI attributes. The first example shows controlling
-the access control on an individual entry and its attributes. The
-second example shows controlling the access control on a subtree. The
-authnLevel is set so that a reasonably secure form of authentication is
-required, since changing ACI has significant security consequences.
-
- entryACI: grant:rwo#
- OID.entryACI#authnLevel:limited:role:cn=aciAdmin
-
- subtreeACI: grant:rwo#
- OID.subtreeACI#authnLevel:limited:role:cn=aciAdmin
-
-The next example shows a subtreeACI attribute where a group "cn=Dept
-XYZ, c=US" is being given permissions to read, search, and compare
-attribute attr1. The permission applies to the entire subtree below the
-node containing this ACI.
-
- subtreeACI: grant;rsc#
- OID.attr1#authnLevel:weak:group:cn=Dept XYZ,c=US
-
-The next example shows an ACI attribute where a role
-"cn=SysAdmins,o=Company" is being given permissions to browseDN,
-viewEntry, and returnDN for objects below this node. The role is also
-being given permission to read, search, and compare to attribute attr2
-and read, search, compare, write, obliterate to attr3. The permissions
-apply to the entire subtree below the node containing this ACI.
-
- subtreeACI: grant:bvt#
- [entry]#authnLevel:weak:role:cn=SysAdmins,o=Company
-
- subtreeACI: grant:rsc#
- OID.attr2#authnLevel:weak:role:cn=SysAdmins,o=Company
-
- subtreeACI: grant:rscwo#
- OID.attr3#authnLevel:weak:role:cn=SysAdmins,o=Company
-
-
-8.2 Modifying the entryACI and subtreeACI Values
-
-Modify-Replace works as defined in the ldap operation modify. If the
-attribute value does not exist, create the value. If the attribute does
-exist, replace the value. If the entryACI/subtreeACI value is replaced,
-all entryACI/subtreeACI values are replaced. To modify the
-entryACI/subtreeACI attributes requires you to have 'w' and 'o'
-permission on the entryACI/subtreeACI attribute (recall that a value of
-entryACI/subtreeACI specifies entryACI/subtreeACI so one can control
-access to the entryACI/subtreeACI attribute). The examples in this
-section assume that you have access to control entryACI/subtreeACI.
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 38]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-A given subtreeACI for an entry:
-
- subtreeACI: deny:rw#[all]#authnLevel:weak:group:cn=Dept ABC
-
- subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
-
-perform the following change:
-
- dn: cn=someEntry
- changetype: modify
- replace: subtreeACI
- subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN
-
-The resulting ACI is:
-
- subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept LMN
-
-( subtreeACI values for Dept XYZ and ABC are lost through the replace )
-
-During an ldapmodify-add, if the ACI does not exist, the create the ACI
-with the specific entryACI/subtreeACI value(s). If the ACI does exist,
-then add the specified values to the given entryACI/subtreeACI. For
-example a given ACI:
-
- subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
-
-with a modification:
-
- dn: cn=someEntry
- changetype: modify
- add: subtreeACI
- subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
-
-would yield an multi-valued ACI of:
-
- subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
-
- subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
-
-To delete a particular ACI value, use the regular ldapmodify - delete
-syntax
-
-Given an ACI of:
-
- subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
- subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
-
- dn: cn = some Entry
- changetype: modify
- delete: subtreeACI
- subtreeACI: grant:r#OID.attr1#authnLevel:weak:group:cn=Dept XYZ
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 39]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-would yield a remaining ACI on the server of
-
-subtreeACI: grant:rw#[all]#authnLevel:weak:group:cn=Dept XYZ
-
-The attributes which are defined for access control interchange may be
-used in all LDAP operations.
-
-Within the ldapmodify-delete operation, the entire acl may be deleted by
-specifying
-
- dn: cn = some Entry
- changetype: modify
- delete: entryACI
-
- dn: cn = some Entry
- changetype: modify
- delete: subtreeACI
-
-In this case, the entry would then inherit its ACI from other nodes in
-the tree depending on the inheritance model.
-
-Similarly, if all values of entryACI and subtreeACI are deleted, then
-the access control information for that entry is defined by the
-inheritance model.
-
-
-8.3 Evaluation
-
-These examples assume that the ACI entries listed in each example are
-the only ACI which applies to the entry in question; if backing-store
-ACI also exists, the effective policy may be different from that listed
-in each example.
-
-Assume cn=jsmith is a member of group cn=G1. Assume cn=jsmith is a
-member of group cn=G2.
-
-
-Example #1
-
- dn: o=XYZ, c=US
- subtreeACI: grant:r#attr2
- #authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
- subtreeACI: grant:w#attr2
- #authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US
-
-What rights does cn=jsmith have to attr2 of o=XYZ,c=US? Read-write (rw)
-access; ACI is combined because both subjects (group) have same
-precedence.
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 40]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-Example #2
-
- dn: o=XYZ, c=US
- subtreeACI: grant:rw#OID.attr3
- #authnLevel:weak:group:cn=G1,ou=ABC,o=XYZ,c=US
- subtreeACI:
-deny:w#OID.attr3#authnLevel:weak:group:cn=G2,ou=ABC,o=XYZ,c=US
-
-What rights does cn=jsmith have to attr3 of o=XYZ, c=US? Read access;
-write is denied (deny has precedence over grant).
-
-
-Example #3
-
- dn: o=XYZ, c=US
- subtreeACI: grant:m#OID.attr5
- #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
- subtreeACI: grant:m#OID.cn
- #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
- subtreeACI: grant:m#OID.sn
- #authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
- subtreeACI: grant:a#[entry]
- #authnLevel:weak:authzID-dn:#cn=jsmith,o=ABC,c=US
-
-What rights does cn=jsmith have to o=XYZ, c=US? Make(m) on attributes
-attr5, cn, and sn and Add(a) on the entry. These are the minimal yet
-sufficient permissions to create a new object, cn=New, o=XYZ, c=US with
-values for the attr5, cn, and sn attributes. This example illustrates
-how the "m" permission can be used to limit the attributes that can be
-created on a new entry.
-
-
-Example #4
-
- dn: c=US
- subtreeACI: grant:m#[all]#authnLevel:weak:subtree:c=US
- dn: o=XYZ, c=US
- subtreeACI: grant:a#[entry]#
- authnLevel:weak:authzID-dn:cn=jsmith,o=ABC,c=US
-
-What rights does cn=jsmith have to o=XYZ, c=US? Make(m) on attributes
-all attributes and Add(a) on the entry. These are sufficient permissions
-to create a new object, cn=New, o=XYZ, c=US with values for any desired
-attributes. For administrators who do not wish to limit the attributes
-that can be created on new entries, this example shows how a single
-ldapACI at the top of the domain solves the problem.
-
-
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 41]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-Example #5
-
- dn: dc=com,dc=demo
- subtreeACI: grant:rw#description;lang-en#authnLevel:weak:authzID-dn:
- cn=rvh,dc=att,dc=com
- subtreeACI: grant:rw#description;lang-en,description;lang-fr#
- authnLevel:weak:authzID-dn:cn=rob,dc=sun,dc=com
-
-In this example, cn=rvh,dc=att,dc=com has "rw" access to the English-
-language "description" attributes of entries under dc=com,dc=demo.
-cn=rob,dc=sun,dc=com has "rw" rights to both English- and French-
-language "description" attributes. The example demonstrates that
-"Attribute Descriptions", not just "Attribute Types", can be used in the
-"attr" field of an ACI. See [LangCode] for more information on the
-attribute options used here.
-
-
-8.4 ModDN
-
-There are many different actions that can happen when the modDN command
-are used. The following illustrates the permissions needed in order to
-execute each scenario. For all examples, we will assume the role
-cn=Admins is working with the following entry:
-
- dn: cn=personA, o=Company
- cn: personA
- cn: FirstName
- sn: LastName
- objectclass: person
-
-
-Example #1
-
-Perform a modRDN only, using an existing attribute value. In this case,
-we perform a modRDN and rename cn=personA, o=Company to cn=FirstName,
-o=Company. The entryACI value for this entry must give the cn=Admin role
-rename permission on the entry.
-
- entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
-
-
-Example #2
-
-We wanted to perform a ModRDN and add a new attribute value. In this
-case we are renaming cn=personA, o=Company to cn=newFirstName,
-o=Company. The entryACI value must give the cn=Admin role rename
-permission on the entry and w permission on the cn attribute.
-
- entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
- entryACI: grant:w#cn#authnLevel:weak:role:cn=Admin
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 42]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-Example #3
-
-Perform a modRDN, using an existing attribute, but delete the old RDN
-value. Here, we perform a modRDN and rename cn=personA, o=Company to
-cn=FirstName, o=Company and set the deleteOldRdn flag to true. The
-cn=Admin role must have permission to rename the entry, and to delete a
-cn attribute value ( i.e. 'o' ).
-
- entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
- entryACI: grant:o#OID.cn#authnLevel:weak:role:cn=Admin
-
-
-Example #4
-
-Perform a modRDN, using an new cn attribute value (cn=newFirstName), and
-delete the old RDN value (cn=personA). Here, we perform a modRDN and
-rename cn=personA, o=Company to cn=newFirstName, o=Company and set the
-deleteOldRdn flag to true. The cn=Admin role must have permission to
-rename the entry, and to delete and write the cn attribute value.
-
- entryACI: grant:n#[entry]#authnLevel:weak:role:cn=Admin
- entryACI: grant:w,o#OID.cn#authnLevel:weak:role:cn=Admin
-
-
-Example #5
-
-We want to change the entry's location in the DIT ( modDN ) and keep the
-same RDN Value. In this case we are moving cn=personA, o=Company to
-cn=personA, o=CompanyB. The cn=Admin role must have export permission on
-the original entry, and import permission on the new superior object (
-the new parent ). The cn=personA, o=Company entryACI is:
-
- entryACI: grant:e#[entry]#authnLevel:weak:role:cn=Admin
-
-and the o=CompanyB entryACI is:
-
- entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
-
-
-Example #6
-
-We want to change the entry's location in the DIT ( modDN ) and change
-the RDN Value to an existing attribute value. In this case we are moving
-cn=personA, o=Company to cn=FirstName, o=CompanyB. The cn=Admin role
-must have rename and export permission on the original entry, and import
-permission on the new superior object ( the new parent ). The
-cn=personA, o=Company entryACI is:
-
- entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
-
-and the o=CompanyB entryACI is:
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 43]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
-
-
-Example #7
-
-We want to change the entry's location in the DIT ( modDN ) and change
-the RDN Value to a new attribute value. In this case we are moving
-cn=personA, o=Company to cn=newFirstName, o=CompanyB. The cn=Admin role
-must have rename and export permission on the original entry, write
-permission on the naming attribute ( cn) and import permission on the
-new superior object ( the new parent ). The cn=personA, o=Company
-entryACI is:
-
- entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
- entryACI: grant:w#OID.cn#authnLevel:weak:role:cn=Admin
-
-and the o=CompanyB entryACI is:
-
- entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
-
-
-Example #8
-
-We want to change the entry's location in the DIT ( modDN ) and change
-the RDN Value to an existing attribute value, and delete the old RDN
-value. In this case we are moving cn=personA, o=Company to
-cn=FirstName, o=CompanyB and deleting the attribute value personA. The
-cn=Admin role must have rename and export permission on the original
-entry, delete ('o') permission on the naming attribute (cn) and import
-permission on the new superior object (the new parent). The cn=personA,
-o=Company entryACI is:
-
- entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
- entryACI: grant:o#cn#authnLevel:weak:role:cn=Admin
-
-and the o=CompanyB entryACI is:
-
- entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
-
-
-Example #9
-
-We want to change the entry's location in the DIT ( modDN ) and change
-the RDN Value to a new attribute value, and delete the old RDN value.
-In this case we are moving cn=personA, o=Company to cn=newFirstName,
-o=CompanyB and deleting the attribute value personA. The cn=Admin role
-must have rename and export permission on the original entry, write
-('w'), and delete ('o') permission on the naming attribute (cn) and
-import permission on the new superior object ( the new parent ). The
-cn=personA, o=Company entryACI is:
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 44]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- entryACI: grant:en#[entry]#authnLevel:weak:role:cn=Admin
- entryACI: grant:wo#OID.cn#authnLevel:weak:role:cn=Admin
-
-and the o=CompanyB entryACI is:
-
- entryACI: grant:i#[entry]#authnLevel:weak:role:cn=Admin
-
-
-8.5 Interaction Among ACI
-
-These examples show how ACI in different parts of the tree interact.
-Examples with varying authnLevel are given in the next section.
-
-The examples refer to this fragment of a directory tree:
-
- dc=com
- |
- +--------+---------------+
- | |
- dc=tivoli dc=sun
- | |
- cn=ellen cn=rob
-
-Example #1
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rw#[all]#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
- at dc=tivoli,dc=com: subtreeACI:grant:r#[all]#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
-
-Then the effective rights of cn=rob,dc=sun,dc=com to all the attributes
-of object cn=ellen,dc=tivoli,dc=com are "rw". The ACI at
-dc=tivoli,dc=com is redundant.
-
-Example #2
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:r#[all]# authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
- at dc=tivoli,dc=com: subtreeACI:grant:w#OID.uid#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
-
-Then cn=rob,dc=sun,dc=com has effective rights of "r" to all the
-attributes of object cn=ellen,dc=tivoli,dc=com, and effective rights of
-"rw" to the uid attribute of object cn=ellen,dc=tivoli,dc=com. Also,
-cn=rob,dc=sun,dc=com has effective rights of "r" to all attributes of
-object cn=rob,cn=sun,cn=com.
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 45]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-Example #3
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rw#[all]#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
- at dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
-
-Then cn=rob,dc=sun,dc=com has effective rights of "r" (but not "w") to
-all the attributes of object cn=ellen,dc=tivoli,dc=com and has effective
-rights of "rw" to all attributes of objects cn=rob,dc=sun,dc=com.
-
-Example #4
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:r#OID.uid#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
- at dc=tivoli,dc=com: subtreeACI:grant:w#OID.sn#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
-
-Then cn=rob,dc=sun,dc=com has effective rights of "r" to the uid
-attribute and "w" to the sn attribute of object
-cn=ellen,dc=tivoli,dc=com.
-
-Example #5
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:r#OID.uid#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
- at cn=rob,dc=sun,dc=com: entryACI:grant:rw#[all]#authnLevel:weak:
- this:
-
-Then cn=rob,dc=sun,dc=com has effective rights of "rw" to all attributes
-of object cn=rob,dc=sun,dc=com.
-
-Example #6
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rw#uid#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
- at dc=tivoli,dc=com: subtreeACI:deny:w#uid#authnLevel:weak:
- subtree:dc=sun,dc=com
-
-Then cn=rob,dc=sun,dc=com has rights of "r" to the uid attribute of
-object cn=ellen,dc=tivoli,dc=com. While checking the "w" permission,
-the subtreeACI at dc=tivoli,dc=com is lower in the tree than the
-subtreeACI at dc=com, so it takes precedence at Step 1.
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 46]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-Example #7
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:
- authzID-dn:cn=rob,dc=sun,dc=com
- at dc=com: subtreeACI:deny:w#OID.uid#authnLevel:weak:
- subtree:dc=sun,dc=com
-
-Then cn=rob,dc=sun,dc=com has rights of "rw" to the uid attribute of
-object cn=ellen,dc=tivoli,dc=com. While checking the "w" permission,
-the two subtreeACI are at the same level in the tree (step 1) and the
-Subject Type dn-dn has precedence over Subject Type subtree (step 2), so
-the first ACI has precedence over the second.
-
-Example #8
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:
- subtree:dc=sun,dc=com
- at dc=com: subtreeACI:deny:w#OID.uid#authnLevel:weak:subtree:dc=com
-
-Then cn=rob,dc=sun,dc=com has rights of "r" to the uid attribute of
-object cn=ellen,dc=tivoli,dc=com. While checking the "w" permission,
-the two subtreeACI are at the same level in the tree (step 1) and they
-have the same Subject Type (step 2), so the precedence of deny over
-grant (step 5) is the deciding factor.
-
-Example #9
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rw#OID.uid#authnLevel:weak:
- subtree:dc=sun,dc=com
- at dc=com: subtreeACI:deny:w#[all]#authnLevel:weak:subtree:dc=com
-
-Then cn=rob,dc=sun,dc=com has rights of "rw" to the uid attribute of
-object cn=ellen,dc=tivoli,dc=com. While checking the "w" permission,
-the two subtreeACI are at the same level in the tree (step 1) and they
-have the same Subject Type (step 2), so the precedence of a specific
-attribute list over "[all]" (step 4) is the deciding factor.
-
-8.6 Use of ipAddress in ACI
-
-Using the tree fragment from Section 8.5:
-
-
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 47]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-Example #1
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI: deny:adeinbvtug#[entry]#
- authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255
- subtreeACI: deny:rwospcm#[all]#
- authnLevel:strong:ipAddress:10.0.0.0-10.255.255.255
- subtreeACI: grant:rscp#[all]#authnLevel:none:public:
- subtreeACI: grant:btv#[entry]#authnLevel:none:public:
-
-Then any user regardless of the strength of their authentication is
-denied all permissions if they happen to be connecting from an IP
-address in the 10-net. If they connect from any other address, they
-have "rscp" permissions for all attributes and "btv" permissions for all
-entries in the dc=com subtree.
-
-Example #2
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI: grant:adeinbvtug#[entry]#
- authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255
- subtreeACI: grant:rspwocm#[all]#
- authnLevel:weak:ipAddress:10.0.0.0-10.255.255.255
-
-It will have no effect. While it might seem that it would grant total
-access to any user bound from an address in 10-net, the special rules
-governing ipAddress and dns as subjects make them useful only for deny
-ACI, not for grants. This was done because the effects of a mistaken
-grant to an IP address range or wildcarded DNS name could be extremely
-serious.
-
-An (insane) administrator who really wants to grant total access to
-anyone on 10-net would have to specify:
-
- at dc=com: subtreeACI: grant:adeinbvtug#[entry]#authnLevel:weak:public:
- subtreeACI: deny:adeinbvtug#[entry]#
- authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255,
- 11.0.0.0-255.255.255.255
- subtreeACI: grant:rspwocm#[all]#authnLevel:weak:public:
- subtreeACI: deny:rspwocm#[all]#
- authnLevel:strong:ipAddress:0.0.0.0-9.255.255.255,
- 11.0.0.0-255.255.255.255
-
-This ACI depends on the fact that a "deny" works on the stated
-authnLevel and all lower authnLevels while a "grant" works on the stated
-level and all higher authnLevels.
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 48]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-8.7 Use of authnLevel in ACI
-
-Using the tree fragment from Section 8.5:
-
-Example #1
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rw#OID.sn#authnLevel:strong:
- authzID-dn:cn=rob,dc=sun,dc=com
- at dc=tivoli,dc=com: subtreeACI:grant:r#OID.sn#authnLevel:limited:
- authzID-dn:cn=rob,dc=sun,dc=com
-
-Then cn=rob,dc=sun,dc=com has effective rights of "rw" to the sn
-attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this
-session used strong authentication. If the BIND for this session used
-limited authentication, cn=rob,dc=sun,dc=com has effective rights of "r"
-to the sn attribute of object cn=ellen,dc=tivoli,dc=com. If the BIND
-for this session used weak or no authentication, cn=rob,dc=sun,dc=com
-has no rights to object cn=ellen,dc=tivoli,dc=com.
-
-Example #2
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI: grant:rw#sn#authnLevel:limited:
- subtree:dc=sun,dc=com
- at dc=tivoli,dc=com: subtreeACI: grant:c;deny:w#sn#authnLevel:strong:
- authzID-dn:cn=rob,dc=sun,dc=com
-
-Then cn=rob,dc=sun,dc=com has effective rights of "rc" to the sn
-attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this
-session used strong authentication. The "r" permission comes from the
-fact that the grant part of the first ACI applies to BINDs at or above
-the "limited" level. If the BIND for this session used limited
-authentication, cn=rob,dc=sun,dc=com has "r" rights to the sn attribute
-of object cn=ellen,dc=tivoli,dc=com. The deny part of the second ACI
-applies to cases where the authnLevel is less than "strong", so it
-overrides the grant of "w" permission in the first ACI. If the BIND for
-this session is at the weak or none authnLevel, the user has no
-permissions.
-
-Example #3
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rs#sn#authnLevel:none:public
- at dc=com: subtreeACI:grant:w#sn#authnLevel:strong:
- subtree:cn=rob,dc=sun,dc=com
-
-Then cn=rob,dc=sun,dc=com has effective rights of "rsw" to the sn
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 49]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-attribute of object cn=ellen,dc=tivoli,dc=com if the BIND for this
-session used strong authentication and effective rights "rs" if the BIND
-for this session used any other form of authentication. The grant in
-the first ACI applies to BINDs at the "none" level and above, so it
-applies to any authnLevel.
-
-Example #4
-
-If the ACI is as follows:
-
- at root: subtreeACI:grant:ps#[all]#authnLevel:none:public:
- subtreeACI:grant:cr#[all]#authnLevel:weak:subtree:
-
-Then any user including the anonymous user (no name supplied to BIND)
-has "ps" permissions to any entry on the server, and any user with an ID
-on the server ("subtree:" specifies any DN in the subtree under root)
-who has bound using "weak" or better authentication has "pscr"
-permissions.
-
-Example #5
-
-If the ACI is as follows:
-
- at dc=com: subtreeACI:grant:rw#[all]#authnLevel:limited:
- cn=ellen,dc=tivoli,dc=com
- at dc=tivoli,dc=com: subtreeACI:deny:w#[all]#authnLevel:strong:
- cn=rob,dc=sun,dc=com
-
-Then if bound at the strong authnLevel, user cn=ellen,dc=tivoli,dc=com
-has permissions "rw" to all the attributes of the object
-cn=ellen,dc=tivoli,dc=com, and permissions "rw" to all the attributes of
-the object cn=rob,dc=sun,dc=com. But if bound at the limited
-authnLevel, user cn=ellen,dc=tivoli,dc=com has permissions "r" to all
-the attributes of the object cn=ellen,dc=tivoli,dc=com, and permissions
-"rw" to all the attributes of the object cn=rob,dc=sun,dc=com.
-
-This is a consequence of the way that "deny" is processed with respect
-to authnLevel. Since cn=rob,dc=sun,dc=com is denied "w" permission when
-authenticating at the "strong" authnLevel, ALL users are denied "w"
-permission when bound at any weaker level (see the rules for authnLevel
-in "Subjects and Associated Authentication").
-
-
-9. GetEffectiveRights Control
-
-The access control information controls provide a way to manipulate
-access control information in conjunction with a LDAP operation. One
-LDAP control is defined. This control allows access control information
-to be retrieved. The control is:
-
- GetEffectiveRights - obtain the effective rights for a given
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 50]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- directory entry(s) for a given subject during a ldap_search
- operation
-
-The purpose of the getEffectiveRights control is to allow an
-administrator or application to query the server about the rights of
-another user of the directory. This is important as it would allow the
-administrator to verify the access control policy for a given subject.
-Or it would allow an application for example, to propose to a user the
-attributes which he has the right to modify or see in a given entry.
-
-9.1 Request Control
-
-This control may only be included in the ldap_search message as part of
-the controls field of the LDAPMessage, as defined in Section
-4.1.12 of [LDAPv3].
-
-The controlType is set to <OID to be assigned>. The criticality MAY be
-either TRUE or FALSE (where absent is also equivalent to FALSE) at the
-client's option. The controlValue is an OCTET STRING, whose value is
-the BER encoding of a value of the following SEQUENCE:
-
- GetEffectiveRightsRequest ::= SEQUENCE{
- gerSubject [0] GERSubject
- }
-
-
- GERSubject ::= SEQUENCE {
- gerOneSubject [0] OneSubject -- from 4.1.2 , OPTIONAL
- germachineSubject [1] GERMachineSubject,
- gerAuthnLEvel [2] AuthnLevel, -- from 4.1.2
- }
-
-
- GERMachineSubject ::= SEQUENCE{
- gerOneIPAddress [0] IPAddress, -- from 4.1.2
- gerOneDNSName [1] DomainName -- from 4.1.2
- }
-
-
-
-The getEffectiveRightsRequest specifies a subject, gerSubject, about
-whom access control information is being requested. The control asks
-the server to evaluate and return the entry level rights possessed by
-the gerSubject for each entry that is returned in the search results,
-and for each returned or specifically requested attribute. The server
-will use the Access Decision Algorithm from section 4.3 to determine the
-requested effective rights; it will be seen that the parameters defining
-the subject in the Access Decision algorithm ((dn OPTIONAL, ipAddress,
-dnsName, authnLevel)) are all present in this control.
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 51]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-9.2 Response Control
-
-This control is included in the ldap_search_response message as part of
-the controls field of the LDAPMessage, as defined in Section 4.1.12 of
-[LDAPv3].
-
-The controlType is set to <OID to be assigned>. There is no need to set
-the criticality on the response. The controlValue is an OCTET STRING,
-whose value is the BER encoding of a value of the following SEQUENCE:
-
- GetEffectiveRightsResponse ::= {
- result ENUMERATED {
- success (0),
- operationsError (1),
- unavailableCriticalExtension (12),
- noSuchAttribute (16),
- undefinedAttributeType (17),
- invalidAttributeSyntax (21),
- insufficientRights (50),
- unavailable (52),
- unwillingToPerform (53),
- other (80)
- }
- }
-
-The effective rights returned are returned with each entry returned by
-the search result. The control response for ldap_search is:
-
- PartialEffectiveRightsList ::= SEQUENCE {
- entryLevelRights [0] EffectiveRights,
- attributeLevelRights [1] AttributeLevelRights
- }
-
-
- EffectiveRights ::= CHOICE {
- rights [0] Permissions -- from 4.1.2,
- noRights [1] NULL,
- errorEvaluatingRights [2] GerError
- }
-
-
- GerError ::= ENUMERATED
- {generalError(0),insufficientAccess(1)}
-
-
- AttributeLevelRights ::= SEQUENCE OF {
- attr [0] SEQUENCE OF Attribute,
- rights [1] EffectiveRights
- }
-
-For a given entry, the control response entryLevelRights field contains
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 52]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-the entry level effective rights that gerSubject has on that entry. The
-attributeLevelRights field contains a list of attributes and the
-effective rights that gerSubject has for each of those attributes. The
-list of attributes consists of those attributes returned as part of the
-search operation plus any explicitly requested attributes that were not
-returned. An attribute explicitly requested in the search request might
-not be returned because the attribute is not in the entry, but we may
-still be interested in the effective rights on it, for example to
-determine if gerSubject could add that attribute to the entry.
-
-The control returns the permissions that gerSubject has on a given entry
-and its attributes. In order to determine whether these permissions
-suffice to allow gerSubject to perform a given LDAP operation on the
-entry, the requestor will determine if these permissions satisfy the
-required permissions for that LDAP operation, as defined in section 5.
-
-Note that in the case where gerSubject does not have a particular
-permission then this control does not allow the requestor to determine
-whether that is because the permission was not granted to gerSubject or
-whether it was because this permission has been explicitly denied.
-
-The required permissions to see the effective rights of a subject on an
-entry and its attributes are specified in 9.3.
-
-If gerSubject has the same rights to a set of attributes in that entry
-then the server may group the attributes together in a list.
-
-Although this extends the search operation, there are no
-incompatibilities between versions. LDAPv2 cannot send a control, hence
-the above structure cannot be returned to a LDAPv2 client. A LDAPv3
-client cannot send this request to a LDAPv2 server. A LDAPv3 server not
-supporting this control cannot return the additional data.
-
-9.3 Access control for the Get Effective Rights Control
-
-In the presence of the get effective rights control, the access controls
-applied to the search operation use the requestor's authorization
-identity.
-
-For a given entry returned in the search results then in order to see
-the effective rights of any subject for this entry and its attributes
-the requestor requires:
-
-
- 1. "g" permission on the entry.
-
-If 1. is not satisfied then the "insufficientAccess" error is returned
-for the entryLevelRights of that entry and for each of the rights in the
-AttributeLevelRights list.
-
-Note A: the set of entries and attributes that are returned are those
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 53]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-visible to the requestor, not the gerSubject. This means that it is
-possible that if gerSubject could see an entry that the requestor could
-not then it is impossible for the requestor, using the
-getEffectiveRights control, to retrieve the effective rights of
-gerSubject on that entry. However, the idea here is that the requestor
-will typically be a powerful administrator whose access rights will be a
-superset of those of other users.
-
-Note B: once a given subject has the "g" permission on a given entry
-then he has the right to see the effective rights of _any_ subject on
-that entry. It might be useful to have a way to restrict the set of
-subjects whose effective rights can be retrieved but that complicates
-the model in that, for the "g" permission only, we no longer have a
-target/subject type structure but rather a target/subject/otherSubject
-structure. Here, we choose the simpler model rather than this extra
-functionality.
-
-9.4 Get Effective Rights example
-
-Suppose we have a DIT with the entries and access controls as described
-in the following LDIF example:
-
- o=sun.com
- objectclass: top
- objectclass: organization
- o: sun.com
- subtreeACI: grant:rsc#[all]#authnLevel:none:public:
- subtreeACI: deny:rsc#[userPassword,subtreeACI,
- entryACI,salary]#authnLevel:none:public:
- subtreeACI: grant:bvt#[entry]#authnLevel:none:public:
- subtreeACI: grant:g#[entry]#authnLevel:limited:this:
- subtreeACI: grant:worsc#[all]#authnLevel:limited:this:
- subtreeACI: deny: wo[entryACI, subtreeACI, salary]#this
- subtreeACI: grant:rscmo,w#[all]#authnLevel:strong:group:
- cn=adminGroup,ou=Groups,o=sun.com
- subtreeACI: grant:bvtugeinad#[entry]#authnLevel:strong
- group: cn=adminGroup,ou=Groups,o=sun.com
-
-
- cn=admin,o=sun.com
- objectclass: top
- objectclass: person
- cn: admin
- sn: admin
- userPassword: secret
- salary: 10000
-
-
- ou=Groups,o=sun.com
- objectclass: top
- objectclass: organizationalUnit
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 54]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- ou: Groups
-
-
- cn=adminGroup,ou=Groups,o=sun.com
- objectclass: top
- objectclass: groupOfUniqueNames
- uniquemember: cn=admin,o=sun.com
-
-
- ou=Eng,o=sun.com
- objectclass: top
- objectclass: organizationalUnit
- ou: Eng
-
-
- cn=Joe Engineer,ou=Eng,o=sun.com
- objectclass: top
- objectclass: person
- cn: Joe Engineer
- sn: Engineer
- userPassword: secret
- salary: 10000
-
-
- ou=Sales,o=sun.com
- objectclass: top
- objectclass: organizationalUnit
-
-
- cn=Joe Sales,ou=Sales,o=sun.com
- objectclass: top
- objectclass: person
- cn: Joe Sales
- sn: Sales
- userPassword: secret
- salary: 100000000000
-
-The access control policy in this DIT policy may be described as
-follows:
-
- 1. anonymous users have full read, search, and compare rights to the
- whole DIT, except for the important attributes userPassword,
- subtreeACI, entryACI, and salary.
-
- 2. Any user bound with a limited authentication level can modify any
- attributes in his own entry, except subtreeACI, entryACI and
- salary.
-
- 3. Any user can read all attributes in his own entry.
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 55]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- 4. Any user bound with a limited authentication level can retrieve
- the effective rights on his own entry (including userPassword,
- salary, entryACI and subtreeACI).
-
- 5. users, bound with a strong authentication level, in the
- cn=adminGroup,ou=Groups,o=sun.com group have full rights in the
- whole DIT.
-
-Then here are some examples of requests to get the effective rights and
-the responses:
-
-Example 1. Suppose we issue a search authenticated to level strong as
-"cn=admin,o=sun.com" (who is in the group
-cn=adminGroup,ou=Groups,o=sun.com), with base "o=sun.com", search filter
-"objectclass=*", requested attributes "* entryACI", with the
-getEffectiveRights control subject set to "cn=Joe
-Sales,ou=Sales,o=sun.com" and the MachineSubject specifying the
-ipAddress and dnsName of the client machine and the authnLevel set to
-limited.
-
-Then the search result and effective rights we see are:
-
- o=sun.com
- objectclass: top
- objectclass: organization
- o: sun.com
-
-
- entryLevelRights: bvt
- attributeLevelRights: objectclass,o: rsc,entryACI: none
- ---
- cn=admin,o=sun.com
- objectclass: top
- objectclass: person
- cn: admin
- sn: admin
- userPassword: secret
- salary: 10000
-
-
- entryLevelRights: bvt
- attributeLevelRights: objectclass,cn,sn: rsc
- userPassword,salary,entryACI: none
- ---
- ou=Groups,o=sun.com
- objectclass: top
- objectclass: organizationalUnit
- ou: Groups
-
-
- entryLevelRights: bvt
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 56]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
- attributeLevelRights: objectclass,ou: rsc,entryACI: none
- ---
- ou=Eng,o=sun.com
- objectclass: top
- objectclass: organizationalUnit
-
-
- entryLevelRights: bvt
- attributeLevelRights: objectclass,ou: rsc,entryACI: none
- ---
- cn=Joe Engineer,ou=Eng,o=sun.com
- objectclass: person
- cn: Joe Engineer
- sn: Engineer
- userPassword: secret
- salary: 10000
-
-
- entryLevelRights: bvt
- attributeLevelRights: objectclass,cn,sn: rsc
- userPassword,salary,entryACI: none
- ---
- ou=Sales,o=sun.com
- objectclass: top
- objectclass: organizationalUnit
-
-
- entryLevelRights: bvt
- attributeLevelRights: objectclass,ou: rsc,entryACI: none
- ---
- cn=Joe Sales,ou=Sales,o=sun.com
- objectclass: person
- cn: Joe Sales
- sn: Sales
- userPassword: secret
- salary: 100000000000
-
-
- entryLevelRights: bvtg
- attributeLevelRights: objectclass,cn,sn,userPassword: rscow
- salary,entryACI: rsc
-
-
-9.5 Client-Server Interaction
-
-The GetEffectiveRightsRequest control requests the rights that are in
-effect for requested directory entry/attribute based on the specified
-subject. The server that consumes the search operation looks up the
-rights for the returned directory information based on the subject and
-returns that rights information as defined above.
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 57]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-There are six possible scenarios that may occur as a result of the
-GetEffectiveRights control being included on the search request:
-
-
- 1. If the server does not support this control and the client
- specified TRUE for the control's criticality field, then the
- server MUST return unavailableCriticalExtension as a return code
- in the searchResponse message and not send back any other results.
- This behavior is specified in section 4.1.12 of [LDAPv3].
-
- 2. If the server does not support this control and the client
- specified FALSE for the control's criticality field, then the
- server MUST ignore the control and process the request as if it
- were not present. This behavior is specified in section 4.1.12 of
- [LDAPv3].
-
- 3. If the server supports this control but for some reason the server
- cannot process it and the client specified TRUE for the control's
- criticality field, then the server SHOULD do the following: return
- unavailableCriticalExtension as a return code in the searchResult
- message.
-
- 4. If the server supports this control but for some reason the server
- cannot process it and the client specified FALSE for the control's
- criticality field, then the server should process as 'no rights
- returned' and include the result Unavailable in the
- GetEffectiveRightsResponse control in the searchResult message.
-
- 5. If the server supports this control and can return the rights
- information, then it should include the GetEffectiveRightsResponse
- control in the searchResult message with a result of success.
-
- 6. If the search request failed for any other reason, then the server
- SHOULD omit the GetEffectiveRightsResponse control from the
- searchResult message.
-
-The client application is assured that the correct rights are returned
-for scope of the search operation if and only if the
-GetEffectiveRightsResponse control returns the rights. If the server
-omits the GetEffectiveRightsResponse control from the searchResult
-message, the client SHOULD assume that the control was ignored by the
-server.
-
-The GetEffectiveRightsResponse control, if included by the server in the
-searchResponse message, should have the GetEffectiveRightsResult set to
-either success if the rights are returned or set to the appropriate
-error code as to why the rights could not be returned.
-
-The server may not be able to return a right because it may not exist in
-that directory object's attribute; in this case, the rights request is
-ignored with success.
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 58]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-10. Security Considerations
-
-This document proposes protocol elements for transmission of security
-policy information. Security considerations are discussed throughout
-this model. Because subject security attribute information is used to
-evaluate decision requests, it is security-sensitive information and
-must be protected against unauthorized modification whenever it is
-stored or transmitted.
-
-Interaction of access control with other directory functions (other than
-the ones defined in this document) are not defined in this document, but
-instead in the documents where those directory functions are defined.
-For example, the directory replication documents should address the
-interaction of access control with the replication function.
-
-In general, IP addresses and DNS names should not be used as identities
-(subjects) since they can be easily spoofed. However, some widely-
-deployed implementations have long supported and continue to support IP
-addresses and DNS names in ACI to enforce access controls based on
-topology. Thus IP address and DNS name are retained in the access
-control model though their use should be discouraged in new deployments.
-
-It is good security practice to set defaults to the most secure
-settings. This is done to ensure that accidentally omitting a security
-field does not compromise security. Following this practice in the case
-of authnLevel would result in a default of "strong". This would have
-meant that ACI with omitted authnLevel in directories where "strong"
-authentication is not available (the great majority of environments at
-this time) would deny all access, causing confusion among users and
-administrators. To avoid this problem, authnLevel is required on all
-ACI. This has the useful side-effect of forcing administrators to think
-about the strength of their authentication system when setting up ACI.
-
-All of the advantages of authnLevel-based access control may be lost if
-system administrators do a poor job of associating actual authentication
-mechanisms with the authnLevels in the model. Administrators should use
-external guidelines (for an example, see [AUTHMAP]) if they are not
-completely familiar with the relative strengths of the authentication
-mechanisms available in their environment. In addition, administrators
-in replicated environments should make sure that the
-authnLevel/authentication mechanism mappings at all replicating sites
-are consistent.
-
-
-
-11. References
-
-[ABNF] D. Crocker, P. Overell, "Augmented BNF for Syntax Specifications:
-ABNF", RFC 2234, November 1997.
-
-[ATTACK] R. Shirey, "Internet Security Glossary", RFC 2828, May 2000.
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 59]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-[ATTR] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
-Access Protocol (v3)": Attribute Syntax Definitions, RFC 2252, December
-1997.
-
-[AUTHMAP] K. Zeilenga, "Authentication Mechanisms Levels", Internet
-Draft, draft-zeilenga-auth-lvl-01.txt, April 2001.
-
-[AuthMeth] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan,
-"Authentication Methods for LDAP", RFC 2829, May 2000.
-
-[Bradner97] S. Bradner, "Key Words for use in RFCs to Indicate
-Requirement Levels", RFC 2119.
-
-[DirCompMatch] S. Legg, "LDAP & X.500 Component Matching Rules",
-Internet Draft, draft-legg-ldapext-component-matching-02.txt, May 30,
-2001.
-
-[ECMA] ECMA, "Security in Open Systems: A Security Framework" ECMA
-TR/46, July 1988.
-
-[IPV6] R. Hinden, S. Deering, "IP Version 6 Addressing Architecture",
-RFC 2373, July 1998.
-
-[LangCode] M. Wahl, T. Howes, "Use of Language Codes in LDAP", RFC 2596,
-May 1999.
-
-[LDAPv3] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
-Protocol (v3)", RFC 2251, December 1997.
-
-[REQTS] E. Stokes, R. Byrne, R. Blakley, "Access Control Requirements
-for LDAP", RFC 2820, May 2000.
-
-[SUBENTRY] E. Reed, "LDAP Subentry Schema", Internet Draft, draft-ietf-
-ldup-subentry-08.txt, April 2001.
-
-[UTF] M. Wahl, S. Kille, "Lightweight Directory Access Protocol (v3)": A
-UTF-8 String Representation of Distinguished Names", RFC 2253, December
-1997.
-
-[X501] Recommendation X.501 (1993), "Information Technology--Open
-Systems Interconnection--The Directory: Models".
-
-[X511] ITU-T, "Information technology - Open Systems Interconnection -
-The Directory: Abstract service definition", ITU-T Recommendation X.511
-(1993) | ISO/IEC 9594-3:1994.
-
-
-ACKNOWLEDGEMENT
-
-This is to acknowledge the numerous companies and individuals who have
-contributed their valuable help and insights to the development of this
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 60]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-specification.
-
-
-AUTHOR(S) ADDRESS
-
- Ellen Stokes Bob Blakley
- Tivoli Systems Tivoli Systems
- 9442 Capital of Texas Hwy N 9442 Capital of Texas Hwy N
- Austin, TX 78759 Austin, TX 78759
- USA USA
- mail-to: estokes@tivoli.com mail-to: blakley@tivoli.com
- phone: +1 512 436 9098 phone: +1 512 436 1564
- fax: +1 512 436 1190 fax: +1 512 436 1199
-
- Debbie Rinkevich Robert Byrne
- Momenta Sun Microsystems
- --- 14 Chemin du Vieux Chene
- Austin, TX Meylan ZIRST 38240
- USA France
- mail-to: drinkevich@momenta.com mail-to: robert.byrne@.sun.com
- phone: +1 512 732 0060 ext 125 phone: +33 (0)4 76 188 205
-
- Rick Huber
- AT&T Laboratories
- 200 Laurel Avenue South
- Middletown, NJ 07748
- USA
- mail-to: rvh@att.com
- phone: +1 732 420 2632
- fax: +1 732 368 1690
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 61]
-
-
-
-
-
-Internet-Draft Access Control Model 29 June 2001
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Stokes, et al Expires 29 December 2001 [Page 62]
-
-
-
-
-
-
-
-
-
- CONTENTS
-
-
- 1. Introduction................................................... 2
-
- 2. The LDAPv3 Access Control Model................................ 3
-
- 3. Access Control Mechanism Attributes............................ 5
- 3.1 Root DSE Attribute for Access Control Mechanism........... 5
- 3.2 Subentry Class Access Control Mechanism................... 5
-
- 4. The Access Control Information Attributes, Syntax, and
- Rules.......................................................... 6
- 4.1 The ABNF and ASN.1........................................ 7
- 4.1.1 ACI UTF-8 String Representation 7
- 4.1.2 ACI Binary Representation 10
- 4.2 The Components of entryACI and subtreeACI Attributes...... 12
- 4.2.1 Access Rights and Permissions 12
- 4.2.2 Attributes 16
- 4.2.3 Subjects and Associated Authentication 16
- 4.3 Access Control Decision Making............................ 18
- 4.3.1 The Parameters to the Access Decision
- Algorithm 18
- 4.3.2 Applicability Rules 19
- 4.3.3 Precedence Rules 22
- 4.3.4 Access Control Decision Algorithm 24
- 4.3.5 Precedence/Inheritance Access Decision Example 25
-
- 5. Required Permissions for each LDAP Operation................... 28
- 5.1 Bind Operation............................................ 28
- 5.2 Search Operation.......................................... 28
- 5.2.1 Protecting the naming attributes of DNs 31
- 5.3 Modify Operation.......................................... 31
- 5.4 Add Operation............................................. 32
- 5.5 Delete Operation.......................................... 33
- 5.6 Modify DN Operation....................................... 34
- 5.7 Compare Operation......................................... 35
- 5.8 Abandon Operation......................................... 35
- 5.9 Extended Operation........................................ 35
-
- 6. Required Permissions for Handling Aliases and References....... 36
- 6.1 ACI Distribution.......................................... 36
- 6.2 Aliases................................................... 36
- 6.3 Referrals................................................. 37
-
- 7. Controlling Access to Access Control Information............... 37
-
- 8. ACI Examples................................................... 37
- 8.1 Attribute Definition...................................... 38
- 8.2 Modifying the entryACI and subtreeACI Values.............. 38
- 8.3 Evaluation................................................ 40
-
-
-
- - i -
-
-
-
-
-
-
-
-
-
-
-
- 8.4 ModDN..................................................... 42
- 8.5 Interaction Among ACI..................................... 45
- 8.6 Use of ipAddress in ACI................................... 47
- 8.7 Use of authnLevel in ACI.................................. 49
-
- 9. GetEffectiveRights Control..................................... 50
- 9.1 Request Control........................................... 51
- 9.2 Response Control.......................................... 52
- 9.3 Access control for the Get Effective Rights Control....... 53
- 9.4 Get Effective Rights example.............................. 54
- 9.5 Client-Server Interaction................................. 57
-
-10. Security Considerations........................................ 59
-
-11. References..................................................... 59
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - ii -
-
-
-
-
-
-
-
-
-
-
-
-Full Copyright Statement
-
-Copyright (C) The Internet Society (2000). All Rights Reserved.
-
-This document and translations of it may be copied and furnished to
-others, and derivative works that comment on or otherwise explain it or
-assist in its implementation may be prepared, copied, published and
-distributed, in whole or in part, without restriction of any kind,
-provided that the above copyright notice and this paragraph are included
-on all such copies and derivative works. However, this document itself
-may not be modified in any way, such as by removing the copyright notice
-or references to the Internet Society or other Internet organizations,
-except as needed for the purpose of developing Internet standards in
-which case the procedures for copyrights defined in the Internet
-Standards process must be followed, or as required to translate it into
-languages other than English.
-
-The limited permissions granted above are perpetual and will not be
-revoked by the Internet Society or its successors or assigns.
-
-This document and the information contained herein is provided on an "AS
-IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
-FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
-LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT
-INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR
-FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - iii -
-
-
-
-
diff --git a/src/site/sandbox/rfcs/rfc3642.txt.pdf b/src/site/sandbox/rfcs/rfc3642.txt.pdf
deleted file mode 100644
index e2174cf..0000000
--- a/src/site/sandbox/rfcs/rfc3642.txt.pdf
+++ /dev/null
Binary files differ
diff --git a/src/site/sandbox/rfcs/rfc3698.txt.pdf b/src/site/sandbox/rfcs/rfc3698.txt.pdf
deleted file mode 100644
index 230ffbe..0000000
--- a/src/site/sandbox/rfcs/rfc3698.txt.pdf
+++ /dev/null
Binary files differ
diff --git a/src/site/site.xml b/src/site/site.xml
deleted file mode 100644
index ccb53f1..0000000
--- a/src/site/site.xml
+++ /dev/null
@@ -1,67 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<project>
- <bannerLeft>
- <src>images/apache-directory-logo.png</src>
- <href>http://directory.apache.org/</href>
- </bannerLeft>
- <bannerRight>
- <name>ApacheDS</name>
- </bannerRight>
- <body>
- <links>
- <item name="ApacheDS" href="http://directory.apache.org/subprojects/apacheds/index.html"/>
- <item name="Naming" href="http://directory.apache.org/subprojects/naming/index.html"/>
- <item name="MINA (Network Layer)" href="http://directory.apache.org/subprojects/mina/index.html"/>
- <item name="Directory" href="http://directory.apache.org/index.html"/>
- </links>
- <menu name="Apache Directory Server">
- <item name="Overview" href="/index.html"/>
- <item name="Features" href="/features.html"/>
- <item name="Roadmap" href="/roadmap.html"/>
- <item name="Documentation" collapse="false">
- <item name="User's Guide" href="/docs/users/index.html" collapse="true">
- <item name="Building" href="/docs/users/building.html"/>
- <item name="Authentication" href="/docs/users/authentication.html"/>
- <item name="Authorization" href="/docs/users/authorization.html"/>
- <item name="Subentries" href="/docs/users/subentries.html"/>
- <item name="Collective Attributes" href="/docs/users/collective.html"/>
- <item name="Configuration" href="/docs/users/configuration.html"/>
- <item name="Partitions" href="/docs/users/partitions.html"/>
- <item name="Maven Plugin" href="/docs/users/plugin.html"/>
- </item>
- <item name="Developer's Guide" href="/docs/developers/index.html" collapse="true">
- <item name="Architecture" href="/docs/developers/architecture.html"/>
- <item name="Components" href="/docs/developers/components.html"/>
- <item name="Networking" href="/docs/developers/networking.html"/>
- <item name="Protocol" href="/docs/developers/protocol.html"/>
- <item name="Backend Subsystem" href="/docs/developers/backend.html"/>
- </item>
- <item name="Articles" href="/docs/articles.html"/>
- <item name="API Docs" href="/docs/api/index.html"/>
- </item>
- <item name="ApacheDS Modules" href="/modules.html"/>
- <item name="Releases" href="/releases.html"/>
- <item name="Downloads" href="http://www.apache.org/dyn/closer.cgi/directory/apacheds/"/>
- </menu>
-
- <!-- <menu name="Project Information">
- <item name="Combined Javadocs" href="/apidocs/index.html"/>
- <item name="Wiki" href="http://wiki.apache.org/directory"/>
- <item name="Open Issues" href="http://issues.apache.org/jira/browse/DIREVE"/>
- <item name="Source Repositories" href="http://svn.apache.org/viewcvs.cgi/directory/apacheds/trunk/?root=Apache-SVN"/>
- <item name="Mailing Lists" href="/mailing-lists.html"/>
- <item name="License" href="/license.html"/>
- <item name="Notices" href="/notices.html"/>
- </menu> -->
-
- <!-- Commented out, still useful as a placeholder for the next event
- <menu name="ApacheCon US 2005">
- <item name="ApacheCon US 2005" href="http://www.apachecon.com/"
- img="http://apache.org/images/ac2005us_blue_125x125.jpg" />
- </menu>
- -->
- ${reports}
- </body>
-
-</project>
diff --git a/src/site/xdoc/docs/developers/aci_aciitemabnf.xml b/src/site/xdoc/docs/developers/aci_aciitemabnf.xml
deleted file mode 100644
index fe8ee35..0000000
--- a/src/site/xdoc/docs/developers/aci_aciitemabnf.xml
+++ /dev/null
@@ -1,198 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="ersiner">ersiner</author>
- <title>ApacheDS - ACIItem ABNF Grammar</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>
- <table>
- <tr>
- <th>
- <img src="http://docs.safehaus.org/images/icons/emoticons/information.png"/>
- </th>
- <th>
- <center>The Apache Directory Server way...</center>
- </th>
- </tr>
- <tr>
- <td/>
- <td>
- <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>
- </td>
- </tr>
- </table>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/developers/aci_aciitemasn1.xml b/src/site/xdoc/docs/developers/aci_aciitemasn1.xml
deleted file mode 100644
index 28fa305..0000000
--- a/src/site/xdoc/docs/developers/aci_aciitemasn1.xml
+++ /dev/null
@@ -1,546 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="ersiner">ersiner</author>
- <title>ApacheDS - ACIItem ASN.1 Grammar</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>
diff --git a/src/site/xdoc/docs/developers/aci_implnotes.xml b/src/site/xdoc/docs/developers/aci_implnotes.xml
deleted file mode 100644
index 88242a4..0000000
--- a/src/site/xdoc/docs/developers/aci_implnotes.xml
+++ /dev/null
@@ -1,290 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
-
- </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>
- <table>
- <tr>
- <td>
- <img src="http://docs.safehaus.org/images/icons/emoticons/warning.png"/>
- </td>
- <td>
- <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>
- </td>
- </tr>
- </table>
- <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>
diff --git a/src/site/xdoc/docs/developers/aci_notesfromx501 b/src/site/xdoc/docs/developers/aci_notesfromx501
deleted file mode 100644
index 5e9e0d8..0000000
--- a/src/site/xdoc/docs/developers/aci_notesfromx501
+++ /dev/null
@@ -1,166 +0,0 @@
-<?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>
diff --git a/src/site/xdoc/docs/developers/architecture.xml b/src/site/xdoc/docs/developers/architecture.xml
deleted file mode 100644
index 2b1ff4f..0000000
--- a/src/site/xdoc/docs/developers/architecture.xml
+++ /dev/null
@@ -1,116 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Architecture</title>
- </properties>
-
- <body>
- <section name="High Level Architecture">
- <subsection name="A picture is worth a thousand words!">
- <img src="../images/architecture.png"/>
-
- <p>
- The server is actually composed of two separable subsystems: the LDAP
- protocol provider within the SEDA framework and the JNDI provider
- (a.k.a. the backend subsystem).
- </p>
-
- <p>
- Below we touch breifly on each major subsystem however a more detailed
- presentation is available describing the server's architecture. It was an
- ApacheCon presentation in 04 and is available
-<a href="https://karasulu.homeip.net/svn/akarasulu/apachecon/eve-presentation/eve-intro-long.ppt">here</a>.
- </p>
- </subsection>
-
- <subsection name="LDAP Protocol Provider">
- <p>
- The LDAP protocol provider is an implementation of the SEDA protocol
- provider interface. SEDA implements a provider architecture where
- protocols snap into the framework like legos to service protocol
- requests. A SEDA provider has no relation to a JNDI provider. Note
- it can get confusing when talking about providers for SEDA or for
- JNDI so we try our best to qualify which we refer to explicitly.
- </p>
-
- <p>
- Other protocol providers may be added to a SEDA instance to service
- multiple protocols on their respective service ports to share the same
- plumbing. In the picture above we show the Kerberos SEDA provider
- we've implemented along side the LDAP SEDA provider
- </p>
-
- <p>
- The LDAP protocol provider contains request handlers for each LDAP
- request PDU type. These handlers translate LDAP requests into
- operations against an LDAP JNDI provider. This LDAP JNDI provider by
- default is the JNDI provider. However the JNDI provider can be
- switched using environment properties to use the SUN LDAP JNDI
- provider. When using the SUN JNDI Provider the SEDA protocol provider
- becomes an LDAP proxy server.
- </p>
-
- <p>
- The LDAP protocol provider is extremely simple yet powerful. It
- merely acts as an LDAP request PDU to JNDI operation transducer. On
- the wire LDAP requests trigger calls against JNDI contexts through
- handlers.
- </p>
- </subsection>
-
- <subsection name="JNDI Provider">
- <p>
- The heart of the server resides within the backend subsystem or the
- JNDI provider. The JNDI provider is a JNDI provider for the
- LDAP namespace. However this provider does not talk LDAP on the wire,
- it effects the internal backing stores of the server directly. Hence
- the JNDI Provider is really the server side JNDI provider.
- </p>
-
- <p>
- Fundamentally JNDI is used as the facade to the entire backend
- subsystem. JNDI interfaces are used to operated upon server backing
- stores this way. JNDI also serves as the integration API for
- embedding the server. The ServerContextFactory starts up the backend
- subsystem as well as the networking code when the first initial
- context is requested. All other contexts do not incur startup costs.
- This unique use of JNDI enables code to simply switch JNDI providers
- to embed the server. It also makes data access code in stored
- procedures that uses JNDI capable of running inside and outside of
- the server which makes testing really easy.
- </p>
-
- <p>
- The directory server's backend subsystem contains most of the guts of
- the server. We want functionality like replication or triggers to be
- present there regardless of whether the server is in standalone mode
- or embedded within another application. Hence keeping it within the
- backend made sense.
- </p>
-
- <p>
- The server contains backing stores to store LDAP entries which really
- are serialized javax.naming.directory.Attributes objects. These
- entries live within database partitions attached to a naming context.
- All entries within these contexts are contained within the partition
- assigned to it. Several partitions can be present within the same
- directory server instance. Operations against contexts are routed by
- a Nexus based on the name (DN) of the entry associated with the
- operation.
- </p>
-
- <p>
- JNDI contexts hence translate relative operations to distinguished
- operations against the Nexus which routes these calls to the
- respective partition to add, delete, modify, search or move around
- entries. Between calls from JNDI Contexts to the RootNexus an
- interceptor framework intervenes to inject services like replication,
- authorization and more.
- </p>
- </subsection>
-
- </section>
-
- </body>
-</document>
diff --git a/src/site/xdoc/docs/developers/backend.xml b/src/site/xdoc/docs/developers/backend.xml
deleted file mode 100644
index 8e91451..0000000
--- a/src/site/xdoc/docs/developers/backend.xml
+++ /dev/null
@@ -1,120 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Backend</title>
- </properties>
-
- <body>
- <section name="Backend Subsystem">
- <p>
- The backend subsystem is everything minus the networking layer and the
- protocol handling layer. It is composed of several parts in itself: the
- JNDI provider, interceptor framework, schema subsystem, and database
- subsystem. Each sub-subsystem of the backend is described in the
- sections to follow.
- </p>
-
-
- <subsection name="Database Subsystem">
- <p>
- The overall design to the database subsystem is described to some
- degree within the partition documentation which can be found
- <a href="../users/partition.html">here</a>. In summary this subsystem
- is responsible for storing and accessing entries addressed by DN.
- </p>
-
- <p>
- Eventually we intend to delve into the design of the database
- subsystem by breaking down the search engine, optimizer and default
- backing store design which uses JDBM BTrees.
- </p>
-
- <p>
- For future reference below the RootNexus is the top level object or
- facade of the database subsystem. It contains all context partitions
- and routes calls to them based on the location of the context within
- the namespace.
- </p>
- </subsection>
-
-
- <subsection name="JNDI Provider">
- <p>
- The JNDI Provider is just an implementation of the
- InitialContextFactory, Context, and other derived interfaces. The
- factory is used to fire up the entire server if it has not been
- started already to service the JNDI request. The contexts are simple
- wrappers around the database subsystem which point to a specific entry
- withing the namespace. More will be put here as time progresses ...
- </p>
- </subsection>
-
-
- <subsection name="Interceptor Framework">
- <p>
- Calls to the RootNexus are made from within Context implementations
- of the JNDI provider. Relative Context positions or names are
- translated into (absolute) distinguished names and the appropriate
- call is made on the RootNexus. The calls are intercepted using a
- proxy and additional functionality is injected before, after and on
- exception to calls made on the RootNexus.
- </p>
-
- <p>
- A framework is built around this. The Context, parameters, return
- values and any exceptions that may be thrown by the call are
- encapsulated within an Invocation object. This object is passed to
- a chain of interceptors that operate on the values it holds to
- implement a service.
- </p>
-
- <p>
- There are three separate types or stages of interceptors.
- Interceptors can operate before a method invocation, after an
- invocation and when an error results during any point in this process.
- Separate chains of interceptors have been created for each stage. The
- Invocation object is passed through this chain and each interceptor
- operates upon it.
- </p>
-
- <p>
- Not all interceptor chains are created equally! The before and after
- chains are fail fast. Meaning the processing of an Invocation object
- shorts the rest of the chain if one interceptor fails while processing
- the invocation. This is not the case when processing exceptions in
- the on error interceptor chain. Regardless of an interceptor's
- success downstream, all interceptors are guaranteed a chance to
- operate on the Invocation object. This makes the on-error chain an
- excellent place to put cleanup code or code to handle failures.
- </p>
-
- <p>
- When implementing a cross cutting service with the interceptor
- framework one or more interceptors may be added to one or more
- chains. Keep in mind this framework helps inject new functionality
- but it can get conjested very quickly.
- </p>
- </subsection>
-
-
- <subsection name="Schema Subsystem">
- <p>
- The schema subsystem manages LDAP schema objects. These objects
- have a direct effect on how lookups and search operations are
- conducted on the directory. The subsystem contains a set of
- registries for each type of LDAP schema object based on OID.
- </p>
-
- <p>
- Schema objects may reference one another by OID and so the system
- is designed to dynamically resolve dependent objects by lookups on
- these registries.
- </p>
- </subsection>
-
-
- </section>
-
- </body>
-</document>
diff --git a/src/site/xdoc/docs/developers/components.xml b/src/site/xdoc/docs/developers/components.xml
deleted file mode 100644
index 6c74375..0000000
--- a/src/site/xdoc/docs/developers/components.xml
+++ /dev/null
@@ -1,153 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Components</title>
- </properties>
-
- <body>
- <section name="Resources">
- <p>
- If the following sections sound a little cryptic you might want
- to read a little about the IoC pattern. Below are some documents you
- might find useful when translating some of this babble:
- </p>
-
- <ul>
- <li><a href="http://wiki.apache.org/avalon/WhatIsIoC">
- Inversion of Control Pattern</a></li>
-
- <li><a href="http://wiki.apache.org/avalon/AvalonNoLogging?highlight=%28NoLogging%29">
- Paul Hammant's use of Monitors instead of Loggers</a> is a technique we use.
- </li>
- </ul>
- </section>
-
- <section name="Components and Services">
- <p>
- The server is designed as a system of highly granular components.
- Some components are a collection of other components with a facade to
- form a subsystem of the server. Subsystems can contain other
- subsystems and one component can depend on zero or more other
- components.
- </p>
-
- <p>
- A micro kernel or component container is required to run the server. By
- default the server uses its oun glue rather than a container with all the
- bells and whistles. However it can run in any micro kernel using
- service wrappers. A micro kernel is a peice of code operating as a
- component container providing services for that component and running
- the component through a set of life-cycles. The server is designed to run
- on any micro kernel using component wrappers. The subsystems and
- components are designed as Plain Old Java Interfaces and Objects (POJIs
- and POJOs) that can be wrapped to make them interoperate within
- different containers.
- </p>
-
- <p>
- Each component within the server has a public service interface which
- declares what that component can do for its clients. It is always good
- to keep the interfaces separate from any specific implementations. You
- can have many implementations for the same service interface. Secondly
- the classloader heirarchy in containers often puts implementation
- classloaders under a classloader containing the service interface.
- This allows containers to manage multiple implementations for the
- same service without having conflicts. Also implementations can be
- created and destroyed in separate classloaders without affecting one
- another.
- </p>
- </section>
-
- <section name="Container Independence">
- <p>
- One of the biggest impediments we've had to deal with while developing
- the server and its precursors was having containers go in and out of
- fashion. We lost several months of development time while switching
- from Pheonix to Merlin for example. Today we use some custom glue
- instead.
- </p>
-
- <p>
- The server has been designed this time from the ground up to be
- independent of any container. We are doing this by making the default
- implementation of a service a Plain Old Java Object (POJO). Wrapper
- implementation projects, one for each supported container, are used to
- wrap these POJO components to introduce container specific lifecycles
- and to encapsulate container idiosyncrasies.
- </p>
-
- <p>
- This approach we have found has several advantagous side-effects. One
- benefit was a nice separation of concerns. By separating out the
- container specific code, configuration and build aspects, developers
- no longer need to be aware of container details. They can focus on the
- core implemenation as a simple class implementing an interface. Those
- interested in making the server run in one container as opposed to
- another can focus on their container wrapper without the clutter of
- another container getting in the way. This reduces the complexity and
- learning curve for all those involved in developing the directory
- server's components and subsystems.
- </p>
- </section>
-
- <section name="Monitors Verse Loggers">
- <p>
- Above we provided a link to Paul Hammant's concept of using Monitors
- in place of Logging. Briefly without restating his wiki we'd like to
- review how we use Monitors instead of Loggers alone.
- </p>
-
- <p>
- Like any other server we need to log what goes on. But rather than log
- we need to monitor. Logging is a specific type of monitoring for the
- sake of archiving what we monitor. Paul proposed that every service
- should propose a very specific Monitor interface. This is a good idea
- because it is the responsibility of the service to announce those
- interesting, and monitoring worthy events. The interface forces
- signatures to explicitly describe what information is involved in the
- monitoring of an event.
- </p>
-
- <p>
- This makes the component implementation logging system independent
- which is provided by a container implementation. Each wrapper
- implementation can provide its own Monitor implementation
- to interface with the Logging system of the target container.
- </p>
-
- <p>
- We gain by becoming more container independent but more importantly we
- are forced to consider what events in a service constitutes a
- noteworthy event. This throught provoking aspect is perhaps the most
- beneficial.
- </p>
- </section>
-
- <section name="Configuration Beans">
- <p>
- Containers are neat because they give component developers a lot of
- nice features out of the box and that's what they should do. The key
- to maintaining container independence is to abstract away from these
- features while still taking advantage of them. This usually translates
- into a few extra interfaces and classes.
- </p>
-
- <p>
- One benefit of containers is to provide a means to associate a
- configuration with a component. Most allow for configurations to be
- stored in properties files and/or XML files. Containers read and load
- the configuration as a part of processing the lifecycles of components.
- </p>
-
- <p>
- Rather than have POJO component implementations depend directly on
- configuration interfaces specific to a container we explicitly define
- configuration beans. POJO implementations are then designed to take
- configuration beans as constructor arguments if the number of parameters
- is large and putting so many parameters into a constructor would be
- too cumbersome.
- </p>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/developers/index.xml b/src/site/xdoc/docs/developers/index.xml
deleted file mode 100644
index 2744dec..0000000
--- a/src/site/xdoc/docs/developers/index.xml
+++ /dev/null
@@ -1,78 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Developer's Guide</title>
- </properties>
-
- <body>
- <section name="Developer's Guide">
- <p>
- </p>
-
- <table>
- <tr>
- <th>Topic</th>
- <th>Description</th>
- </tr>
-
- <tr>
- <td>
- <a href="./architecture.html">Architecture</a>
- </td>
- <td>
- The server's high level architecture.
- </td>
- </tr>
-
- <tr>
- <td>
- <a href="./components.html">Components</a>
- </td>
- <td>
- How we do components in the directory server.
- </td>
- </tr>
-
- <tr>
- <td>
- <a href="./networking.html">Networking</a>
- </td>
- <td>
- Describes the directory servers's networking code.
- </td>
- </tr>
-
- <tr>
- <td>
- <a href="./protocol.html">Protocol</a>
- </td>
- <td>
- The design of LDAP protocol layer.
- </td>
- </tr>
-
- <tr>
- <td>
- <a href="./backend.html">Backend Subsystem</a>
- </td>
- <td>
- Looks at the backend subsystem design in detail.
- </td>
- </tr>
-
- <tr>
- <td>
- <a href="./.html"></a>
- </td>
- <td>
-
- </td>
- </tr>
-
- </table>
-
-
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/developers/interceptor_interactions.xml b/src/site/xdoc/docs/developers/interceptor_interactions.xml
deleted file mode 100644
index 1fb6936..0000000
--- a/src/site/xdoc/docs/developers/interceptor_interactions.xml
+++ /dev/null
@@ -1,164 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
- <title>ApacheDS - 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>
diff --git a/src/site/xdoc/docs/developers/interceptor_mechanism.xml b/src/site/xdoc/docs/developers/interceptor_mechanism.xml
deleted file mode 100644
index 7b0aaad..0000000
--- a/src/site/xdoc/docs/developers/interceptor_mechanism.xml
+++ /dev/null
@@ -1,115 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
- <title>ApacheDS - 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>
diff --git a/src/site/xdoc/docs/developers/networking.xml b/src/site/xdoc/docs/developers/networking.xml
deleted file mode 100644
index 9dff37a..0000000
--- a/src/site/xdoc/docs/developers/networking.xml
+++ /dev/null
@@ -1,64 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Networking</title>
- </properties>
-
- <body>
- <section name="Networking">
- <p>
- We wanted to keep the networking code as independent as possible to
- prevent it's concerns from creeping into the LDAP protocol handling
- code. Furthermore we wanted it to be independent of the LDAP protocol
- so it can be reused as much as possible with other protocols.
- </p>
-
- <p>
- This lead to the creation of a newtorking framework or two. These
- frameworks use different approaches and models to provide the network
- plumbing needed by internet protocol servers. A common protocol
- provider API is used to implement protocols enabling the provider on
- all network frameworks.
- </p>
-
- <p>
- Each network framework at the directory project has its own project so
- its best to delegate a description of each framework to the appropriate
- project documentation:
- </p>
-
- <table>
- <tr>
- <th>Framework</th> <th>Description</th>
- </tr>
-
- <tr>
- <td><a href="../../seda/index.html">seda</a></td>
-
- <td>
- A simple framework for implementing staged event driven internet
- protocol servers.
- </td>
- </tr>
-
- <tr>
- <td><a href="../../seda/index.html">sedang</a></td>
-
- <td>
- The next generation seda framework based on d-haven event packages.
- </td>
- </tr>
-
- <tr>
- <td><a href="../../mina/index.html">mina</a></td>
-
- <td>
- Multipurpose Infrastrusture for Network Applications based on ACE.
- </td>
- </tr>
- </table>
- </section>
-
- </body>
-</document>
diff --git a/src/site/xdoc/docs/developers/partitions.xml b/src/site/xdoc/docs/developers/partitions.xml
deleted file mode 100644
index aeae7f0..0000000
--- a/src/site/xdoc/docs/developers/partitions.xml
+++ /dev/null
@@ -1,21 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Partitions</title>
- </properties>
-
- <body>
- <section name="Default Partition Design">
- </section>
-
- <section name="How does alias dereferencing while searching work?">
- <p>You're going to want to read these documents here:</p>
-
- <ul>
- <li><a href="./xldbm.pdf">Paper LDAP database design by Tim Howes</a></li>
- <li><a href="./alias-dereferencing.pdf">Paper on alias dereferencing mechanism by Alex Karasulu</a></li>
- </ul>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/developers/protocol.xml b/src/site/xdoc/docs/developers/protocol.xml
deleted file mode 100644
index fea168b..0000000
--- a/src/site/xdoc/docs/developers/protocol.xml
+++ /dev/null
@@ -1,52 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Protocol</title>
- </properties>
-
- <body>
- <section name="Server's LDAP Protocol Provider">
- <subsection name="Provider API">
- <p>
- The network layer regardless of the implementation used (seda, sedang,
- or mina), defines protocol provider interfaces. Protocol implementors
- only need to implement these interfaces to plug into these framework
- implementations. A protocol provider essentially encapsulates the
- encoding/decoding of messages and request handlers (hooks) for the
- protocol. The networking code handles the rest to make it all work.
- </p>
-
- <p>
- The directory server has one or more protocol provider
- implementations. The primary implementation is for the LDAP protocol.
- The provider is rather simple in nature and has some unique properties
- which make it flexible enough to be used as an LDAP proxy server or
- an X.500 gateway server.
- </p>
- </subsection>
-
- <subsection name="Design">
- <p>
- The server's LDAP protocol provider translates on the wire LDAP
- requests into JNDI LDAP operations. Results from JNDI operations are
- then translated to LDAP responses pushed out on the wire. This thin
- implementation makes the protocol layer efficient and easy to grasp.
- </p>
-
- <p>
- The protocol provider is independent of the JNDI provider used. It is
- however dependent on the LDAP namespace. Hence it can only work with
- LDAP JNDI providers like the SUN LDAP JNDI provider and the server's
- JNDI provider.
- </p>
-
- <p>
- The grunt of the work done by the protocol provider is within the
- request handlers. There is a request handler for each LDAP request
- type.
- </p>
- </subsection>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/developers/xldbm.pdf b/src/site/xdoc/docs/developers/xldbm.pdf
deleted file mode 100644
index cb12b5a..0000000
--- a/src/site/xdoc/docs/developers/xldbm.pdf
+++ /dev/null
Binary files differ
diff --git a/src/site/xdoc/docs/users/acareas.xml b/src/site/xdoc/docs/users/acareas.xml
deleted file mode 100644
index 6754ae6..0000000
--- a/src/site/xdoc/docs/users/acareas.xml
+++ /dev/null
@@ -1,150 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
-
- </properties>
- <body>
- <section heading="h1" name="Introduction">
- <p>
-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>
- <a href="./subentries.html">Subentries</a>
-and the Administrative
-Model
- </li>
- <li>
- <a href="./authorization.html">Authorization</a>
- </li>
- </ul>
- </section>
- <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
-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
-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.
-These subentries apply access control information (ACI) in these prescriptiveACI
-attributes to collections of entries within the
-ACSA.</p>
- <subsection heading="h2" name="Adding an 'administrativeRole' Attribute">
- <p>
-An entry becomes an AP when it has an administrativeRole attribute added to it
-with the appropriate
-value
- <a href="./s.html">s</a>
-. For an ACSA, we need to add the 'accessControlSpecificArea' value to this
-attribute.
- </p>
- <p>
-Most of the time users will create partitions in the server and set the root
-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
-cover all entries under and including
-'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
-attribute does not already exist before attempting the add
-operation.</p>
- <source> ...
- // Get a DirContext on the dc=example,dc=com entry
- Hashtable env = new Hashtable();
- env.put( "java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory" );
- env.put( "java.naming.provider.url", "ldap://localhost:389/dc=example,dc=com" );
- env.put( "java.naming.security.principal", "uid=admin,ou=system" );
- env.put( "java.naming.security.credentials", "secret" );
- env.put( "java.naming.security.authentication", "simple" );
- ctx = new InitialDirContext( env );
-
- // Lookup the administrativeRole specifically since it is operational
- Attributes ap = ctx.getAttributes( "", new String[] { "administrativeRole" } );
- Attribute administrativeRole = ap.get( "administrativeRole" );
-
- // If it does not exist or has no ACSA value then add the attribute
- if ( administrativeRole == null || ! administrativeRole.contains( "accessControlSpecificArea" ) )
- {
- Attributes changes = new BasicAttributes( "administrativeRole", "accessControlSpecificArea", true );
- ctx.modifyAttributes( "", DirContext.ADD_ATTRIBUTE, changes );
- }
- ...
-</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
-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
-the inner area just add 'accessControlInnerArea' for the administrativeRole
-within the AP: same steps, same code, different value for the
-administrativeRole.</p>
- </section>
- <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
-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
-listed
-below:</p>
- <table>
- <tr>
- <th>
-Attribute</th>
- <th>
-SINGLE-VALUED</th>
- <th>
-Description</th>
- </tr>
- <tr>
- <td>
-cn</td>
- <td>
-no</td>
- <td>
-The name of the subentry used as its
-RDN</td>
- </tr>
- <tr>
- <td>
-subtreeSpecification</td>
- <td>
-yes</td>
- <td>
-The specification for the collection of entries the ACI is to be applied
-to.</td>
- </tr>
- <tr>
- <td>
-prescriptiveACI</td>
- <td>
-no</td>
- <td>
-The attribute holding the
-ACIItem</td>
- </tr>
- </table>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/users/allowselfpasswordmodify b/src/site/xdoc/docs/users/allowselfpasswordmodify
deleted file mode 100644
index de77e26..0000000
--- a/src/site/xdoc/docs/users/allowselfpasswordmodify
+++ /dev/null
@@ -1,58 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
- <title>AllowSelfPasswordModify</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>
- <table>
- <tr>
- <th>
- <img src="http://docs.safehaus.org/images/icons/emoticons/information.png"/>
- </th>
- <th>
- <center>"grantAdd + grantRemove = grantReplace"</center>
- </th>
- </tr>
- <tr>
- <td/>
- <td>
- <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>
- </td>
- </tr>
- </table>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/users/authentication.xml b/src/site/xdoc/docs/users/authentication.xml
deleted file mode 100644
index 583f14f..0000000
--- a/src/site/xdoc/docs/users/authentication.xml
+++ /dev/null
@@ -1,249 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
-
- </properties>
- <body>
- <section heading="h2" name="Server Authentication">
- <p>
-This page
-describes:</p>
- <ol nesting="0">
- <li>
-the status of
-authentication,</li>
- <li>
-how to bind (authenticate) as the admin superuser after starting the server the
-first
-time,</li>
- <li>
-adding non-superusers and binding to the directory as
-them,</li>
- <li>
-how to protect user
-passwords,</li>
- <li>
-how to disable anonymous
-binds,</li>
- <li>
-how to customize the server to use different authentication
-mechanisms.</li>
- </ol>
- <subsection heading="h3" name="Status">
- <p>
-Presently the directory server supports only simple authentication and anonymous
-binds while storing passwords in clear text within userPassword attributes in
-user
-entries.</p>
- <p>
-Within a short while we'll be able to store passwords using the authPassword
-property which uses strong one way hashes for authentication such as MD5 and
-SHA1. These schemes and the schema used are described in detail here
-in
- <a href="http://www.faqs.org/rfcs/rfc3112.html">RFC 3112</a>
-.
- </p>
- </subsection>
- <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
-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
-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.
-Second you'll have to change the password in the server.xml configuration file
-for the java.naming.security.credentials
-property.</p>
- <p>
-If you did not disable anonymous binds by setting the respective property
-(described below), then you can bind anonymously to the server without any
-username or
-password.</p>
- <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
-only.</p>
- </subsection>
- <subsection heading="h3" name="Adding and authenticating normal users">
- <p>
-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
-user.</p>
- <source>dn: uid=jdoe,ou=users,ou=system
-cn: John Doe
-sn: Doe
-givenname: John
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-objectclass: inetOrgPerson
-ou: Human Resources
-ou: People
-l: Las Vegas
-uid: jdoe
-mail: jdoe@apachecon.comm
-telephonenumber: +1 408 555 5555
-facsimiletelephonenumber: +1 408 555 5556
-roomnumber: 4613
-userpassword: test
-</source>
- <p>
-You can download
-this
- <a href="./newuser.ldif.html">newuser.ldif</a>
-file and use it to add the user. Below we use the ldapadd OpenLDAP client to
-import the LDIF file presuming the server was started on port 1024 on the
-localhost:
- </p>
- <source>ldapadd -a -D "uid=admin,ou=system" -f newuser.ldif -h localhost -p 1024 -x -w secret
-</source>
- <p>
-You can confirm the add/import by performing a search for the user. This time
-using the OpenLDAP search client you use the following
-command:</p>
- <source>ldapsearch -D "uid=admin,ou=system" -h localhost -p 1024 -x -w secret -s one
- -b "ou=users,ou=system" "(uid=jdoe)"
-</source>
- <p>
-You can start searching the directory using this new user like
-so:</p>
- <source>ldapsearch -D "uid=jdoe,ou=users,ou=system" -h localhost -p 1024 -x -w test -s one -b "ou=system" "(objectClass=*)"
-</source>
- </subsection>
- <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
-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
-groupOfNames or groupOfUniqueNames under the 'ou=groups,ou=system' are also
-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.
-This however shuts down access to everything by everyone except the admin user
-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>
-.
- </p>
- </subsection>
- <subsection heading="h3" name="Disabling anonymous binds">
- <p>
-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 setting the allowAnonymousAccess property to false in the server.xml
-configuration
-file.</p>
- </subsection>
- <subsection heading="h3" name="Using custom authenticators">
- <p>
-Authenticator SPI provides a way to implement your own authentication mechanism,
-for instance simple mechanism using password encryption such as MD5 or SHA1, or
-SASL mechanism. See the following
-example:</p>
- <source>import javax.naming.NamingException;
-
-import org.apache.ldap.server.auth.AbstractAuthenticator;
-import org.apache.ldap.server.auth.LdapPrincipal;
-import org.apache.ldap.server.jndi.ServerContext;
-import org.apache.ldap.common.exception.LdapNoPermissionException;
-import org.apache.ldap.common.name.LdapName;
-
-public class MyAuthenticator extends AbstractAuthenticator {
-
- public MyAuthenticator( )
- {
- // create authenticator that will handle "simple" authentication mechanism
- super( "simple" );
- }
-
- public void init() throws NamingException
- {
- ...
- }
-
- public LdapPrincipal authenticate( ServerContext ctx ) throws NamingException
- {
- ...
-
- // return the authorization id
- LdapName principalDn = new LdapName( dn );
- return new LdapPrincipal( principalDn );
- }
-}
-</source>
- <p>
-The authenticator class has to extend the
-org.apache.ldap.server.auth.AbstractAuthenticator. This class needs to have a
-no-argument constructor that calls the super() constructor with parameter the
-authentication mechanism it is going to handle. In the above example,
-MyAuthenticator class is going to handle the simple authentication mechanism. To
-implement a SASL mechanism you need to call super() with the name of the SASL
-mechanism, e.g. super( "DIGEST-MD5"
-).</p>
- <p>
-You can optionally implement the init() method to initialize your authenticator
-class. This will be called when the authenticator is loaded by ApacheDS during
-start-up.</p>
- <p>
-When a client performs an authentication, ApacheDS will call the authenticate()
-method. You can get the client authentication info from the server context.
-After you authenticate the client, you need to return the authorization id. If
-the authentication fails, you should throw an
-LdapNoPermissionException.</p>
- <p>
-When there are multiple authenticators registered with the same authentication
-type, ApacheDS will try to use them in the order it was registered. If one fails
-it will use the next one, until it finds one that successfully authenticates the
-client.</p>
- <p>
-To tell ApacheDS to load your custom authenticators, you need to specify it in
-the server.xml. You can also optionally specify the location of a .properties
-file containing the initialization parameters. See the following
-example:</p>
- <p>
-EXAMPLE BELOW IS NO LONGER VALID WITH XML
-CONFIGURATION</p>
- <source>server.authenticators=myauthenticator yourauthenticator
-
-server.authenticator.class.myauthenticator=com.mycompany.MyAuthenticator
-server.authenticator.properties.myauthenticator=myauthenticator.properties
-
-server.authenticator.class.yourauthenticator=com.yourcompany.YourAuthenticator
-server.authenticator.properties.yourauthenticator=yourauthenticator.properties
-</source>
- </subsection>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/users/building.xml b/src/site/xdoc/docs/users/building.xml
deleted file mode 100644
index 2143646..0000000
--- a/src/site/xdoc/docs/users/building.xml
+++ /dev/null
@@ -1,97 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
- <title>ApacheDS - Building</title>
- </properties>
- <body>
- <section heading="h2" name="Building and Running the Apache Directory Server">
- <p>
-All directory projects
-use
- <a href="http://maven.apache.org">Maven</a>
-as the default build tool. We try to remain current with the production version
-of Maven. As of 12/04 we use Maven 1.0.2 on JDK 1.4 and
-up.
- </p>
- <p>
-The multiproject plugin is used to build all the maven projects associated with
-the server. After checking out the server trunk from subversion, cd into it and
-run the following multiproject
-command:</p>
- <source>maven multiproject:install
-</source>
- <p>
-Once you've built the server you'll find an executable jar file under the
-main/target directory labeled apacheds-main-$version.jar which can be fired up
-like
-so:</p>
- <source>java -jar main/target/apacheds-main-$version.jar server.xml
-</source>
- <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
-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
-directory:
- </p>
- <source>java -jar main/target/apacheds-main-${version}.jar main/server.xml
-</source>
- </section>
- <section heading="h2" name="Apache Directory Server's Maven Modules">
- <p>
-The server is composed of 4 separate maven projects. These projects are
-summarized
-below:</p>
- <table>
- <tr>
- <th>
-Project</th>
- <th>
-Summary</th>
- </tr>
- <tr>
- <td>
-core</td>
- <td>
-The heart of the server which contains the JNDI Provider, interceptors,
-partitions and
-schema.</td>
- </tr>
- <tr>
- <td>
-shared</td>
- <td>
-Contains shared classes between modules to prevent cyclic
-deps.</td>
- </tr>
- <tr>
- <td>
-plugin</td>
- <td>
-Contains a maven plugin used while developing with/for the directory
-server.</td>
- </tr>
- <tr>
- <td>
-main</td>
- <td>
-Contains the ApacheDS application main() along with a special
-InitialContextFactory implemenation that extends the CoreContextFactory which is
-an InitialContextFactory implementation (ICF). This ICF is the
-ServerContextFactory and it initializes MINA adding the LDAP protocol provider
-as well as the other providers for protocols like Kerberos, Change Password,
-NTP, DNS and DHCP. Of course the configuration determines if these protocols are
-started or not. All protocols with the exception of NTP use the core LDAP store
-as their backing store with custom
-schema.</td>
- </tr>
- </table>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/users/enablesearchforallusers.xml b/src/site/xdoc/docs/users/enablesearchforallusers.xml
deleted file mode 100644
index 5934107..0000000
--- a/src/site/xdoc/docs/users/enablesearchforallusers.xml
+++ /dev/null
@@ -1,322 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
-
- </properties>
- <body>
- <section heading="h1" name="Enable Authenticated Users to Browse and Read Entries in a Subtree">
- <table>
- <tr>
- <th>
- <img src="http://docs.safehaus.org/images/icons/emoticons/warning.png"/>
- </th>
- <th>
- <center>The first time is always the hardest!</center>
- </th>
- </tr>
- <tr>
- <td/>
- <td>
- <p>
-We presume this is your first encounter and so many bases will be covered this
-time around. Every other trail will build on this information. So expect a
-little less to read as you gain
-momentum.</p>
- </td>
- </tr>
- </table>
- <p>
-Since the entire directory is locked down for all but the superuser, you're
-going to want to grant read and browse access to users for certain regions of
-the DIT. This will probably be the first thing you'll want to do after turning
-on access
-controls.</p>
- <subsection heading="h2" name="Check for insufficientAccessRights for Normal Users">
- <p>
-Just to make sure everything is locked down login as admin and create a new
-non-superuser. For more information on how to do this
-see
- <a href="./authentication.html">Authentication</a>
-. After creating the normal user make sure you cannot bind to dc=example,dc=com
-with access controls enabled. You should get an error trying to bind with a
-result code of 50 (insufficientAccessRights). If using JNDI to connect to the
-server you should get a NoPermissionException. After we apply the following ACI
-you can check
-again.
- </p>
- </subsection>
- <subsection heading="h2" name="Partition and Access Control Area Setup">
- <p>
-For this example we presume you have setup a partition at the namingContext
-dc=example,dc=com and have turned on access controls. Now you want to grant
-browse and read access to entries and their
-attributes.</p>
- <p>
-Before you can add a subentry with the prescriptiveACI you'll need to create an
-administrative area. For now we'll make the root of the partition the
-adminstrative point (AP). Every entry including this entry and those underneath
-it will be part of the autonous administrative area for managing access
-controls. To do this we must add the administrativeRole operational attribute to
-the AP entry.
-See
- <a href="./acarea.html">ACArea</a>
-for code and information about creating access control administrative
-areas.
- </p>
- </subsection>
- <subsection heading="h2" name="Adding the Subentry">
- <p>
-The subentry can be added using an LDIF or via code. We'll show the code but the
-LDIF can be accessed
-here
- <a href="./enablesearchforallusers.ldif.html">enableSearchForAllUsers.ldif</a>
-:
- </p>
- <source> // Get a DirContext on the dc=example,dc=com entry
- Hashtable env = new Hashtable();
- env.put( "java.naming.factory.initial", "com.sun.jndi.ldap.LdapCtxFactory" );
- env.put( "java.naming.provider.url", "ldap://localhost:" + port + "/dc=example,dc=com" );
- env.put( "java.naming.security.principal", "uid=admin,ou=system" );
- env.put( "java.naming.security.credentials", "secret" );
- env.put( "java.naming.security.authentication", "simple" );
- ctx = new InitialDirContext( env );
-
- // now add the A/C subentry below dc=example,dc=com
- Attributes subentry = new BasicAttributes( "cn", "enableSearchForAllUsers", true );
- Attribute objectClass = new BasicAttribute( "objectClass" );
- subentry.put( objectClass );
- objectClass.add( "top" );
- objectClass.add( "subentry" );
- objectClass.add( "accessControlSubentry" );
- subentry.put( "subtreeSpecification", "{}" );
- subentry.put( "prescriptiveACI", "{ \n" +
- " identificationTag \"enableSearchForAllUsers\",\n" +
- " precedence 14,\n" +
- " authenticationLevel simple,\n" +
- " itemOrUserFirst userFirst: \n" +
- " { \n" +
- " userClasses { allUsers }, \n" +
- " userPermissions \n" +
- " { \n" +
- " {\n" +
- " protectedItems {entry, allUserAttributeTypesAndValues}, \n" +
- " grantsAndDenials { grantRead, grantReturnDN, grantBrowse } \n" +
- " }\n" +
- " } \n" +
- " } " );
- ctx.createSubcontext( "cn=enableSearchForAllUsers", subentry );
-</source>
- <p>
-Before we cover the anatomy of this ACIItem, you might want to add the subentry
-and test access with a normal non-super user to make sure access is now
-granted.</p>
- </subsection>
- </section>
- <section heading="h1" name="ACIItem Description">
- <p>
-Here's the ACIItem you just added above without all the Java
-clutter:</p>
- <source>{
- identificationTag "enableSearchForAllUsers",
- precedence 14,
- authenticationLevel simple,
- itemOrUserFirst userFirst:
- {
- userClasses { allUsers },
- userPermissions
- {
- {
- protectedItems {entry, allUserAttributeTypesAndValues},
- grantsAndDenials { grantRead, grantReturnDN, grantBrowse }
- }
- }
- }
-}
-</source>
- <p>
-There are several parameters to this simple ACIItem. Here's a breif
-exaplanation of each field and it's meaning or
-significance.</p>
- <table>
- <tr>
- <th>
-Fields</th>
- <th>
-Description</th>
- </tr>
- <tr>
- <td>
-identificationTag</td>
- <td>
-Identifies the ACIItem within an
-entry.</td>
- </tr>
- <tr>
- <td>
-precedence</td>
- <td>
-Determine which ACI to apply with conflicting
-ACIItems.</td>
- </tr>
- <tr>
- <td>
-authenticationLevel</td>
- <td>
-User's level of trust with values of none, simple,
-strong</td>
- </tr>
- <tr>
- <td>
-itemOrUserFirst</td>
- <td>
-Determines order of item permissions or user
-permissions.</td>
- </tr>
- <tr>
- <td>
-userClasses</td>
- <td>
-The set of users the permissions apply
-to.</td>
- </tr>
- <tr>
- <td>
-userPermissions</td>
- <td>
-Permissions on protected
-items</td>
- </tr>
- </table>
- <subsection heading="h2" name="identificationTag">
- <p>
-The identificationTag is just that a tag. It's often used with a subtring
-search filter to lookup a specific ACIItem within an entry. One or more
-ACIItems may be present within a subentry, zero or more in entries, so this
-serves as a means to address the ACIItem within
-entries.</p>
- </subsection>
- <subsection heading="h2" name="precedence">
- <p>
-Precendence is used to determine the ACI to apply when two or more ACIItem's
-applied to an entry conflict. The ACIItem with the highest precedence is
-applied over other conflicting
-ACIItems.</p>
- <table>
- <tr>
- <th>
- <img src="http://docs.safehaus.org/images/icons/emoticons/warning.png"/>
- </th>
- <th>
- <center>Denials Overpower Grants</center>
- </th>
- </tr>
- <tr>
- <td/>
- <td>
- <p>
-When two or more conflicting ACIItems are encountered with the same precedence
-the ACIItems with denials overpower ACIItems with
-grants.</p>
- </td>
- </tr>
- </table>
- <p>
-Right now the use of this field may not mean too much to you. We're dealing
-with a very simple situation with a single access control area. Later as you
-add more subentries their subtreeSpecifications may define collections that
-intersect. When this happens two or more conflicting ACIItems may apply to the
-same entry. Precendence is then applied to determine which permissions
-apply.</p>
- <p>
-Another complex situation requiring precedence is the use of inner areas. These
-nested inner administrative areas overlap and so do their effects. The
-authority within an AA may deny some operation to all entries but grant access
-to subentries of inner areas so minor authorities can control access to inner
-areas. Their grants to users may need to have a higher precedence over denials
-in outer areas. Such situations will arise and precedence will need to be used.
-In this example we just assign an arbitrary value to the
-precedence.</p>
- </subsection>
- <subsection heading="h2" name="authenticationLevel">
- <p>
-The authenticationLevel is the minimum authentication requirement for requestor
-for the ACI to by applied: According to
-X.501:</p>
- <table>
- <tr>
- <th>
- <img src="http://docs.safehaus.org/images/icons/emoticons/information.png"/>
- </th>
- <th>
- <center>18.4.2.3 Authentication Level</center>
- </th>
- </tr>
- <tr>
- <td/>
- <td>
- <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>
- </td>
- </tr>
- </table>
- <p>
-The authenticationLevel can have three values: none, simple and strong. It's
-used to be able to associate permissions with the level of trust in users. For
-none, the identity of the user is anonymous or does not matter. The user can be
-anyone. The simple authenticationLevel means the user has authenticated but is
-using a simple bind with clear text passwords. The strong authenticationLevel
-represents users that bind to the directory using strong authentication
-mechanisms via
-SASL.</p>
- <p>
-SASL can allow annonynous binds as well so there is a distinction here. Using
-SASL alone does not mean the authenticationLevel is strong. As we add SASL
-mechanisms to the server, we'll qualify each one with none, simple or strong.
-This will be reflected in the authenticationLevel property of the principal
-making
-requests.</p>
- </subsection>
- <subsection heading="h2" name="itemOrUserFirst">
- <p>
-This field describes the order of information within the ACI whether protected
-items are described first or user classes and permissions are described first.
-For simplicity we will only describe the userFirst configuration in this
-tutorial.</p>
- </subsection>
- <subsection heading="h2" name="userClasses">
- <p>
-UserClasses is used to list the sets of users to which this permission applies.
-Several mechanisms can be used here to define userClasses. They can be defined
-by name per user, by group membership, or by the superset of all users possible
-and many more. In our example we have applied the ACI to all users that have
-authenticated by simple or strong
-means.</p>
- <p>
-For more information
-see
- <a href="./userclasses.html">UserClasses</a>
-.
- </p>
- </subsection>
- <subsection heading="h2" name="userPermissions">
- <p>
-These are the permissions granted or denied to those users included by the
-userClasses field. The grants or denials however are qualified by the protected
-items operated upon. In our example we grant read, return DN and browse to all
-entries, their attributes and all possible values they may
-have.</p>
- <p>
-For more information
-see
- <a href="./userpermissions.html">UserPermissions</a>
-.
- </p>
- </subsection>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/users/newuser.ldif b/src/site/xdoc/docs/users/newuser.ldif
deleted file mode 100644
index f41b9af..0000000
--- a/src/site/xdoc/docs/users/newuser.ldif
+++ /dev/null
@@ -1,18 +0,0 @@
-dn: uid=jdoe,ou=users,ou=system
-cn: John Doe
-sn: Doe
-givenname: John
-objectclass: top
-objectclass: person
-objectclass: organizationalPerson
-objectclass: inetOrgPerson
-ou: Human Resources
-ou: People
-l: Las Vegas
-uid: jdoe
-mail: jdoe@apachecon.comm
-telephonenumber: +1 408 555 5555
-facsimiletelephonenumber: +1 408 555 5556
-roomnumber: 4613
-userpassword: test
-
diff --git a/src/site/xdoc/docs/users/subentries.xml b/src/site/xdoc/docs/users/subentries.xml
deleted file mode 100644
index 1d1f884..0000000
--- a/src/site/xdoc/docs/users/subentries.xml
+++ /dev/null
@@ -1,514 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
-
- </properties>
- <body>
- <section heading="h2" name="Introduction">
- <p>
-Subentries are used for managing the administration of different aspects of the
-directory. LDAP has just recently formalized the notion of subentires
-in
- <a href="http://www.faqs.org/rfcs/rfc3672.html">RFC 3672</a>
-. Subentries have existed within X.500 Directories for years with clear
-specifications for administering collective attributes, schema, and access
-controls. With the exception of managing collective attributes LDAP has no
-equivalent *yet* for administering these aspects. However with RFC 3672, LDAP
-is on its way towards adopting and adapting these mechanisms from X.500
-Directories. It is only a matter of
-time.
- </p>
- <p>
-For this reason we intend to remain ahead of the curve by implementing these
-aspects of administration using Subentries and Administrative Areas similar to
-X.500
-Directories.</p>
- </section>
- <section heading="h2" name="What exactly are subentries?">
- <p>
-To explain this properly we're going to need to discuss a couple other things
-like administrative areas (AA) and administrative points (AP) within the
-directory. However for the impatient here's a quick attempt to describe what
-subentries
-are:</p>
- <p>
-Subentries are hidden leaf entries (which cannot have children). These entries
-immediately subordinate to an administrative point (AP) within the directory.
-They are used to specify administrative information for a part of the Directory
-Information Tree (DIT). Subentries can contain administrative information for
-aspects of access control, schema administration, and collective attributes (and
-others which have not been defined in any specification
-yet).</p>
- </section>
- <section heading="h2" name="Administrative Areas, Entries and Points">
- <p>
-First some definitions as provided by
-X.501:</p>
- <ul nesting="1">
- <li>
-11.1.1 administrative area: A subtree of the DIT considered from the perspective
-of
-administration.</li>
- <li>
-11.1.2 administrative entry: An entry located at an administrative
-point.</li>
- <li>
-11.1.3 administrative point: The root vertex of an administrative
-area.</li>
- <li>
-11.1.5 autonomous administrative area: A subtree of the DIT whose entries are
-all administered by the same Administrative Authority. Autonomous administrative
-areas are
-non-overlapping.</li>
- <li>
-11.1.11 inner administrative area: A specific administrative area whose scope is
-wholly contained within the scope of another specific administrative area of the
-same
-type.</li>
- <li>
-11.1.17 specific administrative area: A subset (in the form of a subtree) of an
-autonomous administrative area defined for a particular aspect of
-administration: access control, subschema or entry collection administration.
-When defined, specific administrative areas of a particular kind partition an
-autonomous administrative
-area.</li>
- <li>
-11.1.18 specific administrative point: The root vertex of a specific
-administrative
-area.</li>
- </ul>
- <p>
-Now take a step back because the above definitions are, well, from a sleep
-inducing spec. Let's just talk about some
-situations.</p>
- <p>
-Presume you're the uber directory administrator over at WallyWorld (a Walmart
-competitor). Let's say WallyWorld uses their corporate directory for various
-things including their product catalog. As the uber admin you're going to have a
-bunch of people wanting access, update and even administer your directory.
-Entire departments within WallyWorld are going to want to control different
-parts of the directory. Sales may want to manage the product catalog, while
-operations may want to manage information in other areas dealing with suppliers
-and store locations. Whatever the domain some department will need to manage the
-information as the
-authority.</p>
- <p>
-Each department will probably designate different people to manage different
-aspects of their domain. You're not going to want to deal with their little
-fiefdoms instead you can delegate the administration of access control policy to
-a departmental contact. You will want to empower your users and administrative
-contacts in these departments so they can do part of the job for you. Plus it's
-much better than having to communicate with everyone in the company to meet
-their needs. This is where the delegation of authority comes into the
-picture.</p>
- <p>
-Usually administrators do this already to an extent without defining
-administrative areas. Giving users the ability to change their own passwords for
-example is a form of delegation. This is generally a good idea because you don't
-want to set passwords for people. First because you don't want to see the
-password and secondly because of the management nightmare you'd have to deal
-with. Expand this idea out a little further and think about delegating
-administration not of users on their passwords but of entire subtrees in the
-directory to administrative contacts in various
-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
-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 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
-for themselves. These X.500 definitions are there to be able to talk about
-administrative areas within the directory. Now let's get back to what these
-things are
-exactly.</p>
- <p>
-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
-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
-areas.</p>
- </section>
- <section heading="h2" name="How are administrative areas defined?">
- <p>
-Usually an entry is selected as the administrative point and marked with an
-operational attribute. The attributeType of the operational attribute is
-'administrativeRole'. This attribute can have the following
-values:</p>
- <table>
- <tr>
- <th>
-OID</th>
- <th>
-NAME</th>
- </tr>
- <tr>
- <td>
-2.5.23.1</td>
- <td>
-autonomousArea</td>
- </tr>
- <tr>
- <td>
-2.5.23.2</td>
- <td>
-accessControlSpecificArea</td>
- </tr>
- <tr>
- <td>
-2.5.23.3</td>
- <td>
-accessControlInnerArea</td>
- </tr>
- <tr>
- <td>
-2.5.23.4</td>
- <td>
-subschemaAdminSpecificArea</td>
- </tr>
- <tr>
- <td>
-2.5.23.5</td>
- <td>
-collectiveAttributeSpecificArea</td>
- </tr>
- <tr>
- <td>
-2.5.23.6</td>
- <td>
-collectiveAttributeInnerArea</td>
- </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
-likes.</p>
- <p>
-Also notice that two aspects, collective attribute and access controls, allow
-administrative points to be inner areas. Delegated authorities for these two
-aspects can create inner administrative areas to further delegate their
-administrative powers. The schema aspect unlike the others cannot have inner
-areas because of potential conflicts this may cause which would lead to data
-integrity issues. For this reason only the authority of an automomous area can
-manage schema for the entire
-subtree.</p>
- <p>
-An autonomous administrative area (AAA) includes the AP and spans all
-descendants below the AP down to the leaf entries of the subtree with one
-exception. If another AAA, let's call it AAA' (prime) is present and rooted
-below the first AAA then the first AAA does not include the entries of AAA'.
-Translation: an AAA spans down until other AAAs or leaf entries are encountered
-within the subtree. This is due to the fact that AAAs do not overlap as do inner
-AAs
-(IAA).</p>
- </section>
- <section heading="h2" name="Subentries under an IAA or an AAA">
- <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
-subentry's rdn attribute. The subtreeSpecification describes the collection of
-entries within the AA (IAA or AAA) that the administrative instruction applies
-to.</p>
- <p>
-A subtree specification uses various parameters described below to define the
-set of entries. Note that entries need not exist for them to be included in the
-collection on
-addition.</p>
- <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
-above.</p>
- </subsection>
- <subsection heading="h3" name="Chop parameters">
- <p>
-Chop specification parameters define specific nodes to be excluded from the
-collection as well as how deep the subtree spans and even where it starts
-relative to the
-base.</p>
- <subsection heading="h4" name="chopBefore and chopAfter">
- <p>
-These parameters are names relative to the root vertex of the subtree, hence
-they are relative to the base parameter. They specify whether or not an entry
-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
-entry are
-excluded.</p>
- </subsection>
- <subsection heading="h4" name="minimum and maximum">
- <p>
-The minimum parameter describes the minimum DN length required to include
-entries within the selection. The maximum parameter describes the maximum DN
-length allowed before entries are excluded from the
-collection.</p>
- </subsection>
- </subsection>
- <subsection heading="h3" name="Specification filter parameter">
- <p>
-The specification filter is a unique beast. It's a filter like a search filter,
-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>
- <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
-not really a contiguous subtree of entries but a possibly disconnected set of
-selected based on the objectClass characteristics of entries. This feature of a
-subtreeSpecification is very powerful. For example, I can define a subtree to
-cover a region of an AA yet include only inetOrgPersons within this
-region.</p>
- </subsection>
- <subsection heading="h3" name="Subentry types in ApacheDS">
- <p>
-Different subentry objectClasses exist for applying different aspects of
-administration to the entry collection described by their subtreeSpecification
-attribute. By the way the subtreeSpecification attribute is single valued so
-there can only be one in a subentry. However you can have several subentries of
-various kinds under an AP. Furthermore their collections can
-intersect.</p>
- <p>
-The kinds of subentries allowed though are limited by the administrativeRole of
-the AP. If the AP is for an access control AA then you can't add a subentry to
-it for schema administration. The AP must have the role for schema
-administration as well to allow both types of
-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
-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
-up.</p>
- <p>
-ApacheDS does however manage collective attributes using subentries. An AP that
-takes the administrativeRole for managing collective attributes can have
-subentries added. These subentries are described in greater detail
-here:
- <a href="./collective.html">Collective</a>
-. In short, collective attributes added to subentries show up within entries
-included by the subtreeSpecification. Adding, removing, and modifying the values
-of collective attributes within the subentries instantly manifest changes in the
-entries selected by the subtreeSpecification. Again
-consult
- <a href="./collective.html">Collective</a>
-for a hands on explanation of how to use this
-feature.
- </p>
- <p>
-ApacheDS performs access control and allows delegation using subentries, AAAs,
-and IAAs. ApacheDS uses the Basic Access Control Scheme from X.501 to manage
-access control. By default this subsystem is deactivated because it locks down
-everything except access by the admin. More information about hands on use is
-available
-here:
- <a href="./authorization.html">Authorization</a>
-. However to summarize its association with subentries, access control
-information (ACI) can be added to subentries under an AP for access control AAs.
-When one or more ACI are added in this fashion, the access rules of the ACI set
-apply to all entries selected by the subtreeSpecification. Even with this
-powerful feature individual entries can have ACI added to them for controlling
-access to them. Also there are things you can do with ACI added to subentries
-that cannot be done with entry level ACI. For example you cannot allow entry
-addition with entry ACI. You must use subtreeSpecifications to define where
-entries may be added because those entries and their parents may not exist
-yet.
- </p>
- </subsection>
- <subsection heading="h3" name="How to specify a subentry's subtreeSpecification">
- <p>
-The best way to demonstrate subtreeSpecification values are through examples.
-Here's the simplest filter of them
-all:</p>
- <source>{}
-</source>
- <p>
-This basically selects the entire contiguous subtree below the AP. The base is
-the empty name and it's rooted at the
-AP.</p>
- <p>
-Next step let's add a
-base:</p>
- <source>{ base "ou=users" }
-</source>
- <p>
-If this is the subtreeSpecification under the AP, *'ou=system'*, then it selects
-every entry under
-*'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
-parameters.</p>
- <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
-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
-not.</p>
- <p>
-It's time to add some chop
-exclusions:</p>
- <source>{
- base "ou=users",
- minimum 4,
- specificExclusions { chopBefore: "ou=untrusted" }
-}
-</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
-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
-the excluded DN,
-*'ou=untrusted,ou=users,ou=system'*.</p>
- <p>
-Note that you can add as many exclusions as you like by comma delimiting them.
-For
-example:</p>
- <source>{
- base "ou=users",
- minimum 4,
- specificExclusions { chopBefore: "ou=untrusted", chopAfter: "ou=ugly", chopBefore: "ou=bad" }
-}
-</source>
- <p>
-The final example includes a refinement. Again any combination of chop, filter
-and base parameters can be used. The following refinement makes sure the users
-selected are of the objectClass inetOrgPerson and specialUser where the OID for
-the specialUser class is 32.5.2.1
-(fictitious).</p>
- <source>{
- base "ou=users",
- minimum 4,
- specificExclusions { chopBefore: "ou=untrusted", chopAfter: "ou=ugly", chopBefore: "ou=bad" }
- specificationFilter and:{ item:32.5.2.1, item:inetOrgPerson }
-}
-</source>
- <p>
-If you'd like to see the whole specification of the grammar used for the
-subtreeSpecification take a look at Appendix A
-in
- <a href="http://www.faqs.org/rfcs/rfc3672.html">RFC 3672</a>
-.
- </p>
- </subsection>
- </section>
- <section heading="h2" name="Future Possibilities">
- <p>
-In the immediate future we intend to
-introduce
- <a href="./triggers.html">Triggers</a>
-, stored procedures and views into ApacheDS. Subentries will play a critical
-role in the administration and application of these features. For example a
-Trigger specification need not include information on what entries it applies to
-since the subtreeSpecification handles this. The question of "on what" a trigger
-applies to is nicely disassociated from the "which operation" part of the
-specification. This makes for much better reuse of triggers. It also allows for
-the pin point application of triggers to entries in the DIT. Likewise a view
-itself will be defined by a specification. A view for example in a subentry can
-define a region of the tree that does not exist but is shadowed from another
-region all together. The possibilities here are
-limitless.
- </p>
- <p>
-Of course we will revamp the schema subsystem of ApacheDS to use subentries in
-AAA to manage the schema in effect within different regions of the DIT. Today
-most LDAP servers just have a global scheme in effect for the entire DIT served
-by a DSA. We don't think that is reasonable at all. So expect some serious
-advances in the design of a new schema subsystem based on
-subentries.</p>
- <p>
-Replication is yet another excellent candidate for using subentries. Replication
-of specific collections of entries can be managed for each cluster rather than
-replicating the entire DIT served by a DSA to replicas. This way we don't only
-control what is replicated but we can also control how and where it is
-replicated.</p>
- </section>
- <section heading="h2" name="Conclusions">
- <p>
-ApacheDS has implemented subentries for the administration of various aspects of
-the directory and gains several powerful features as a result: namely precision
-application of control to entry collections and the ability to delegate
-administrative authority. For details on the administration of each aspect using
-subentries
-(
- <a href="./collective.html">Collective</a>
-and
- <a href="./authorization.html">Authorization</a>
-) please see the respective
-documentation.
- </p>
- <p>
-As ApacheDS progresses it will gain an immense advantage from subentries. Both
-for existing LDAP features like scheme and for new experimental features like
-triggers, and
-replication.</p>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/users/subtreespecificationgrammar.xml b/src/site/xdoc/docs/users/subtreespecificationgrammar.xml
deleted file mode 100644
index d74a2ee..0000000
--- a/src/site/xdoc/docs/users/subtreespecificationgrammar.xml
+++ /dev/null
@@ -1,54 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="elecharny">elecharny</author>
-
- </properties>
- <body>
- <section heading="h1" name="Subtree Specification LL(1) Grammar">
- <p>
-Here is the LL(1) grammar used to decode a subtreeSpecification as described
-by
- <a href="http://www.faqs.org/rfcs/rfc3672.html">RFC 3672</a>
- </p>
- <source><SubtreeSpecification> ::= '{' <spse> <base-e> <chopSpecification> <spse> <refinement-e> '}'
-
-<base-e> ::=
- «base» <sps> <localName> <spse> ',' <spse> |
- e
-
-<chopSpecification> ::= «chopSpecification» '{' <spse> <chopSpecification-in> '}'
-
-<chopSpecification-in> ::=
- «specificExclusions» <spse> <chop-set-of-choice> <spse> <specificExclusions-follower> |
- «minimum» <sps> <number> <spse> <minimum-follower> |
- «maximum» <sps> <number> <spse>
-
-<specificExclusions-follower> ::=
- ',' <spse> «minimum» <sps> <number> <spse> <minimum-follower> |
- ',' <spse> «maximum» <sps> <number> <spse>
-
-<minimum-follower> ::= ',' <spse> «maximum» <sps> <number> <spse>
-
-<refinement-e> ::=
- «specificationFilter» <sps> <refinement> |
- e
-
-<refinement> ::=
- «item» <spse> ':' <spse> OID <spse> |
- «and» <spse> ':' <spse> <set-of-refinement> |
- «or» <spse> ':' <spse> <set-of-refinement> |
- «not» <spse> ':' <spse> <refinement> |
-
-<set-of-refinement> ::= '{' <spse> <refinement> <refinements> '}' <spse>
-
-<refinements> ::=
- ',' <spse> <refinement> |
- e
-
-<localName> ::= '"' DN '"'
-</source>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/docs/users/userclasses.xml b/src/site/xdoc/docs/users/userclasses.xml
deleted file mode 100644
index 5f0ad59..0000000
--- a/src/site/xdoc/docs/users/userclasses.xml
+++ /dev/null
@@ -1,166 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-
-<document>
- <properties>
- <author email="akarasulu">akarasulu</author>
-
- </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 with possible requirements 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 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>
- <table>
- <tr>
- <td>
- <img src="http://docs.safehaus.org/images/icons/emoticons/warning.png"/>
- </td>
- <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>
- </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 specification 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
-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>
- <td>
- <img src="http://docs.safehaus.org/images/icons/emoticons/warning.png"/>
- </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
-determination to just the DN of the requestor and not the entry of the
-requestor.</p>
- </td>
- </tr>
- </table>
- </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 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 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>
diff --git a/src/site/xdoc/features.xml b/src/site/xdoc/features.xml
deleted file mode 100644
index 449016d..0000000
--- a/src/site/xdoc/features.xml
+++ /dev/null
@@ -1,84 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Features</title>
- </properties>
-
- <body>
- <section name="Server's Features">
- <p>
- The Apache Directory Server is an embeddable LDAP server implemented in
- pure Java. It has several features that make it unique amoung LDAP
- servers. These features are described below:
- </p>
-
- <ul>
- <li>
- Designed as an LDAP and X.500 experimentation platform. Plugable
- components and subsystems make ApacheDS extremely modular and ideal
- for experiments with various aspects of the LDAP protocol.
- </li>
-
- <li>
- The server's frontend is completely separable from its backend and
- vice-versa making it very flexible for implementing virtual
- directories, proxy servers and gateways to X.500.
- </li>
-
- <li>
- Several backends can be implemented and plugged into the server's
- partition nexus. The server supports a BTree based partition out of
- the box but any backing store can be used to implement a partition so
- long as it conforms to interfaces.
- </li>
-
- <li>
- The server exposes aspects of administration via a special system
- backend. LDAP can be used to manage these concerns through the
- system naming context at <code>ou=system</code>.
- </li>
-
- <li>
- Java based triggers and stored procedures are being implemented.
- </li>
-
- <li>
- Both the backend subsystem and the frontend are separable and
- independently embeddable.
- </li>
-
- <li>
- The server contains a server side JNDI LDAP provider as the facade
- for the entire backend subsystem. JNDI operations are directly
- translated by this provider into operations against the nexus and the
- target partitions storing server entries.
- </li>
-
- <li>
- The server will use JNDI as the data access API for stored procedures.
- This will make stored procedures functional within and outside of the
- server without requiring recompilation.
- </li>
-
- <li>
- The server's networking code, MINA, Multipurpose Infrastructure for
- Network Applications was designed for pluggable protocol providers,
- of all sorts and not just LDAP. MINA gives ApacheDS the ability to
- handle large amounts of concurrency.
- </li>
-
- <li>
- The server uses the Snickers tools and APIs for ASN.1 BER encoding and
- decoding. These tools are designed for a very small encoding and
- decoding footprint as well as for use in non-blocking servers. The
- chunking nature of the BER codec makes the server very efficient while
- handling encoding and decoding making it more resistant to DoS
- attacks. This layer is also pluggable with a new experimental Twix
- provider which is much more efficient. Of course there is the
- unsupported Snacc4J provider which is no longer maintained.
- </li>
- </ul>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/index.xml b/src/site/xdoc/index.xml
deleted file mode 100644
index da4e0c3..0000000
--- a/src/site/xdoc/index.xml
+++ /dev/null
@@ -1,72 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <title>Overview</title>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- </properties>
-
- <body>
- <section name="Overview">
- <p>Welcome to the Apache Directory Server Homepage!</p>
-
- <p>
- The Apache Directory Server is an embeddable LDAP server written in
- Java. It has been designed to introduce triggers, stored procedures,
- queues and views to the world of LDAP which has lacked these rich
- constructs.
- </p>
-
- <table>
- <tr>
- <th>Topic</th>
- <th>Description</th>
- </tr>
-
- <tr>
- <td>
- <a href="./features.html">Features</a>
- </td>
- <td>
- Lists existing and planned features.
- </td>
- </tr>
-
- <tr>
- <td>
- <a href="./roadmap.html">Roadmap</a>
- </td>
- <td>
- A development roadmap.
- </td>
- </tr>
-
- <tr>
- <td>
- <a href="./docs/users/index.html">User's Guide</a>
- </td>
- <td>
- Material that might go into a user's guide or howto section.
- </td>
- </tr>
-
- <tr>
- <td>
- <a href="./docs/developers/index.html">Developers's Guide</a>
- </td>
- <td>
- Material that might go into a developer's guide.
- </td>
- </tr>
-
- </table>
-
- <p>
- Here is a figure for the architectural overview of ApacheDS. Click on it to see further details.
- </p>
- <p>
- <a href="./modules.html"><img src="images/50k-ft-architecture.png" href="./modules.html"/></a>
- </p>
-
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/modules.xml b/src/site/xdoc/modules.xml
deleted file mode 100644
index feed927..0000000
--- a/src/site/xdoc/modules.xml
+++ /dev/null
@@ -1,32 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <title>ApacheDS Modules</title>
- </properties>
- <body>
- <section name="ApacheDS Modules">
- <p>ApacheDS is composed of several modules. Here is the list of them with brief descriptions:</p>
- <table>
- <tr><th>Name</th><th>Description</th></tr>
- <tr> <td>ApacheDS Core</td> <td>Server's core contains the JNDI provider, interceptors, schema, and database subsystems. The core is the heart of the server without protocols enabled. </td> </tr>
- <tr> <td>ApacheDS Core Plugin (Maven 2)</td> <td>A collection of tools as plugins to manage various tasks associated with the directory server. </td> </tr>
- <tr> <td>ApacheDS Core Shared</td> <td>Shared classes between the core plugin and the core to prevent cyclic dependencies since the core uses the core plugin. </td> </tr>
- <tr> <td>ApacheDS Core Unit</td> <td>To be described...</td> </tr>
- <tr> <td>ApacheDS Protocol Kerberos Shared</td> <td>The Kerberos protocol provider for ApacheDS </td> </tr>
- <tr> <td>ApacheDS Protocol Change Password</td> <td>The Change Password protocol provider for ApacheDS </td> </tr>
- <tr> <td>ApacheDS Protocol Dhcp</td> <td>The DHCP protocol provider for ApacheDS </td> </tr>
- <tr> <td>ApacheDS Protocol Dns</td> <td>The DNS protocol provider for ApacheDS </td> </tr>
- <tr> <td>ApacheDS Protocol Kerberos</td> <td>The Kerberos Protocol Provider for ApacheDS </td> </tr>
- <tr> <td>ApacheDS Protocol Ldap</td> <td>The LDAPv3 protocol provider for ApacheDS </td> </tr>
- <tr> <td>ApacheDS Protocol Ntp</td> <td>The NTP protocol provider for ApacheDS </td> </tr>
- <tr> <td>ApacheDS Protocol Shared</td> <td>Shared library that is used by all protocol providers in ApacheDS </td> </tr>
- <tr> <td>ApacheDS Server JNDI</td> <td>The JNDI provider which launches the core and associated network services: Changepw, Kerberos, LDAP, and NTP if all are configured. By default only LDAP is configured to startup. </td> </tr>
- <tr> <td>ApacheDS Server Main</td> <td>To be described...</td> </tr>
- <tr> <td>ApacheDS Server Sar (JBoss 3.x)</td> <td>A server archive file for ApacheDS to run within a JBoss 3.x instance </td> </tr>
- <tr> <td>ApacheDS Server SSL</td> <td>An SSL support module for LDAPS with ApacheDS </td> </tr>
- <tr> <td>ApacheDS Server Tools</td> <td>Contained within this executable jar are various commandline utilities for apacheds. </td> </tr>
- <tr> <td>ApacheDS Server Unit</td> <td>Unit testing framework for ApacheDS Server JNDI Provider </td> </tr>
- </table>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/notices.xml b/src/site/xdoc/notices.xml
deleted file mode 100644
index 9507e54..0000000
--- a/src/site/xdoc/notices.xml
+++ /dev/null
@@ -1,18 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
-
- </properties>
-
- <body>
- <section name="Notices">
- <subsection name="Apache General Notice">
- <source>
-This product includes software developed by
-The Apache Software Foundation (http://www.apache.org/).
- </source>
- </subsection>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/releases.xml b/src/site/xdoc/releases.xml
deleted file mode 100644
index 2b80cb6..0000000
--- a/src/site/xdoc/releases.xml
+++ /dev/null
@@ -1,29 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <title>ApacheDS Releases</title>
- </properties>
- <body>
- <section name="ApacheDS 1.0">
- <p>
- Apache Directory Project is proud to announce the first public
- release of Apache Directory Server, ApacheDS 1.0 which has been
- <a href="http://www.opengroup.org/openbrand/register/brand3527.htm">
- certified by the Open Group</a> as the first LDAPv3 compliant Open Source
- LDAP Server!
- </p>
- <p>
- Installers for various platforms are available.
- <table>
- <tr> <td> <a href="http://www.apache.org/dyn/closer.cgi/directory/apacheds/stable/1.0/1.0.0/apacheds-1.0.0-linux-i386.rpm">Linux (RPM/Native - i386)</a> </td> </tr>
- <tr> <td> <a href="http://www.apache.org/dyn/closer.cgi/directory/apacheds/stable/1.0/1.0.0/apacheds_1.0.0-1_i386.deb">Linux (DEB/Native - i386)</a> </td> </tr>
- <tr> <td> <a href="http://www.apache.org/dyn/closer.cgi/directory/apacheds/stable/1.0/1.0.0/apacheds-1.0.0-linux-i386-setup.jar">Linux (IzPack/Java - i386)</a> </td> </tr>
- <tr> <td> <a href="http://www.apache.org/dyn/closer.cgi/directory/apacheds/stable/1.0/1.0.0/apacheds-1.0.0-solaris-i386-setup.jar">Solaris (IzPack/Java - i386)</a> </td> </tr>
- <tr> <td> <a href="http://www.apache.org/dyn/closer.cgi/directory/apacheds/stable/1.0/1.0.0/apacheds-1.0.0-solaris-sparc-setup.jar">Solaris (IzPack/Java - SPARC)</a> </td> </tr>
- <tr> <td> <a href="http://www.apache.org/dyn/closer.cgi/directory/apacheds/stable/1.0/1.0.0/apacheds-1.0.0-macosx-ppc-setup.jar">MacOSX (IzPack/Java - PPC)</a> </td> </tr>
- <tr> <td> <a href="http://www.apache.org/dyn/closer.cgi/directory/apacheds/stable/1.0/1.0.0/apacheds-1.0.0-win32-setup.exe">Windows (Inno/Native - i386)</a> </td> </tr>
- </table>
- </p>
- </section>
- </body>
-</document>
diff --git a/src/site/xdoc/roadmap.xml b/src/site/xdoc/roadmap.xml
deleted file mode 100644
index 3851239..0000000
--- a/src/site/xdoc/roadmap.xml
+++ /dev/null
@@ -1,30 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<document>
- <properties>
- <author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>ApacheDS - Roadmap</title>
- </properties>
-
- <body>
- <section name="Server Roadmap">
- <p>
- Until we pull this together in a nice format you can get an
- idea of what is going on using these alternative sources of info:
- </p>
-
- <ul>
- <li>
- Look at the JIRA
- <a href="http://issues.apache.org/jira/secure/BrowseProject.jspa">here
- </a> for specific tasks.
- </li>
- <li>
- Look at the release info in the WIKI
- <a href="http://wiki.apache.org/directory/ReleasesHowto">here
- </a> for high level roadmap.
- </li>
- </ul>
- </section>
-
- </body>
-</document>
