directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From directory-...@incubator.apache.org
Subject [Apache Directory Project Wiki] Updated: EveGeneral
Date Mon, 06 Dec 2004 06:47:12 GMT
   Date: 2004-12-05T22:47:12
   Editor: AlexKarasulu <akarasulu@apache.org>
   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.
 
 
 

Mime
View raw message