On Thu, Jan 12, 2012 at 3:45 PM, Emmanuel Lecharny <email@example.com>
Authenticator are pluggable elements. PPolicy is a bit different, as we can't plug a new PPolicy element, we can just modify its configuration.
On 1/12/12 2:01 PM, Alex Karasulu wrote:
On Tue, Jan 10, 2012 at 2:33 AM, Göktürk Gezer<firstname.lastname@example.org>wrote:
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....
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.
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 IMO.
Can you clarify what you mean by TL elements ? Are they bundles ? (I do think so)
Although Authenticators and PasswordPolicies are managed under the
AuthenticationInterceptor they are top level elements.
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?
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.
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.
That would make the AI smaller and easier to manage.
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 :
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
- 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.