You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ak...@apache.org on 2005/10/25 21:28:02 UTC
svn commit: r328459 - in /directory/apacheds/trunk/xdocs: ./ projects/ users/
Author: akarasulu
Date: Tue Oct 25 12:27:53 2005
New Revision: 328459
URL: http://svn.apache.org/viewcvs?rev=328459&view=rev
Log:
changes ...
o made corrections to existing doco so its inline with changes
o added some extra doco which has yet to be completed and integrated into the
user guide on the following topics:
- authorization: for X.501 basic access control scheme
- subentries: RFC 3671 implementation
- collective attributes: RFC 3672 implementation
- configuration: for changes to the configuration mechanism
Added:
directory/apacheds/trunk/xdocs/users/authorization.xml
- copied, changed from r328262, directory/apacheds/trunk/xdocs/users/authentication.xml
directory/apacheds/trunk/xdocs/users/collective.xml
directory/apacheds/trunk/xdocs/users/configuration.xml
- copied, changed from r328262, directory/apacheds/trunk/xdocs/users/jndi.xml
directory/apacheds/trunk/xdocs/users/subentries.xml
Removed:
directory/apacheds/trunk/xdocs/users/jndi.xml
Modified:
directory/apacheds/trunk/xdocs/features.xml
directory/apacheds/trunk/xdocs/projects/index.xml
directory/apacheds/trunk/xdocs/roadmap.xml
directory/apacheds/trunk/xdocs/users/authentication.xml
directory/apacheds/trunk/xdocs/users/building.xml
directory/apacheds/trunk/xdocs/users/index.xml
directory/apacheds/trunk/xdocs/users/partitions.xml
Modified: directory/apacheds/trunk/xdocs/features.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/features.xml?rev=328459&r1=328458&r2=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/features.xml (original)
+++ directory/apacheds/trunk/xdocs/features.xml Tue Oct 25 12:27:53 2005
@@ -16,10 +16,8 @@
<ul>
<li>
Designed as an LDAP and X.500 experimentation platform. Plugable
- components and subsystems make Eve extremely modular and perfect for
- experiments with various aspects of the LDAP protocol. The server
- may be made to can run on any IoC based microkernel using IoC type
- wrappers for POJO components implementing POJI services.
+ components and subsystems make ApacheDS extremely modular and ideal
+ for experiments with various aspects of the LDAP protocol.
</li>
<li>
@@ -36,7 +34,7 @@
</li>
<li>
- The server exposes all aspects of administration via a special system
+ 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>
@@ -64,10 +62,10 @@
</li>
<li>
- The server's networking code is based on a simple Staged Event Driven
- Architecture (SEDA) which gives it the ability to handle large
- amounts of concurrency. Multiple swapable network layers will be
- available for different usage characteristics.
+ 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>
@@ -76,9 +74,11 @@
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.
+ 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>
\ No newline at end of file
+</document>
Modified: directory/apacheds/trunk/xdocs/projects/index.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/projects/index.xml?rev=328459&r1=328458&r2=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/projects/index.xml (original)
+++ directory/apacheds/trunk/xdocs/projects/index.xml Tue Oct 25 12:27:53 2005
@@ -32,9 +32,7 @@
<a href="../projects/apacheds-core/index.html">core</a>
</td>
<td>
- The server's core contains all of it's backend subsystems. The
- core depends on the protocol and uses it with seda to service LDAP
- requests. The core contains the JNDI provider, interceptor
+ The core contains the JNDI provider, interceptor
framework, interceptor services, the schema subsystem and the
database subsystem. Hence the core is the heart of the server as
its name suggests.
@@ -55,7 +53,9 @@
<a href="../projects/maven-directory-plugin/index.html">plugin</a>
</td>
<td>
- The server's Maven Plugin
+ A Maven Plugin used to generate code from OpenLDAP schema files.
+ These files are parsed and source is generated to bootstrap schema
+ in the server.
</td>
</tr>
</table>
Modified: directory/apacheds/trunk/xdocs/roadmap.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/roadmap.xml?rev=328459&r1=328458&r2=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/roadmap.xml (original)
+++ directory/apacheds/trunk/xdocs/roadmap.xml Tue Oct 25 12:27:53 2005
@@ -8,7 +8,7 @@
<body>
<section name="Server Roadmap">
<p>
- Until we pull this together over here in a nice format you can get an
+ 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>
Modified: directory/apacheds/trunk/xdocs/users/authentication.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/authentication.xml?rev=328459&r1=328458&r2=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/authentication.xml (original)
+++ directory/apacheds/trunk/xdocs/users/authentication.xml Tue Oct 25 12:27:53 2005
@@ -51,7 +51,10 @@
<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.
+ server without any username or password. NOTE: 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.
</p>
</subsection>
@@ -62,7 +65,7 @@
within one of the directory partitions. So if you add a partition to
hang off of <code>dc=example,dc=com</code> then you can add user
entries anywhere under this naming context or just add user entries
- under the <code>ou=system</code> naming context. Above is an LDIF of
+ under the <code>ou=system</code> naming context. Below is an LDIF of
a user you can add to the directory as a test user.
</p>
@@ -125,21 +128,30 @@
<p>
At the moment there's a sweet spot for new users. This sweet
spot is immediately under the ou=users,ou=system context. Users
- created here are hard protected right now. The server does not have
- a formal authorization mechanism in place yet to protect entries from
- other users. Authorization rules have been hardcoded into the system
- for now to control access to user entries under <code>ou=users,
- ou=system</code>. Only the admin and the user him/her self can
- access their entries for reads. Users cannot modify their group
- membership properties but can change their own passwords. They do
- not see each other's accounts at all. The admin is the only one that
- can read and write anything.
+ created here are hard protected right now. As of 0.9.3 an
+ implementation of X.501 basic access controls are available however
+ the system is not turned on by default. Turning it on presumes
+ access is denied to all but the admin. More information on this is
+ available in the access control page. When the access control
+ subsystem is not activated hardcoded minimal access controls are
+ used to protect the admin account, users and groups under respective
+ containers in the ou=system partition.
+ </p>
+ <p>
+ In the absense of the ACI subsystem, authorization rules have been
+ hardcoded into the system to control access to user entries under
+ <code>ou=users,ou=system</code>. Only the admin and the user
+ him/her self can access their entries for reads. Users cannot
+ modify their group membership properties but can change their own
+ passwords. They do not see each other's accounts at all. The admin
+ is the only one that can read and write anything.
</p>
<p>
So in the interim you're best off adding your users to this area to
- prevent others from reading clear text password stored in userPassword
- fields.
+ prevent others from reading clear text passwords stored in
+ userPassword fields. If using a release with hashed passwords we
+ highly discourage the use of clear text passwords.
</p>
<p>
@@ -156,21 +168,21 @@
<subsection name="Disabling Anonymous Binds">
<p>
Anonymous binds come enabled out of the box. So you might want to
- turn off this feature especially since you cannot protect much of
- your data at the present moment from access using authorization rules.
+ 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 while disallowing
- these binds. The <b>server.disable.anonymous</b> property when
- present as a key in the enviroment (regardless of value) will disable
- access by anonymous users. This applies to authentication via LDAP
- clients over the wire and via JNDI caller through the JNDI provider.
+ these binds. In the server.xml that comes with the distribution
+ take a look at the <b>allowAnonymousAccess</b> property for the
+ server startup configuration.
</p>
</subsection>
<subsection name="Custom Authenticator">
<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:
+ 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>
@@ -207,38 +219,45 @@
</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" ).
+ 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.
+ 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.
+ 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.
+ 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 JNDI
- Properties. You can also optionally specify the location of a .properties file containing
- the initialization parameters. See the following example:
+ 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
Copied: directory/apacheds/trunk/xdocs/users/authorization.xml (from r328262, directory/apacheds/trunk/xdocs/users/authentication.xml)
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/authorization.xml?p2=directory/apacheds/trunk/xdocs/users/authorization.xml&p1=directory/apacheds/trunk/xdocs/users/authentication.xml&r1=328262&r2=328459&rev=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/authentication.xml (original)
+++ directory/apacheds/trunk/xdocs/users/authorization.xml Tue Oct 25 12:27:53 2005
@@ -2,252 +2,33 @@
<document>
<properties>
<author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>Server Authentication</title>
+ <title>Access Controls</title>
</properties>
<body>
- <section name="Server Authentication">
+ <section name="Access Control">
<subsection 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 name="What password do I use?">
+ <subsection name="Default Settings">
<p>
- So you just downloaded the server and fired her up. Now you're
- wondering how to get an LDAP client like jxplorer, gq, or ldapbrowser
- to bind to the server over the wire.
- </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 <b>secret</b>. You might want to
- change this after starting the server. So you can bind to the server
- as this user with <b>secret</b> as the password for the first time.
- </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>
</subsection>
- <subsection name="Adding and authenticating normal users">
- <p>
- A user in the server is 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 <code>dc=example,dc=com</code> then you can add user
- entries anywhere under this naming context or just add user entries
- under the <code>ou=system</code> naming context. Above 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>
-
+ <subsection name="X.501 Basic Access Controls">
<p>
- You can download this <a href="newuser.ldif">newuser.ldif</a> file and
- use it to add the user. If you are lazy another test user, <code>
- uid=akarasulu, ou=users, ou=system</code> already exists within the
- directory. It is created by default. Simply replace jdoe's DN with
- akarasulu's DN to search for this user and bind as this 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 name="Protecting User Passwords">
- <p>
- At the moment there's a sweet spot for new users. This sweet
- spot is immediately under the ou=users,ou=system context. Users
- created here are hard protected right now. The server does not have
- a formal authorization mechanism in place yet to protect entries from
- other users. Authorization rules have been hardcoded into the system
- for now to control access to user entries under <code>ou=users,
- ou=system</code>. Only the admin and the user him/her self can
- access their entries for reads. Users cannot modify their group
- membership properties but can change their own passwords. They do
- not see each other's accounts at all. The admin is the only one that
- can read and write anything.
- </p>
-
+ <subsection name="ACI Examples">
<p>
- So in the interim you're best off adding your users to this area to
- prevent others from reading clear text password stored in userPassword
- fields.
</p>
-
- <p>
- Note that anonymous binds and binds as users show different
- views of the ou=system naming context. So don't freak out if you
- don't see the usual suspects when binding anonymously! Anonymous
- users cannot see the admin account or any other user accounts. Users
- other than admin cannot see the admin account and can only see one
- user account: their own. The admin sees everything and can alter or
- remove any entry.
- </p>
- </subsection>
-
- <subsection name="Disabling Anonymous Binds">
- <p>
- Anonymous binds come enabled out of the box. So you might want to
- turn off this feature especially since you cannot protect much of
- your data at the present moment from access using authorization rules.
- To do so you're going to have to restart the server while disallowing
- these binds. The <b>server.disable.anonymous</b> property when
- present as a key in the enviroment (regardless of value) will disable
- access by anonymous users. This applies to authentication via LDAP
- clients over the wire and via JNDI caller through the JNDI provider.
- </p>
- </subsection>
-
- <subsection name="Custom Authenticator">
- <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 JNDI
- Properties. You can also optionally specify the location of a .properties file containing
- the initialization parameters. See the following example:
- </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>
Modified: directory/apacheds/trunk/xdocs/users/building.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/building.xml?rev=328459&r1=328458&r2=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/building.xml (original)
+++ directory/apacheds/trunk/xdocs/users/building.xml Tue Oct 25 12:27:53 2005
@@ -30,27 +30,22 @@
</p>
<source>
-[akarasulu@newton trunk]$ java -jar main/target/apacheds-main-0.8.0-SNAPSHOT.jar
-server: using default properties ...
-server: standard ldap port 389 is not available, using 1024 instead
-server: started in 1368 milliseconds
+java -jar main/target/apacheds-main-${version}.jar server.xml
</source>
<p>
- When you start the server without a properties file arguement default
+ When you start the server without a xml conf file arguement default
settings are used. It tries to bind to 389 but this non-root user
does not have the needed privledges so it tries to bind on the next
- available port which is 1024. If you would like a properties file can
+ available port which is 1024. You may like a conf file that can
be used to override and set server specific properties to control her
- behavoir. Below we use the <a href="http://vortuoad.notlong.com/">
- properties</a> file that comes preconfigured for Apache under the
- server/trunk/main directory:
+ 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>
-[akarasulu@newton trunk]$ java -jar main/target/apacheds-main-0.8.0-SNAPSHOT.jar main/server.properties
-server: loading properties from main/eve.properties
-server: started in 1449 milliseconds
+java -jar main/target/apacheds-main-${version}.jar main/server.xml
</source>
</section>
@@ -86,15 +81,17 @@
<td>Contains shared classes between modules to prevent cyclic deps.</td>
</tr>
<tr>
- <td>optional</td>
+ <td>main</td>
<td>
- We might create this project in the near future to contain bundles
- of optional schema jars. The server's maven plugin generates Java
- class files for OpenLDAP schema files. These classes create schema
- objects way faster than parsing a file to dynamically create schema
- objects. The optional package will contain all the schema classes
- for published schemas we can find. When firing up the server you
- can request to load only those schemas you actually use.
+ Contains the ApacheDS application <code>main()</code> along with
+ a special InitialContextFactory implemenation that extends the
+ CoreContextFactory 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>
Added: directory/apacheds/trunk/xdocs/users/collective.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/collective.xml?rev=328459&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/users/collective.xml (added)
+++ directory/apacheds/trunk/xdocs/users/collective.xml Tue Oct 25 12:27:53 2005
@@ -0,0 +1,33 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>Collective Attributes</title>
+ </properties>
+
+ <body>
+
+ <section name="Collective Attributes">
+ <subsection name="What are collective attributes?">
+ <p>
+ </p>
+ </subsection>
+
+ <subsection name="Collective Attribute Administrative Areas">
+ <p>
+ </p>
+ </subsection>
+
+ <subsection name="How ApacheDS Handles Collective Attributes">
+ <p>
+ </p>
+ </subsection>
+
+ <subsection name="Examples">
+ <p>
+ </p>
+ </subsection>
+
+ </section>
+ </body>
+</document>
Copied: directory/apacheds/trunk/xdocs/users/configuration.xml (from r328262, directory/apacheds/trunk/xdocs/users/jndi.xml)
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/configuration.xml?p2=directory/apacheds/trunk/xdocs/users/configuration.xml&p1=directory/apacheds/trunk/xdocs/users/jndi.xml&r1=328262&r2=328459&rev=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/jndi.xml (original)
+++ directory/apacheds/trunk/xdocs/users/configuration.xml Tue Oct 25 12:27:53 2005
@@ -2,7 +2,7 @@
<document>
<properties>
<author email="akarasulu@apache.org">Alex Karasulu</author>
- <title>Server-Side JNDI Provider</title>
+ <title>Server Configuration and its JNDI Provider</title>
</properties>
<body>
@@ -21,193 +21,26 @@
First stored procedures written in Java will naturally use JNDI to
alter entries using this provider. Thanks to JNDI the same procedure
outside of the server can be tested using the SUN JNDI LDAP provider.
- This transparency is wicked cool since it makes testing easy. The
+ This transparency is neat since it makes testing easy. The
server side JNDI provider is also used as the API of choice for
integrating the server into other Java applications and servers. The
first InitialContext request to the server side provider fires up the
entire server. So you need not learn anything new to start using and
- embedding the Apache Directory Server!
+ embedding the Apache Directory Server! Well perhaps you need to know
+ about a few configuration interfaces that are added to the JNDI
+ environment via a provider specific JNDI property. This however is
+ very easy to do as you will soon see.
</p>
<p>
This document describes the server side JNDI Provider in terms of the
custom properties used to control its behavoir in the solid state and
- for configuring the server on start up.
+ for configuring the server on start up. It also describes the
+ configuration beans used by the server.
</p>
</section>
<section name="Server Specific JNDI Properties">
- <table>
- <tr><th>key</th><th>optional</th><th>description</th></tr>
- <tr>
- <td>server.wkdir</td>
- <td>true</td>
- <td>
- The file system folder the server will use to store database files
- and other things. You can set server.wkdir to an absolute path
- or to a relative path like so:
-<source>
-server.wkdir=/opt/apacheds/work
-server.wkdir=tmp/work
-</source>
- </td>
- </tr>
-
- <tr>
- <td>server.schemas</td>
- <td>true</td>
- <td>
- The schema configuration settings. A space separated list of fully
- qualified class names. These classes must extend AbstractBootstrapSchema
- in the <code>org.apache.ldap.server.schema.bootstrap</code> package.
- Here's an example:
-<source>
-server.schemas = org.apache.ldap.server.schema.bootstrap.SystemSchema
- org.apache.ldap.server.schema.bootstrap.ApacheSchema
- org.apache.ldap.server.schema.bootstrap.CoreSchema
- org.apache.ldap.server.schema.bootstrap.CosineSchema
- org.apache.ldap.server.schema.bootstrap.InetorgpersonSchema
- org.apache.ldap.server.schema.bootstrap.Krb5kdcSchema
-</source>
- </td>
- </tr>
-
- <tr>
- <td>server.disable.anonymous</td>
- <td>true</td>
- <td>
- If present at all this key disables anonymous binds. The value of
- the property is disregarded. By default anonymous binds are allowed.
- </td>
- </tr>
-
- <tr>
- <td>server.operation.sync</td>
- <td>true</td>
- <td>
- If present when requesting an InitialContext this property forces
- all partitions to sync their buffers to disk if their implementation
- contains a cache. The value of the property is disregarded.
- </td>
- </tr>
-
- <tr>
- <td>server.operation.shutdown</td>
- <td>true</td>
- <td>
- If present when requesting an InitialContext this property gracefully
- shuts down the server. The returned context is a useless DeadContext
- which throws exceptions when used. The value of the property is
- disregarded.
- </td>
- </tr>
-
- <tr>
- <td>server.net.disable.protocol</td>
- <td>true</td>
- <td>
- Used when starting up the server to disable the networking frontend that
- handles LDAP protocol requests. The value of the property is disregarded.
- By default the LDAP protocol is enabled.
- </td>
- </tr>
-
- <tr>
- <td>server.net.passthru</td>
- <td>true</td>
- <td>
- Used to pass an existing network frontend to the server rather
- than having the server create its own instance. The value of
- this property is a MINA ServiceRegistry instance.
- </td>
- </tr>
-
- <tr>
- <td>server.net.ldap.port</td>
- <td>true</td>
- <td>
- The LDAP port to use for servicing LDAP protocol requests if not
- on the standard port: 389.
- </td>
- </tr>
-
- <tr>
- <td>server.net.ldaps.port</td>
- <td>true</td>
- <td>
- <b>WARNING</b>: ONLY FOR JDK 1.5 AND HIGHER. Optionally specifies the
- LDAP port to use for servicing secure LDAP protocol requests. Secure
- LDAP port 636 is usually used.
- </td>
- </tr>
-
- <tr>
- <td>server.db.partitions</td>
- <td>true</td>
- <td>
- The list of database partition identifiers. If this is not specified
- the only partition in the server is the system partition hanging off
- of the ou=system context. The value is a space separated list of
- partition names like 'apache example xyz123'.
- </td>
- </tr>
-
- <tr>
- <td>server.db.partition.suffix.</td>
- <td>maybe</td>
- <td>
- A key base for listing the suffixes of database partitions. The
- identifier for the partition in the property above is appended to
- this base to form the key for the suffix of that partition. Here
- are some examples:
-<source>
-server.db.partition.suffix.apache=dc=apache,dc=org
-server.db.partition.suffix.example=dc=example,dc=com
-server.db.partition.suffix.xyz123=ou=xyz123
-</source>
- </td>
- </tr>
-
- <tr>
- <td>server.db.partition.indices.</td>
- <td>maybe</td>
- <td>
- A key base for listing the indices for database partitions. The
- identifier for the partition is appended to this base to form the
- key for the suffix of that partition. The value is a space
- separated list of attributeType names.
-<source>
-server.db.partition.indicies.apache=dc ou locale cn
-server.db.partition.indicies.example=dc ou locale cn uid
-server.db.partition.indicies.xyz123=ou cn
-</source>
- </td>
- </tr>
-
- <tr>
- <td>server.db.partition.attributes.</td>
- <td>maybe</td>
- <td>
- A key base for listing the attributes and values for the suffix
- entries of partitions. The identifier for the partition is
- appended to this base, then the name of attribute is appended to
- form the key for the attribuet in the suffix of that partition.
- More information on setting up partitions with this and other
- properties is <a href="./partitions.html">here</a>...
-<source>
-server.db.partition.attributes.apache.dc=apache
-server.db.partition.attributes.apache.objectClass=domain top
-</source>
- </td>
- </tr>
-
- </table>
-
- <p>
- Note that the optional columns of some rows were labeled as 'maybe'. If a
- partition is created then the respective property with the base would be
- required. It is only required when the respective partition is being defined.
- </p>
</section>
<section name="Embedding the Apache Directory Server">
@@ -219,10 +52,6 @@
</p>
<source>
-Hashtable env = new Hashtable();
-env.put( Context.PROVIDER_URL, "ou=system" );
-env.put( Context.INITIAL_CONTEXT_FACTORY, "org.apache.ldap.server.jndi.ServerContextFactory" );
-InitialDirContext ctx = new InitialDirContext( env );
</source>
<p>
@@ -237,7 +66,7 @@
<p>
<b>WARNING:</b> REMOVE THE TEST USER AND RESET THE PASSWORD ON THE ADMIN
- USER ACCOUNT AFTER STARTING EVE.
+ USER ACCOUNT AFTER STARTING APACHEDS.
</p>
<p>
@@ -245,36 +74,6 @@
</p>
<source>
-Hashtable env = new Hashtable();
-
-// Standard JNDI properties
-env.put( Context.PROVIDER_URL, "ou=system" );
-env.put( Context.INITIAL_CONTEXT_FACTORY, "org.apache.ldap.server.jndi.ServerContextFactory" );
-env.put( Context.SECURITY_PRINCIPAL, "uid=admin,ou=system" );
-env.put( Context.SECURITY_CREDENTIALS, "secret" );
-
-// Eve specifice JNDI properties
-env.put( EnvKeys.WKDIR, "/var/ldap" );
-env.put( EnvKeys.DISABLE_ANONYMOUS, "true" );
-env.put( EnvKeys.LDAP_PORT, "10389" );
-env.put( EnvKeys.PARTITIONS, "apache" );
-
-// Setup new partition for Apache
-BasicAttributes attrs = new BasicAttributes( true );
-BasicAttribute attr = new BasicAttribute( "objectClass" );
-attr.add( "top" );
-attr.add( "domain" );
-attr.add( "extensibleObject" );
-attrs.put( attr );
-attr = new BasicAttribute( "dc" );
-attr.add( "apache" );
-attrs.put( attr );
-env.put( EnvKeys.SUFFIX + "apache", "dc=apache,dc=org" ); // suffix
-env.put( EnvKeys.INDICES + "apache", "ou uid objectClass" ); // user indices
-env.put( EnvKeys.ATTRIBUTES + "apache", attrs ); // suffix entry
-
-// Fire it up!
-InitialDirContext ctx = new InitialDirContext( env );
</source>
<p>
@@ -284,7 +83,7 @@
<b>dc=apache,dc=org</b> naming context in addition to the system
partition. If you look closely at /var/ldap you'll see a directory
named apache where you'll find even more database files. These files
- are the database files for the separate partition for apache.org entries.
+ are the database files for the separate partition apache.org entries.
</p>
</section>
</body>
Modified: directory/apacheds/trunk/xdocs/users/index.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/index.xml?rev=328459&r1=328458&r2=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/index.xml (original)
+++ directory/apacheds/trunk/xdocs/users/index.xml Tue Oct 25 12:27:53 2005
@@ -40,11 +40,20 @@
<tr>
<td>
- <a href="./jndi.html">JNDI Properties</a>
+ <a href="./authorization.html">Authorization</a>
</td>
<td>
- Describes the JNDI properties used to control the behavoir and
- configuration of the server.
+ Explains the hardcoded authorization rules and how to replace
+ them using the basic access control mechanism and ACI.
+ </td>
+ </tr>
+
+ <tr>
+ <td>
+ <a href="./configuration.html">Configuration</a>
+ </td>
+ <td>
+ Describes how to configure and control the server.
</td>
</tr>
Modified: directory/apacheds/trunk/xdocs/users/partitions.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/partitions.xml?rev=328459&r1=328458&r2=328459&view=diff
==============================================================================
--- directory/apacheds/trunk/xdocs/users/partitions.xml (original)
+++ directory/apacheds/trunk/xdocs/users/partitions.xml Tue Oct 25 12:27:53 2005
@@ -80,157 +80,12 @@
<section name="Adding User Partitions">
<p>
Adding new application partitions to the server is a matter of
- setting the right JNDI environment properties. These properties are
- used in both standalone and in embedded configurations. We will show
- you how to configure partitions by example using properties files and
- programatically.
+ adding DirectoryPartitionConfiguration objects to the
+ StartupConfigration added to the JNDI environment. These properties
+ are used in both standalone and in embedded configurations. We will
+ show you how to configure partitions by example using xml configuration
+ files with the standalone application and programatically for embedding.
</p>
-
- <subsection name="Using Properties Files">
- <p>
- Obviously properties files are not the best way to configure a large
- system like an LDAP server. However properties files are the JNDI
- standard for pulling in configuration. The server's JNDI provider tries
- to honor this. Hence the use of a properties file for configuration.
- Below we have the configuration of two user defined partitions within
- a properties file. These partitions are for the naming contexts:
- <code>dc=apache,dc=org</code> and <code>ou=test</code>.
- </p>
-
- <source>
-# all multivalued properties are space separated like the list of partions here
-server.db.partitions=apache test
-
-# apache partition configuration
-server.db.partition.suffix.apache=dc=apache,dc=org
-server.db.partition.indices.apache=ou cn objectClass uid
-server.db.partition.attributes.apache.dc=apache
-server.db.partition.attributes.apache.objectClass=top domain extensibleObject
-
-# test partition configuration
-server.db.partition.suffix.test=ou=test
-server.db.partition.indices.test=ou objectClass
-server.db.partition.attributes.test.ou=test
-server.db.partition.attributes.test.objectClass=top organizationalUnit extensibleObject
- </source>
-
- <p>
- Although somewhat ugly the way we use properties for settings is
- portable across JNDI LDAP providers. Hopefully we can build a tool
- on top of this to save the user some hassle. Another approach may be
- to use XML or something easier to generate these properties from them.
- For now its the best non-specific (to the server's provider) means we
- have to inject settings through JNDI environment Hashtables while
- still being able to load settings via properties files. Properties
- from proerties files are the common denominator though. Another
- easier means to configure the server is possible programatically.
- </p>
- <h3>Partition Id</h3>
- <p>
- Breifly we'll explain these properties and the scheme used. A
- partition's property set is associated as a set using the partition's
- id. All partition ids are listed as a space separated list using the
- <b>server.db.partitions</b> property: above it lists the ids for the two
- partitions, <i>apache</i> and <i>test</i>.
- </p>
- <h3>Naming Context</h3>
- <p>
- Partitions need to know the naming context they will store entries
- for. This naming context is also referred to as the suffix since all
- entries in the partition have this common suffix. The suffix is a
- distinguished name. The property key for the suffix of a partition is
- composed of the following property key base
- <b>server.db.partition.suffix.</b> concatenated with the id of the
- partition: <b>server.db.partition.suffix.</b><i>${id}</i>. For example
- if the partition id is foo, then the suffix key would be,
- <b>server.db.partition.suffix.foo</b>.
- </p>
- <h3>User Defined Indices</h3>
- <p>
- Partitions can have indices on attributes. Unlike OpenLDAP where you
- can build specific types of indices, the server's indices are of a
- single type. For each partition, a key is assembled from the
- partition id and the property key base:
- <b>server.db.partition.indices.</b><i>${id}</i>. So
- again for foo the key for attribute indices would be
- <b>server.db.partition.indices.foo</b>. This value is a space separated
- list of attributeType names to index. For example the apache
- partition has indices built on top of <b>ou</b>, <b>objectClass</b>
- and <b>uid</b>.
- </p>
- <h3>Suffix Entry</h3>
- <p>
- When creating a context the root entry of the context corresponding
- to the suffix of the partition must be created. This entry is
- composed of single-valued and multi-valued attributes. We must
- specify these attributes as well as their values. To do so we again
- use a key composed of a base, however this time we use both the id
- of the partition and the name of the attribute:
- <b>server.db.partition.attributes.</b><i>${id}</i>.<i>${name}</i>. So
- for partition foo and attribute bar the following key would be used:
- <b>server.db.partition.attributes.foo.bar</b>. The value of the key
- is a space separated list of values for the bar attribute. For
- example the apache partition's suffix has an objectClass attribute
- and its values are set to: top domain extensibleObject.
- </p>
- </subsection>
-
- <subsection name="Programatically">
- <p>
- This is simple create a Hashtable and stuff it with those properties.
- But that's a real pain. The other option is to set all the properties
- that way minus the one for the suffix entries attributes. We have
- a shortcut where you can set an Attributes object within the Hashtable
- and it will get picked up instead of using the standard property
- scheme above.
- </p>
-
- <p>
- Simply put the Attributes into the Hashtable using the following
- key <b>server.db.partition.attributes.</b><i>${id}</i>. Below we show
- how this can be done for the same example above:
- </p>
-
-<source>
-BasicAttributes attrs = new BasicAttributes( true );
-BasicAttribute attr = new BasicAttribute( "objectClass" );
-attr.add( "top" );
-attr.add( "organizationalUnit" );
-attr.add( "extensibleObject" );
-attrs.put( attr );
-attr = new BasicAttribute( "ou" );
-attr.add( "testing" );
-attrs.put( attr );
-
-extras.put( EnvKeys.PARTITIONS, "testing example" );
-extras.put( EnvKeys.SUFFIX + "testing", "ou=testing" );
-extras.put( EnvKeys.INDICES + "testing", "ou objectClass" );
-extras.put( EnvKeys.ATTRIBUTES + "testing", attrs );
-
-attrs = new BasicAttributes( true );
-attr = new BasicAttribute( "objectClass" );
-attr.add( "top" );
-attr.add( "domain" );
-attr.add( "extensibleObject" );
-attrs.put( attr );
-attr = new BasicAttribute( "dc" );
-attr.add( "example" );
-attrs.put( attr );
-
-extras.put( EnvKeys.SUFFIX + "example", "dc=example" );
-extras.put( EnvKeys.INDICES + "example", "ou dc objectClass" );
-extras.put( EnvKeys.ATTRIBUTES + "example", attrs );
-</source>
-
- <p>
- Ok that does not look any shorter. We'll add to this in the future.
- Perhaps we enable the use of configuration beans that can be used
- with an SPI specific to server. However this starts making your code
- server provider specific. You can just change properties and use the
- SUN provider anymore to have your code be location independent.
- </p>
- </subsection>
- </section>
<section name="Future Progress">
<subsection name="Partition Nesting">
Added: directory/apacheds/trunk/xdocs/users/subentries.xml
URL: http://svn.apache.org/viewcvs/directory/apacheds/trunk/xdocs/users/subentries.xml?rev=328459&view=auto
==============================================================================
--- directory/apacheds/trunk/xdocs/users/subentries.xml (added)
+++ directory/apacheds/trunk/xdocs/users/subentries.xml Tue Oct 25 12:27:53 2005
@@ -0,0 +1,36 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>Subentries</title>
+ </properties>
+
+ <body>
+
+ <section name="What are they?">
+ <subsection name="Status">
+ <p>
+ </p>
+
+ <p>
+ </p>
+ </subsection>
+
+ <subsection name="Subentry Handling in ApacheDS">
+ <p>
+ </p>
+ </subsection>
+
+ <subsection name="SubtreeSpecification Examples">
+ <p>
+ </p>
+ </subsection>
+
+ <subsection name="Subentry Examples">
+ <p>
+ </p>
+ </subsection>
+
+ </section>
+ </body>
+</document>