[jira] Commented: (DIREVE-58) Figure out and implement some kind of simple authentication mechanism

["Alex Karasulu (JIRA)" <di...@incubator.apache.org>]

     [ http://issues.apache.org/jira/browse/DIREVE-58?page=comments#action_54826 ]
     
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: http://issues.apache.org/jira/browse/DIREVE-58
>      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:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira