directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [JNDI removal]
Date Wed, 07 May 2008 12:39:22 GMT
On Wed, May 7, 2008 at 7:53 AM, Emmanuel Lecharny <>

> Hi,
> in the effort to remove the JNDI from our server, I will have to create a
> kind of context where we will store some informations, in order to be able
> to execute the LDAP requests without changing the whole logic.
> For instance, the authentication interceptor uses the stored Context to
> check if the user who submitted a request is already authentified or not
> (this information is currently stored as a property within a LdapContext,
> stored into the user's MINA IoSession attributes)
> Ldap being a connected protocol, it seems quite natural to define a
> LdapSession object which will be associated with all new incoming Bind
> request, which will contains informations like the ones currently defined by
> JNDI, but also some others. We can have three kinds of data :
> - server specific data (the ones which won't change before decades), like
> Principal, Credentials, Referral...
> - user specific data (the ones a use can use, but are optional), like
> factory.object, language...
> - configurable data : some unknown data which may be used by some server
> extension.
> The idea is to declare the first and second kind of data as fields in the
> LdapSession object, for faster access, and add a Property field to store the
> third kind of data.
> wdyt ?

Yeah I like this idea.  Let me add some of my motely thoughts to this:

(1) An LdapSession interface is a great idea.  An implementation of this
interface can wrap a MINA Session to provide access to session attributes in
MINA as well as expose things like IP related information which may be
leveraged by things like the access control subsystem.

(2) We could stuff or cache many things in this session object.

 - Authenticated LdapPrincipal
 - Authorized LdapPrincipal
 - Groups associated with authenticated and authorized identity.
 - AuthenticationLevel

(3) Perhaps we can also cache some stuff that is used frequently for a user
while they perform operations.

Whatever we add to a session I'd like to make sure we can invalidate
sessions based on related information changing for that user.


View raw message