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:21:58 GMT
Jira Issues created here:

PPolicy Issue: https://issues.apache.org/jira/browse/DIRSERVER-1686

Authenticators Issue: https://issues.apache.org/jira/browse/DIRSERVER-1685

On Thu, Jan 12, 2012 at 8:09 PM, Alex Karasulu <akarasulu@apache.org> wrote:

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


-- 
Best Regards,
-- Alex

Mime
View raw message