Date: 2004-12-05T22:47:12
Editor: AlexKarasulu <[EMAIL PROTECTED]>
Wiki: Apache Directory Project Wiki
Page: EveGeneral
URL: http://wiki.apache.org/directory/EveGeneral
no comment
Change Log:
------------------------------------------------------------------------------
@@ -4,41 +4,13 @@
== Out-of-the-box Authentication ==
-I really wanted to make Authentication something that does not get in the way
of users
-not needing it. Meaning if users did not have any security requirements where
-they're just using Eve (especially in embedded mode) as a simple backing store
using LDAP
-as the namespace they should not have to authenticate. To balance enabling
both types of
-users (those needing and not needing auth) while minimizing first time startup
configuration
-overheads and authorization issues we needed a policy for dealing with user
passwords in
-general and the system user password. First let's list some of our
requirements and some
-notes about the problems.
-
-Requirements for Setting Admin (super-user) Password:
- * minimize setup overhead in general
- * config-less operation even without providing a password should be possible
for those that just want to use eve as an LDAP backing store
- * users that do not care about authorizing effectively want to be super users
all the time to get around authorization issues to have free reign
-
-Notes:
- * According to LDAP JNDI provider implementation guidelines, "if this
property [java.naming.security.authentication] is not set then its default
value is none, unless the java.naming.security.credentials property is set, in
which case the default value is simple." So this means config-less operation
presumes anonymous binds and we must conform to these guidelines.
- * Most LDAP browsers do not allow simple binds using null or empty passwds.
This makes using a null password a poor choice for the super user.
-
-So from this information we find ourselve kinda stuck. Without any credential
information anonymous binds should be in effect not simple binds. So we need
to provide something. Secondly we can't use null or empty passwords for any
users.
-
-There is one gray area though where we might be able to appease all however
its a risky proposition. The anonymous user right now defaults to the empty
string or empty DN user "" which is never authenticated. We can make the
anonymous user configurable and have it default to the super user. This is
sorta insane for anyone except for those who want to embed the server. Even
they may not want to expose this via LDAP though. Right now LDAP access is
enabled by default blowing up the LDAP server automatically. We can supress
this default behavoir when the anonymous account is the super-user. We can
require a property to force it on in addition to the property we have today to
force disabling the LDAP server.
-
-So a new property for setting the anonymous account would need to be created:
eve.anonymous.user. If this property is not present, the super-user account's
DN (uid=admin,ou=system) is used for anonymous binds by default. If present
and set to null or the empty string the anonymous user is the empty string DN
(""). If the anonymous account is set to the super-user then the default
behavoir of firing up the LDAP server is supressed. An explicit force server
on property can be used to turn on the server even when the super-user is the
anonymous user. Right now eve.net.disable.protocol is used to force
suppression of firing up the server. We can use eve.net.enable.protocol to
force enabling the protocol server when the super-user account is used as the
anonymous user. These two symmetric properties are overrides. Should we just
use one property for the override and use a true or a false value instead of
having two marker properties? This might be best and we can use
eve.net.protocol.override which can be "on" or "off". Also by default we must
enable anonymous binds. Right now anonymous binds are turned off out of the
box. To turn them on the eve.enable.anonymous property must be present. I say
we just swap the setup where we rename eve.enable.anonymous to
eve.disable.anonymous and enable anonymous binds by default.
-
-These present security issues but they make using Eve as a JNDI provider sooo
much easier without having to set any properties at all. Not just yet! We
still need to look at what happens on the first start which creates the
uid=admin account. With a config-less setup the passwd is set to "" the empty
string. If the credentials property is provided on startup it is presumed to
be the admin's password. If the principal property is also provided on the
first startup it must be the admin user DN. If it is not then we throw a
configuration exception. By default if credentials are provided without a
principal name the super-user is presumed to be the principal by default since
the authentication type now becomes simple.
-
-WDYT?
-
-
-
-
-
+* Eve's super-user (uid=admin,ou=system) is created on the first start and has
its userPassword field set to "secret".
+* Another test user uid=akarasulu,ou=users,ou=system is created on first
startup and has password "test".
+* Any user entry that has the userPassword attribute set can be authenticated.
The user need not be under ou=users, ou=system.
+* There are advantages to creating users under ou=users, ou=system. First the
user is available regardless of the context partitions that are created. The
user also is protected by some hardcoded authorization rules within the system.
Namely only self read is possible for all users on their own accounts. Users
cannot see the credentials of others minus the super-user of course. This is
an intermediate hardcoded authorization rule set until the authorization
subsystem matures.
