From dev-return-189902-archive-asf-public=cust-asf.ponee.io@tomcat.apache.org Fri Mar 30 02:30:25 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id C6D9A180645 for ; Fri, 30 Mar 2018 02:30:24 +0200 (CEST) Received: (qmail 25349 invoked by uid 500); 30 Mar 2018 00:30:23 -0000 Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Developers List" Delivered-To: mailing list dev@tomcat.apache.org Received: (qmail 25338 invoked by uid 99); 30 Mar 2018 00:30:23 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 30 Mar 2018 00:30:23 +0000 Received: from Christophers-MacBook-Pro.local (pool-173-66-120-163.washdc.fios.verizon.net [173.66.120.163]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 84D6FFC6 for ; Fri, 30 Mar 2018 00:30:22 +0000 (UTC) Subject: Re: Request for comment on BZ 59750 (authentication listener) To: dev@tomcat.apache.org References: <624a29b7-9be4-202a-0310-148430ef7a6d@christopherschultz.net> <6d70ef9a-006e-da04-92c4-57432d99eb70@apache.org> From: Christopher Schultz Message-ID: <7d8ded91-7bc3-f5ea-f9e9-d4a32f6fa460@christopherschultz.net> Date: Thu, 29 Mar 2018 20:30:21 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6d70ef9a-006e-da04-92c4-57432d99eb70@apache.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9aamblCSndbpFAzQJ3t1LaREjVKekMJKz" --9aamblCSndbpFAzQJ3t1LaREjVKekMJKz Content-Type: multipart/mixed; boundary="m6zorzd38MXHzUuSO3gkoDUm9UDpaBq2I"; protected-headers="v1" From: Christopher Schultz To: dev@tomcat.apache.org Message-ID: <7d8ded91-7bc3-f5ea-f9e9-d4a32f6fa460@christopherschultz.net> Subject: Re: Request for comment on BZ 59750 (authentication listener) References: <624a29b7-9be4-202a-0310-148430ef7a6d@christopherschultz.net> <6d70ef9a-006e-da04-92c4-57432d99eb70@apache.org> In-Reply-To: <6d70ef9a-006e-da04-92c4-57432d99eb70@apache.org> --m6zorzd38MXHzUuSO3gkoDUm9UDpaBq2I Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Mark, On 3/29/18 4:11 PM, Mark Thomas wrote: > On 29/03/18 19:07, Christopher Schultz wrote: >> R=C3=A9my, >> >> On 3/29/18 11:41 AM, R=C3=A9my Maucherat wrote: >>> On Thu, Mar 29, 2018 at 3:48 PM, Christopher Schultz < >>> chris@christopherschultz.net> wrote: >>> >>>> All, >>>> >>>> For reference: https://bz.apache.org/bugzilla/show_bug.cgi?id=3D5975= 0 >>>> >>>> I've got a proposal (in patch form) attached to that BZ issue. >>>> >>>> Ralf's enhancement request is fairly terse, but this is something I'= d >>>> like to have as well. >>>> >>>> The requirement is to be able to log failed authentication attempts.= As >>>> it stands, using container-managed authentication does not allow thi= s >>>> (as far as I can tell). >>>> >>>> My proposal is essentially a new listener interface that authenticat= or >>>> classes will invoke (if registered) when an authentication event occ= urs >>>> (success or failure). The Request object and username are currently >>>> arguments to the two methods on the interface. >>>> >>>> You can read the entire current path without even scrolling your scr= een. >>>> >>>> Before attempting to publish a more complete patch, I wanted to know= if >>>> there was any appetite for this kind of thing, or any objections. >=20 > I think this is better than changing the existing Realm.authenticate(*)= > methods to add Request. Yes, I like this better, too. The separation-of-concerns is architecturally appropriate. > My biggest concern at this point is how does the listener get > registered? Why not attach it to the Authenticator valve? Most people don't explicitly declare their authenticator valve and let Tomcat auto-select based upon the auth-method. But most people don't need this new listener (not many people have mentioned this before, which is surprising ... maybe everyone's been using Spring Security forever), but if they do, they'll have to manually-configure the Valve. > Might this be better as ContainerListener and two new > events? That reduces the plumbing required to make this work. That would definitely require a dependency upon Tomcat code. I think it's worth the trade-off of plumbing-code versus dependencies. >>> Ok with the idea, but the patch is indeed very incomplete. >> >> Absolutely. I wanted to make sure there were no -1s before I spent muc= h >> time on it. That represents maybe 5 minutes of work :) >> >> Some specific questions: >> >> For FormAuthenticator: there are several calls to authenticate() in >> doAuthenticate. I chose to ignore the call at the top of the method >> because I didn't understand the purpose. Something about >> re-authentication of a previous-authentication? Would it be appropriat= e >> to also fire an authentication event at that time? >=20 > I don't think so. Okay, thanks for the confirmation. >> For Basic/DigestAuthenticator: since technically the user is being >> authenticated at *every* request, should we bother trying to avoid >> spamming the Listener, or should we let the Listener decide how to >> handle the huge number of events it will likely get? Does Tomcat know >> whether the authentication is a re-authentication or not? If so, shoul= d >> it let the Listener know this is a re-authentication? >=20 > Let the listener solve that problem. There may be different ways that > are appropriate for different use cases (client IP, session ID, etc.) +1 This was my nominal position as well... especially because it's less work in Tomcat. >> Implementing a listener in a webapp: can a listener be registered from= >> within the web application without any ClassLoader weirdness? >=20 > Yes. I was thinking about something that needed to depend upon the Tomcat API, but ... >> What options exist for writing a listener that doesn't require a >> compile-time dependency on Tomcat? (I suspect this is unavoidable, >> because even if reflection is used to invoke the listener's method >> by *name* and not via an interface-call, the Tomcat-specific >> Request class is a parameter to the interface methods. >=20 > Use HttpServletRequest? Or do you need access to Tomcat specific intern= als? I don't see a particular need to access Tomcat-specific internals at this point. I was just being lazy with the initial patch I guess. Thanks, -chris --m6zorzd38MXHzUuSO3gkoDUm9UDpaBq2I-- --9aamblCSndbpFAzQJ3t1LaREjVKekMJKz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlq9hR0ACgkQHPApP6U8 pFjyuxAAw3sfw+Pk6kLyYiPN6y1wqQ1JBbE8K+8VDEo6Iw9lt2/e9ry3mSPoRo/u dmpuHpbvGCJYpgSr3vCrKZB6uFvBap8u/539b7B15FWleCjz+c2Gy+7ID0Oms6Yw JLs0RbtbB1WKvfB1L4xupZOEcH7Qp9SXQS4LgS0i5ODTGmQEK4Iiwo2lxLza/tLy fIw02Vqo7BA7/BiNq+/ZygE4v/C/ugQ2xE/u1iJaxrzSOEqW/kp3GGaIgJEaLuKe zNkIOP4gT2yxZ0o3PpM975FrNsSDZSBp1GZ6UPdlSy0KRkONI0eBEgKB/2fL07z0 MyAUDLoTrdNs+xjar2muIcDeheK80WazqbF4pjbEQF3aExD1Qi+5LmKYDMlhrCgG zCEvgalr0Y+pnAJ44WixeFPtFkDkjYJXclVzMKdOZaUJxaKtgb87yG4A0R11NkDV gJUfQWdCE9fkX9LDUxxNjb9Wi/QcqmkQEATtpTA1M7gY04ytgJ8JAFRt0U9rsC4/ OhPYxz4fkXLo9EeK9+8LWTSBNLaDWfB7kK30sw11kUgFDdrGWDgRE1akzEYx2sto iIPEBWZSD3h2F4VPwTH19kn4E0R38VeBXD9X5Q8t3sLQRM0c/cVGw4bjd+NBXI+t rGCsO9bbV7CMq7ch52+e/QXak6QG9ZoaAaeJ/MxmLyWvfJnqr60= =EhsK -----END PGP SIGNATURE----- --9aamblCSndbpFAzQJ3t1LaREjVKekMJKz--