directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Karasulu <akaras...@apache.org>
Subject Re: How Authenticators and PasswordPolicies will be managed in new component design.
Date Thu, 12 Jan 2012 18:09:22 GMT
On Thu, Jan 12, 2012 at 7:26 PM, Emmanuel L├ęcharny <elecharny@apache.org>wrote:

> On 1/12/12 5:21 PM, Alex Karasulu wrote:
>
>> On Thu, Jan 12, 2012 at 3:45 PM, Emmanuel Lecharny<elecharny@gmail.com>**
>> wrote:
>>
>>
>>>
>>>  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?
>>
>
> Absolutely.
>
>
>
>>  - 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.
>>
>
> Agreed. I don't think I mentioned this part, so thanks for making it
> crystal clear.
>
>
Kruta (means cool in Russian)


>  The
>> Authenticators should be managed and configured under the
>> DirectoryService.
>> The AuthenticationInterceptor uses/refers to these Authenticators that are
>> managed under the DS.
>>
> +1
>
>
>>
>>  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.
>>
> Yep. So we should move the Authenticator config elsewhere (ie, not under
> the AuthenticationInterceptor). This way, they can be used by someone who
> wants to develop another interceptor.
>
>
+1


> We should also create a PPolicy interceptor (just as a reminder).
>
> I suggest we create JIRAs for those tasks, to be sure we don't forget to
> do that.
>
>
OK I'll add the issues.


> IMO, we can even make those changes in trunks, and inject the changes into
> the OSGi branch, because it's orthogonal.
>
> Thanks for the clarification !
>
>
Thank you as well.

-- 
Best Regards,
-- Alex

Mime
View raw message