directory-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Connection : Simple Bind operation
Date Thu, 11 Feb 2010 11:03:44 GMT
Hi,

I just checked the way all the API handle the simple Bind() operation. 
Here is a sum up :

ADS :
-----
see later...

jLdap :
-------
synchronous :
* bind(int, String, byte[])
* bind(int, String, byte[], LDAPConstraints)

asynchronous :
* bind(int, String, byte[], LDAPResponseQueue)
* bind(int, String, byte[], LDAPResponseQueue, LDAPConstraints)

LDAPConstraints will contain the controls.
LDAPResponseQueue is used for asynchronous operation


JNDI :
------

JNDI Bind operation is totally different. It's semantically another 
beast. A LDAP Bind on JNDI is done through the creation of a Context, 
and the user/credentials are passed in a hashtable. We don't want to go 
there ...

ODS :
-----
synchronous :
* Connection.bind(BindRequest)
* Connection.bind(String, String)

asynchronous :
* LdapConnection.bind(BindRequest, ResultHandler<? super BindResult>)

Beside the fact that it's not obvious that LdapConnection class means 
'asynchronous', a password may be a byte[] so we won't be able to easily 
bind in this case (a user will have to create a BindRequest). Anonymous 
bind needs to pass null values to the bind operation.

UID :
-----
synchronous :
* bind(BindRequest)
* bind(String, String)

No asynchronous bind.

Summary :
---------
This is really an area where the APIs differ a lot. If we come back to 
the RFC, a Simple Bind operation has 3 valid forms and one invalid :
user = null, password = null : anonymous bind
user != null, password = null : unauthenticated bind
user = null, password != null : invalid
user != null, password != null : simple authentication

In any case, the password is an Octet String, ie a byte[]. The user is 
always a DN when doing a simple bind.

Some last consideration : if we are to support asynchronous operations, 
then we need to make this explicit.

I suggest we keep it simple from the user pov, considering that :
- users will mainly do synchronous operations
- anonymous bind must be easy to code
- we want to make it explicit that the async mode is used
- and we don't want zillion of methods.

So every method bind(...) will have a equivalent async method 
bindAsync(), the anonymous bind will be a bind() method without 
parameters, the password can be either a String or a byte[], and the 
user can be either a String or a DN :

synchronous :
* bind()  anonymous bind
* bind( String userDN, String password ): simple bind (if the password 
is null, this will be the unauthenticated bind)
* bind( String userDN, String password )
* bind( DN userDN, String password )
* bind( String userDN, byte[] password )
* bind( DN userDN, byte[] password )
* bind( BindRequest )

asynchronous :
* bindAsync()  anonymous bind
* bindAsync( String userDN, String password ): simple bind (if the 
password is null, this will be the unauthenticated bind)
* bindAsync( String userDN, String password )
* bindAsync( DN userDN, String password )
* bindAsync( String userDN, byte[] password )
* bindAsync( DN userDN, byte[] password )
* bindAsync( BindRequest )

This is currently what we have in ADS, not because it's better, but 
because we have redesigned the API after having written this mail (the 
previous API was, hmmm. ok. don't ask ;)

thoughts ?

-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.nextury.com



Mime
View raw message