Return-Path: X-Original-To: apmail-directory-dev-archive@www.apache.org Delivered-To: apmail-directory-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id E606FB2BE for ; Thu, 12 Jan 2012 18:09:50 +0000 (UTC) Received: (qmail 75206 invoked by uid 500); 12 Jan 2012 18:09:50 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 75161 invoked by uid 500); 12 Jan 2012 18:09:50 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 75153 invoked by uid 99); 12 Jan 2012 18:09:49 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jan 2012 18:09:49 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of akarasulu@gmail.com designates 209.85.220.178 as permitted sender) Received: from [209.85.220.178] (HELO mail-vx0-f178.google.com) (209.85.220.178) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 12 Jan 2012 18:09:43 +0000 Received: by vcbfo11 with SMTP id fo11so2078288vcb.37 for ; Thu, 12 Jan 2012 10:09:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=bECiFbotMbsfQx8nJSm94IYVIGGpPAHtSAMwuqTWC78=; b=wgRffUWHdyKC7j9cumXy3FWhHwd6oq90jTGfnNj4ZD0wMRUWX37PCirmM9GRXejCDK n5g5z+mL+Rpyn3tTlMWk+vBUy+egRLbq3PYkqg/1FLSgla5Tfo5SYrjTcawYTWDC8Zm/ i8ieQXMxeRDibA1BH5qH/heyRkrwjBWSjB5W4= MIME-Version: 1.0 Received: by 10.220.155.147 with SMTP id s19mr2881922vcw.14.1326391762775; Thu, 12 Jan 2012 10:09:22 -0800 (PST) Sender: akarasulu@gmail.com Received: by 10.220.108.7 with HTTP; Thu, 12 Jan 2012 10:09:22 -0800 (PST) In-Reply-To: <4F0F17B6.5000202@apache.org> References: <4F0EE402.9000209@gmail.com> <4F0F17B6.5000202@apache.org> Date: Thu, 12 Jan 2012 20:09:22 +0200 X-Google-Sender-Auth: OwaNtVgJ4q_JJp0wk2gxzg1OFHI Message-ID: Subject: Re: How Authenticators and PasswordPolicies will be managed in new component design. From: Alex Karasulu To: Apache Directory Developers List , elecharny@apache.org Content-Type: multipart/alternative; boundary=f46d043c7cf0da703004b658a57c --f46d043c7cf0da703004b658a57c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2012 at 7:26 PM, Emmanuel L=E9charny = wrote: > On 1/12/12 5:21 PM, Alex Karasulu wrote: > >> On Thu, Jan 12, 2012 at 3:45 PM, Emmanuel Lecharny*= * >> 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 unde= r >> 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 o= n >>> 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 a= re >> 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 a= nd >> 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 invocatio= n. >> > 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 int= o > the OSGi branch, because it's orthogonal. > > Thanks for the clarification ! > > Thank you as well. --=20 Best Regards, -- Alex --f46d043c7cf0da703004b658a57c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Jan 12, 2012 at 7:26 PM, Emmanue= l L=E9charny <= 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 cr= ystal clear.


Kr= uta (means cool in Russian)
=A0
The
Authenticators should be managed and configured under the DirectoryService.=
The AuthenticationInterceptor uses/refers to these Authenticators that are<= br> managed under the DS.
+1



Does this make sense ? Does it aligns well with what Gokturk is working on<= br> ?


Almost just a simple difference in our thoughts but really nothing at all.<= br> I just think think about interceptors as a mechanism to inject aspects and<= br> functionality. The interceptor itself need not manage the configuration of<= br> 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.<= br>
Yep. So we should move the Authenticator config elsewhere (ie, not under th= e AuthenticationInterceptor). This way, they can be used by someone who wan= ts to develop another interceptor.


+1
=A0
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 t= o do that.


OK I'll add the issues.
= =A0
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 !

<= /div>

Thank you as well.
--
Best Regards,
-- Alex

--f46d043c7cf0da703004b658a57c--