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 Sun, 05 Dec 2004 22:50:02 GMT
   Date: 2004-12-05T14:50:02
   Editor: AlexKarasulu <akarasulu@apache.org>
   Wiki: Apache Directory Project Wiki
   Page: EveGeneral
   URL: http://wiki.apache.org/directory/EveGeneral

   no comment

Change Log:

------------------------------------------------------------------------------
@@ -4,7 +4,7 @@
 
 == Out-of-the-box Authentication ==
 
-I really wanted to make Authentication something that does not get in the way if users 
+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

@@ -15,8 +15,32 @@
 
 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; in this case they effectively are the super
user and need to get around authorization issues to have free reign
+ * 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.
+ * 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?
+
+ 
+
+
+
+
+
+
+
+
+
+
+

Mime
View raw message