But you still want your application to see this Basic Auth header, because it needs to check the "standard password" in it, right ? (Otherwise, describe precisely what you want).
If there is a way to disable Basic Auth (i.e. not compel the user to authenticate yet again) without triggering on the password or ignoring the header altogether, then the password is not important. I mentioned the password in the hopes that I could use it in some way to trigger the disabling of Basic Auth. P.S. 1) You say "Installed 'out of the box - as is'", but what box ? The standard Tomcats 8.0 or 8.5 do not have an active Connector for port 8088. So it does not look as if it is so 'out of the box - as is'. Where does that Tomcat come from, really ? It was installed by the previous admin -- I inherited it. Of course, there are other web apps on other ports. For example, there are 2 Connectors defined in the server.xml file. When I said 'as is' I was thinking in the context of Basic Auth. I have done nothing to change Basic Auth. 2) your application has a WEB-INF/web.xml file in it. What does it say about authentication ? The <TOMCAT_INSTALLED_DIRECTORY>/webapps/WEB-INF/myapp/web.xml file for each app has no security constraints. The <TOMCAT_INSTALLED_DIRECTORY>/conf/web.xml file also has no security constraints. There is no web.xml file under <TOMCAT_INSTALLED_DIRECTORY>/webapps/ROOT/WEB-INF. Was there anything in particular you were referring to? Tony -----Original Message----- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: Friday, October 12, 2018 6:54 PM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and authenticating Basic Auth users On 13.10.2018 00:04, Tony Esposito wrote: > Addendum: > The user "myuser" attempts to authenticate once, fails, and on the second > attempt the WARNING is thrown (i.e. user locked) which is to be expected. > I want the user "myuser" not to authenticate at all by having the Tomcat > instance 'ignore/bypass' the Basic Auth (that is received in the header). > But you still want your application to see this Basic Auth header, because it needs to check the "standard password" in it, right ? (Otherwise, describe precisely what you want). P.S. 1) You say "Installed 'out of the box - as is'", but what box ? The standard Tomcats 8.0 or 8.5 do not have an active Connector for port 8088. So it does not look as if it is so 'out of the box - as is'. Where does that Tomcat come from, really ? 2) your application has a WEB-INF/web.xml file in it. What does it say about authentication ? > Tony > > -----Original Message----- > From: Tony Esposito > Sent: Friday, October 12, 2018 4:42 PM > To: Tomcat Users List <users@tomcat.apache.org> > Cc: Tony Esposito <tony.espos...@region10.org> > Subject: RE: Tomcat 8 and authenticating Basic Auth users > > Hi Christopher, > The 'web server in question' is the Tomcat web server that I am trying > to get to ignore Basic Auth. > Installed 'out of the box - as is', this Tomcat web server instance > throws the error > > WARNING [http-nio-8088-exec-25] > org.apache.catalina.realm.LockOutRealm.authenticate An attempt was made to > authenticate the locked user "myuser" > > whenever a user (who has SSO'd successfully) tries to reach the web app > that runs on that Tomcat web server. > > Tony > > -----Original Message----- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Friday, October 12, 2018 3:33 PM > To: users@tomcat.apache.org > Subject: Re: Tomcat 8 and authenticating Basic Auth users > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Tony, > > On 10/12/18 16:24, Tony Esposito wrote: >> Some very good feedback here. Thank you. >> >> The web server in question doesn't need to authenticate any users at >> all. But, as a part of the SSO handoff, the web server in question >> is being passed Basic Auth in the header. >> >> Any further authentication (e.g. the examination of the header) is >> handled by the application. So, with regard to the web server in >> question, how to ignore the Basic Auth? > > What is "the web server in question"? Most web servers will ignore > authentication headers unless they have been specifically configured to do > something with it. You shouldn't have to do anything specific to get the web > server to ignore those headers. > > - -chris > >> -----Original Message----- From: Christopher Schultz >> [mailto:ch...@christopherschultz.net] Sent: Friday, October 12, >> 2018 3:07 PM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and >> authenticating Basic Auth users >> >> Tony, >> >> On 10/12/18 15:41, Tony Esposito wrote: >>> Concerning tomcat-user.xml versus database: The number of users has >>> increased by an order of 2 magnitudes AND we don't know ahead of >>> time who those users will be. The user count is an estimate of the >>> number of companies (known) multiplied by the number of users at >>> each company (unknown - we know it is greater than 1). >> Uhh... you need to authenticate users but you don't know who they are? >> This sounds like either you don't need authentication or you are >> doing something very dangerous. >> >> Perhaps you are trying to solve Y but you are asking about X. What is >> Y? What is the use-case, here? What are you protecting? Why do you >> need authentication? How are you expected to do it without being able >> to identify users? >> >> This seems like a good case for using CLIENT-CERT authentication >> where you trust each company's root cert and each employee at that >> company gets their cert issued by their company. There are problems >> with CLIENT-CERT authentication (like revocation is a PITA) but at >> least it fits the use-case better. >> >> Another option would be to tie-into each company's LDAP server. >> Then, they can use their own username+password just like they use for >> other services. >> >> Or, if you don't or can't implement the above, use something like >> SAML/OAuth to transfer a user from one trusted system (like a client >> company's system) into your own. You can request specific user >> information be set to you as a part of that SSO handoff and you can >> "register" them "locally" so you'll recognize them the next time they >> authenticate. >> >>> Concerning Basic Auth: >> >>> Users are already signed on via SSO thru another application. >>> And they cannot login directly to this application. A header is >>> passed to my web app which has the static password (so I can't do >>> much about that). (Yes, bad...bad...). Unfortunately, the header >>> also has Basic Auth passed to my application. >> You can always ignore that header. >> >>> I need Tomcat to pass this request on through, ignoring the Basic >>> Auth in the header. >> >> No problem: just remove all authentication and authorization >> configuration from web.xml and Tomcat will happily pass those headers >> to your application without doing anything to them. Tomcat will also >> happily pass that information to your application even if those >> headers are being used for authentication and authorization. >> >> -chris >> >>> -----Original Message----- From: Christopher Schultz >>> [mailto:ch...@christopherschultz.net] Sent: Friday, October 12, >>> 2018 2:25 PM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and >>> authenticating Basic Auth users >> >>> Tony, >> >>> On 10/12/18 14:45, Tony Esposito wrote: >>>> Thank you André for this feedback. >> >>>> If I may, I wish to approach this from another angle. (The user >>>> community is larger than at first anticipated). >> >>> Since you are switching away from tomcat-users.xml to a real data >>> store, why does a larger user community change things further? >> >>>> If the header received has a certain password (which is static for >>>> all users requesting access), then bypass Basic Auth and let the >>>> user connect. >> >>>> (The application does more security checking and authentication on >>>> the header.) >> >>>> So the question becomes: >> >>>> How to disable Basic Auth when the header contains a password which >>>> is static for all users requesting access? >>> This make zero sense. >> >>> HTTP Basic authentication will require the user to enter their >>> credentials. Once they enter their credentials, you'll inspect the >>> password for some magic value and then you want to retroactively >>> DISABLE HTTP Basic auth? I believe that requires timey-wimeyness. >> >>> Why not simply always require username+password, and then >>> opportunistically perform additional checks (as mentioned, but not >>> described) above? Once the user has authenticated successfully, the >>> browser will continue to send the >>> username+password with each successive request and the user won't >>> be asked again for their credentials. >> >>> The definition of "authenticated successfully" from the browser's >>> view is when the server stops sending the "WWW-Authenticate" >>> response header. >> >>> BTW static password == bad bad bad bad bad bad bad bad bad >> >>> If you have a static password, why bother asking for it in the first >>> place? It's like requiring a username + password for a terminal and >>> then stamping the username and password on the monitor. You may as >>> well remove the challenge. >> >>> -chris >> >>>> -----Original Message----- From: André Warnier (tomcat) >>>> [mailto:a...@ice-sa.com] Sent: Friday, October 12, 2018 11:29 AM >>>> To: users@tomcat.apache.org Subject: Re: Tomcat 8 and >>>> authenticating Basic Auth users >> >>>> Hi. >> >>>> On 12.10.2018 16:38, Tony Esposito wrote: >>>>> Hello, Using Tomcat 8.0.22 on Linux CentOS 6.10: >>>>> >>>>> Trying to setup Tomcat to authenticate users that use Basic Auth. >>>>> I could (possibly) enter these users into the tomcat-users.xml >>>>> file but we are dealing with 1000 potential users. >>>>> >>>>> What happens instead is (of course) the users fail to authenticate >>>>> and then subsequent attempts by the same user locks the user's >>>>> account. >>>>> >>>>> 11-Oct-2018 16:21:37.970 WARNING [http-nio-8088-exec-25] >>>>> org.apache.catalina.realm.LockOutRealm.authenticate An attempt was >>>>> made to authenticate the locked user "myuser" >>>>> >>>>> This is 'normal' since after a failed attempt to log in, Tomcat >>>>> suspects a 'brute force attack' and locks the account. >>>>> I don't want to lose that security but (as mentioned above) I >>>>> can't just enter all users into the tomcat-users.xml file >>>>> >>>>> So the basic question: How to do authentication of 1000 >>>>> users that use Basic Auth? >>>>> >>>>> Thanks. >>>>> >>>>> Tony >>>>> >>>>> >> >>>> There are two separate parts to this (and it is not specific to >>>> Tomcat) : >> >>>> - the "basic auth" part, is the way it talks to the browser, to get >>>> a userid/pw (in this case, through a browser popup dialog) >> >>>> - the "realm", is the way that the server *verifies* the >>>> user-id/pw, with some back-end "authority". In your case, you have >>>> specified that this realm is a file. But it can be something else, >>>> like a database. >> >>>> The two are independent, and you can mix and match according to >>>> your needs. The on-line Tomcat documentation helps, see : >>>> http://tomcat.apache.org/tomcat-8.5-doc/realm-howto.html >> >> >> >> >> >>>> ------------------------------------------------------------------- >>>> - > - - >> >>>> >>>> >> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >>>> ------------------------------------------------------------------- >>>> - > - - >> >>>> >>>> >> >>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >>> -------------------------------------------------------------------- >>> - >> >>> >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >>> -------------------------------------------------------------------- >>> - >> >>> >> >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >>> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> >> --------------------------------------------------------------------- >> >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvBBREACgkQHPApP6U8 > pFgzNg/+I4ervsW1nqgvLPhTZfsmrXnnegml7gOvs3e4W2RxYTMupOA+uDs0zX9D > LY7oHDKQsWDFsu0V+UUDGC5kMIDcv2rYiLoSDxVWeq01IvtMLAepZL0hAF1HGl1f > yc5CZnljXSQln+heOabULBsoWXAXSXRgXBUw5f0QbTOo5QNzVAmwNTqpHmmWvmcA > kCMwyGLbDu9uHfSvU5QaH8NEQeoLHhWUSoiVUtBzaEJyd5q5l20n+E+EGxlJL1/I > N4gSVbaJoqR2pah/MTxopbJCbJFbJCSwiurgdkxL5kt7PnubADBm+oxSP4Emgx1g > vZRuKtinAmCmJ15j5ORj/+EiIsCy58k+TVFByV78C0/pcL2v3FQTiG/HAPVugg3d > TXayWU2IQHgstZX9s0j4cEOt8RyLUrCtfRwWnJHsyKfU4hkW/A++tsu+IQRSmbgH > Pc3q8B/VtQ4iWSfB9hyEH0dTl0+W8dORmdEJfPXzOpQLyjhIZgBof4tB4HYQe18b > 8WNRFV7JbQ5kismfGXmixc9TrA4UiAnxP2zNjFLIyWF7sLcdgMMy4Wmhzz8aZR47 > y2EYrrU3L5LdMSFLs+qLrBPIMGDGmMo2AVNRSP7ZJv1I/poYFI+IpU7spuobSKOq > 6HWC5TmDF6sfbGb7cQLE8JgizxdqJR1i66pKz+uqXBk8haPG2Bw= > =99Rw > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
