directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <>
Subject Re: How Authenticators and PasswordPolicies will be managed in new component design.
Date Thu, 12 Jan 2012 16:21:03 GMT
On Thu, Jan 12, 2012 at 3:45 PM, Emmanuel Lecharny <>wrote:

> 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.
Makes no difference but as you say below we do want to enable and disable
it too.

> 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.
+1 regarding making it optional and the default is not to enable PP module

>> 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)

I mean this in terms of configuration nesting. For example in the
configuration DIT area these should not be found to be configurable under
the authentication interceptor but should be things we can configure at the
top level under the directory service.

Does this shed more light on my terminology?

>  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.
That would make the AI smaller and easier to manage.


>> 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
> configuration.


> - 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.
Partially in line with my thoughts. The configurations for the
Authenticators should not be under the AuthenticationInterceptor. The
Authenticators should be managed and configured under the DirectoryService.
The AuthenticationInterceptor uses/refers to these Authenticators that are
managed under the DS.

> Does this make sense ? Does it aligns well with what Gokturk is working on
> ?
Almost just a simple difference in our thoughts but really nothing at all.
I just think think about interceptors as a mechanism to inject aspects and
functionality. The interceptor itself need not manage the configuration of
the aspect.This can be done outside the interceptor. The interceptor is
there to just do the bidding of the aspect and apply it to the invocation.

Best Regards,
-- Alex

View raw message