directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu (JIRA)" <>
Subject [jira] Commented: (DIREVE-58) Figure out and implement some kind of simple authentication mechanism
Date Sat, 30 Oct 2004 07:41:32 GMT
     [ ]
Alex Karasulu commented on DIREVE-58:

Eve JNDI Provider Authentication

Depending on how we intend to use Eve in embedded and standalone scenarios we may need different
mechanisms for managing authentication.  This opens the door to several possibilities.  We
need to explore all the possible use cases to make decisions that in turn make the experiences
of Eve users pleasant and easy.

Why is a user so important?

We may not need any authentication at all but we do need to have identity for all Eve provider
operations to proceed.  We need to know who is performing operations at a minimum to be able
to set critical operational attribute values like creatorsName and modifiersName.

Several critical system objects will be created in the bootstrap process and they must be
owned by some user in the system.  For sure we're not going to use a wide open user such as
the guest or anonymous user denoted by the empty String DN "".  We want maximum security for
these critical objects so we assign admin user as the owner.  The admin user account is fixed
at uid=admin,ou=system and is the super user of all users including other administrators.

Rules that make using Eve's JNDI Provider easier?

For brevity we refer to the Context.SECURITY_PRINCIPAL property as the principal and the Context.SECURITY_CREDENTIALS
as the credentials.

1.Only the admin user can bootstrap Eve's backend subsystem! Meaning the initial Eve JNDI
context request after starting the JVM must be issued by the admin user.  
2.If the principal property is not set on an initial context request, the admin user is presumed
to be the effective principal.
3.If the principal property is present with a null value it represents the anonymous user
and not the admin user.  Only when the principal property key is missing in the env do we
default to the admin principal.
4.The credentials property is used to authenticate the admin on the bootstrapping request.
 If this property key is not present or its value is null, the empty string, or an empty byte[],
authentication will only proceed if the admin userPassword is set to null, the empty string
or an empty byte[].
5.When starting Eve for the very first time ever the system database partition at ou=system
is created and at some point after that the admin user account is created.  The admin account
entry is an inetOrgPerson with a userPassword field.  The userPassword field is set to whatever
the value of credentials property is set to.  If the key is undefined then the userPassord
property is set to the empty byte[].

These rules of operation have a useful effect of reducing the amount of work required on the
part of the most common Eve JNDI provider use cases.  We see their value when we look at how
Eve's provider will be used with respect to authentication when embedding.  Let's look at
a few use cases now:

1.The embedding application does not care at all about multiple users and/or having to perform
any authentication at all.  For all they care, authentication need not even exist as a feature.
 These users simply want a JNDI backing store that uses the LDAP namespace to store stuff
owned by the application.  This will be the most common use case.
2.The application does care about authenticating as a specific user but this user is the do
anything they want user: the admin.  Here security is important but the user is fixed as the
administrator.  The aim here is to have full control while preventing others from using the
Eve provider to access your backend system data.
3.The dependent application requires multiuser authentication.  Here security matters, all
the way, all the time.  Basically authentication is totally delegated to the Eve JNDI provider.
 This situation is pretty rare and is specific to the way the Eve server's networking front
end delegates simple authentication.  Things like SASL are implemented at the networking level
and are not concerns of the JNDI backend subsystem.

In case #1, the user can just start up the Eve backend without providing the security principal
or their credentials as if authentication does not exist at all.  When bootstrapping for the
first time the admin user account is created. According to rule-2 and rule-3 the user admin
is presumed when the principal property is found missing.  Finally according to rule-4 the
system database with admin account is created and the admin userPassord is set to a byte[].
 Recurring requests for the JNDI context automatically default in the same manner and authentication
proceeds without having to provide any credentials.  Effectively there is no authentication
according to the application embedding Eve in this way.

In case #2, the first bootstrap request contains the principal and credentials to set for
the admin account that is created.  Subsequent requests for InitialContexts using the same
credentials will authenticate the user correctly.  If authentication fails the system will
shut back down so others using the Eve JNDI Provider cannot access the data within this instance
without those credentials.  Security is achieved in the minimal fashion needed.

In case #3, well that gets complex but the rules save us again here two but for the admin
user this is the same as case #2.  For all principals creating initial contexts the provider
becomes the authentication service in itself.

> Figure out and implement some kind of simple authentication mechanism
> ---------------------------------------------------------------------
>          Key: DIREVE-58
>          URL:
>      Project: Directory Eve
>         Type: New Feature
>   Components: jndi-provider
>     Reporter: Alex Karasulu
>     Assignee: Alex Karasulu

> We want to at least facilitate simple authentication and anonynous binds alike with a
simple JAAS based solution.  Let's look into using security manger base operations like doAs
and doPrivledged to understand how to sandbox users as well.  
> Plus there's the whole problem of how do we manage the logical user session?  What's
the associatation with new contexts and users - also how do we protect from impersonation.
> How do we set the admin password when starting for the first time.  Do we just use the
first principal and credentials given for the uid=admin,ou=system special super user account?
 These are all questions that need to be answered.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
If you want more information on JIRA, or have a bug to report see:

View raw message