directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: How Authenticators and PasswordPolicies will be managed in new component design.
Date Thu, 12 Jan 2012 13:45:38 GMT
On 1/12/12 2:01 PM, Alex Karasulu wrote:
> On Tue, Jan 10, 2012 at 2:33 AM, Göktürk Gezer<>wrote:
>> Hi Again,
>> It seems lots of things are structured like that. Partitions,servers are
>> all have inner entries.There are partition-indexes and transports those
>> have same problem. I must develop some way to allow such structure.
>> Component-hub must have component type specific code to handle these
>> things. So i'll work on that before everything. But you can still say if
>> Authenticators must be extensible....
>> Regards,
>> Gokturk
> Hi All,
> Gokturk and I had a discussion yesterday regarding this topic. Basically
> authenticators and password policies can be considered top level
> configurable elements unlike indices for example that are specifically tied
> to their partitions.

Authenticator are pluggable elements. PPolicy is a bit different, as we 
can't plug  a new PPolicy element, we can just modify its configuration.

We should make the distinction between those two kinds of things. Now, 
the question would be : should we allow the user to uninstall the 
PPolicy module ? I tend to think that it would be a good idea, for those 
who would like to embed a minimal server.

> Although Authenticators and PasswordPolicies are managed under the
> AuthenticationInterceptor they are top level elements.

Can you clarify what you mean by TL elements ? Are they bundles ? (I do 
think so)
> The
> AuthenticationInterceptor just happens to be where functionally their
> maintenance made sense in the past. This might change and we might manage
> these in the DirectoryService to denote their first class component status.
> However PPs and Authenticators are clearly different from a Partition's
> Index which is really tied to the partition where as these components are
> not really tied the AuthenticationInterceptor.
At some point, we could perfectly well make the PPolicy an interceptor, 
instead of make it be a part of the AuthenticatorInterceptor. IMHO, it 
would be easier. Then disabling it would be just a matter of not loading 
the PPolicyInterceptor bundle at all.
> I think this makes me believe that the AuthenticationInterceptor should not
> manage these components but just leverage them by accessing them from the
> DirectoryService. The DirectoryService should really manage these top level
> components.
> Thoughts?

So let me sumup how I see those components being used in the server. Not 
sure it's very different with what you have in mind :
- we should have a PPolicyInterceptor, a bundle that must be loaded in 
order to be used. It will of course be configured. This should be a 
standalone bundle.
- the AuthenticatorInteceptor is also a standalone bundle, with some 
- the Authenticators are standalone bundles that are loaded by the 
AuthenticatorInteceptor, depending on the AuthenticatorInteceptor 
configuration. We should be able to load/decommision an Authenticator on 
the fly, without having to stop the server.

Does this make sense ? Does it aligns well with what Gokturk is working on ?

Emmanuel Lécharny

View raw message