Hello André, Thank you. I would be curious to see what they come up with as a response.
Tony -----Original Message----- From: André Warnier (tomcat) [mailto:a...@ice-sa.com] Sent: Monday, October 15, 2018 9:13 AM To: users@tomcat.apache.org Subject: Re: Tomcat 8 and authenticating Basic Auth users Hi. I put this question to the tomcat devs in a previous post, but it was somewhat lost in the volume I guess, so here it goes again : @ tomcat devs : If a HTTP request to Tomcat 8.0/8.5, in an unsollicited way (meaning without a previous 401 response), were to provide a "Authorization: Basic" header, would this trigger any Basic Auth code in Tomcat ? (I mean, even if the target app (not one of the ones below) does not seem to have any security-constraints or <auth-method> like stated below ?) We're trying to figure out why an app seems to be going through a Basic Auth (and rejecting it), although the app's web.xml contains no directives to that effect. On 15.10.2018 16:01, Tony Esposito wrote: > Hello André, > Yes, you understand the issue correctly. > Once again an excellent explanation. > > Using grep -rnw '/opt/apache-tomcat-8.0.22/' -e 'auth-method' and logged > in as 'root', I have only been able to find auth-method in the following > files: > > /opt/apache-tomcat-8.0.22/webapps/host-manager/WEB-INF/web.xml:110: > <auth-method>BASIC</auth-method> > /opt/apache-tomcat-8.0.22/webapps/examples/WEB-INF/web.xml:272: > <auth-method>FORM</auth-method> > /opt/apache-tomcat-8.0.22/webapps/manager/WEB-INF/web.xml:165: > <auth-method>BASIC</auth-method> > > Absent that, I am going to toss around the Realm versus Valve approaches > and give 1 (or maybe both) a try. > Thank you. > > Tony > > -----Original Message----- > From: André Warnier (tomcat) [mailto:a...@ice-sa.com] > Sent: Sunday, October 14, 2018 3:58 PM > To: users@tomcat.apache.org > Subject: Re: Tomcat 8 and authenticating Basic Auth users > > On 14.10.2018 18:44, Tony Esposito wrote: >> Hello André, >> As always I appreciate your detailed response. >> >> The web server is indeed setup in this simplified, "basic" configuration >> (i.e. the tomcat-users.xml file and server.xml file are configured as you >> described). >> The password is always the same. However, the users (hence, the user >> names) are unknown and only over time will they we known. >> >> How does this change your suggestion? Could a database realm be the >> answer (as opposed to the tomcat-users.xml file)? >> > > Whether the back-end is a file or a database, to make it work you would need > to have the corresponding userid/password pairs anyway. > So no, my suggestion does not work in that case. > > As I understand it now : > - the Basic authentication is active, somehow, for your webapp > - the requests which come in for that webapp always have a Basic > "Authorization:" header, always with the same password part, but with a > user-id which varies > - you cannot modify the front-end application part, which sends these headers > in the first place > - you do not really care about the user-id, and (in a way) the password only > serves > (possibly) to distinguish requests which are valid (iow coming from the > front-end server), from those that are not (coming from elsewhere, if that is > possible) > - you want to avoid having and managing any kind of back-end database or file > which would have to contain all the users/passwords pairs > > In such circumstances, the real thing to do would be to disable the Basic > authentication for the webapp (which means you still need to find where it is > specified), and protect the access by some other means, for example by > blocking all requests which do NOT come from your front-end server (by IP > address e.g.). (There exists a Valve for that, which can be configured just > for that webapp if need be. See : > http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Remote_Address_Valve) > > Barring that, another way that I can imagine would be to create your own > Realm for the Basic auth. It could be totally dummy and have no users file > back-end at all, since you only want to compare the password to some known > fixed value. > Like all Tomcat code, the code for the existing Realms is open-source and > available, so you could take one of them and modify it for that. > I am not really a Java programmer, so I would not try that myself, but I > would imagine that for any Real Java Programmer that would not be a big > problem. > > You could even think about creating your own Valve, which would > (subrepticiously) modify the incoming requests' Authorization headers, to > replace the varying user-id part by a single user-id, which would then be the > single one you need in the tomcat-users.xml file (or whatever other back-end > is in use). > > Now all of these things are somewhat flaky, and certainly weaken the security > of your server. That may impact not only /your/ webapp, but also everything > else that runs on that same server. If that server is on the Internet, you > should really think twice. > (I would at least consider running this connection over HTTPS, if you can). > > > >> Tony >> >> -----Original Message----- >> From: André Warnier (tomcat) [mailto:a...@ice-sa.com] >> Sent: Sunday, October 14, 2018 5:55 AM >> To: users@tomcat.apache.org >> Subject: Re: Tomcat 8 and authenticating Basic Auth users >> >> On 14.10.2018 02:29, Tony Esposito wrote: >>> Hello André, >>> >>> It's routed through a server... >>> A co-worker noticed a Tomcat valve that might do the trick... >>> https://github.com/lokechenlin/tomcat-auto-login-valve >>> >>> Your thoughts? >>> >> >> They are as follows : >> If that works, fine. >> But as per Occam's razor principle, one should not introduce more complexity >> than necessary. One additional dependency risks adding additional burdens in >> terms of debugging, support, maintenance etc. >> >> And there shouldn't really be a need for anything additional. >> >> Assuming that indeed the intermediate routing server adds this Basic Auth >> header, with a certain user-id/password pair, and that this user/password is >> always the same. >> (That's a big if of course). >> And assuming that indeed something as yet unidentified in the webapp, >> introduces a need for Basic Auth, and that you cannot find it or remove it. >> Then the solution would be, to make sure that this Basic Auth succeeds. >> (One reason being, that the lockout Valve - which apparently is also >> present - would not lockout this user, if it's authentication >> succeeded.) >> >> To make the Basic Auth succeed, one would have to insure that the Tomcat >> Realm that is being used by this webapp to *verify* the correctness of this >> userid/password pair, indeed knows this userid/password pair, and responds >> positively when enquired from. >> >> Of course, this requires finding out first, which Realm is being used, to >> back-up this Basic Auth. And that also would require finding out which >> component wants this Basic Auth. >> But you can try at least one thing, just to check : >> In the standard "vanilla" Tomcat as downloaded from the Tomcat website, >> there is : >> - in the file conf/server.xml, a tag like : <Resource name="UserDatabase" >> auth="Container".. >> - this tag points to a file, normally : pathname="conf/tomcat-users.xml" >> - that file "conf/tomcat-users.xml", there is a section, normally >> commented-out, like : >> <!-- >> <role rolename="tomcat"/> >> <role rolename="role1"/> >> <user username="tomcat" password="<must-be-changed>" roles="tomcat"/> >> <user username="both" password="<must-be-changed>" >> roles="tomcat,role1"/> >> <user username="role1" password="<must-be-changed>" >> roles="role1"/> >> --> >> What you could try is to copy the following tags to a non-commented-out >> section like this : >> <role rolename="tomcat"/> >> <user username="(user-that-you know)" password="(password-that-you-know, in >> clear)" >> roles="tomcat"/> >> >> save the file, and restart tomcat. >> Then see if it works. >> >> Chances are, that whoever configured this app in the first place, took the >> path of least resistance, and configured that webapp for Basic Auth, using >> the simplest configuration available, which is the above using a simple file >> as the back-end for authentication. >> By making the changes above, you may make your mystery user/password known >> to this simple Realm, and so maybe now its authentication will succeed. >> >> >> >> @others : if any of the Tomcat devs is reading this, I am curious about >> something : >> If a HTTP request, in an unsollicited way, contains a Basic Auth >> "Authorization:" header, could this automatically trigger some Basic Auth >> code in Tomcat, even if the webapp being targeted does not have any such >> security constraints ? >> I would assume not, but just in case.. >> >> >> >>> Tony >>> >>> >>> -----Original Message----- >>> From: André Warnier (tomcat) [mailto:a...@ice-sa.com] >>> Sent: Saturday, October 13, 2018 4:38 PM >>> To: users@tomcat.apache.org >>> Subject: Re: Tomcat 8 and authenticating Basic Auth users >>> >>> On 13.10.2018 18:54, Tony Esposito wrote: >>>> Hello André, >>>> >>>> Thank you for taking the time to put together this excellent explanation. >>>> >>>> I do not have control over the server that is passing me the Basic Auth >>>> header, unfortunately. >>> >>> Ok, so to make things clearer : when Tomcat receives a request for this >>> "myapp" >>> application, where does this request come from ? >>> From a user browser, or from another server directly ? >>> >>>> >>>> You mentioned "In other words, there is no "trick" to add to stop Tomat >>>> trying to authenticate the client. By default, it doesn't. >>>> If it does, it is because it was asked to, by something added to the >>>> default configuration." >>>> >>>> Ok, maybe the server IS asking for Basic Auth. I inherited this >>>> server (and this dilemma) show how/where do I check to see if Basic >>>> Auth is 'on'? Because I don't see it and (less valid) >>> >>> That's the puzzle indeed, if the "myapp" webapp's web.xml does not contain >>> any <security-> thing, and neither does the general conf/web.xml (which >>> gets merged with every webapp's web.xml, so it was a good idea to check >>> there too). >>> >>> I think that you will have to activate (and look at) the Access Log, to >>> find out which requests really come into your server. >>> Look here : >>> http://tomcat.apache.org/tomcat-8.5-doc/config/valve.html#Access_Log_ >>> V alve The Access Log produces lines like this : >>> 127.0.0.1 - - [10/Oct/2017:17:54:41 +0200] "GET /favicon.ico HTTP/1.1" 200 >>> 21630 The penultimate value is the status code returned by Tomcat to the >>> client, for this request. The last value is the (data) size of the >>> response (excluding headers). >>> You will be looking for requests which trigger a status code 401. >>> If there are any, that is a clear sign that the corresponding application >>> (with the URL in the same line) has some auth. requirement. >>> >>> >>>> I was told by the previous web admin that Basic Auth was turned off. >>> >>> Disregard that. Basic Auth cannot be "turned off". It is an inherent part >>> of the code (of any webserver, because it is mandated by the HTTP RFC); it >>> is always there. >>> But it "activates" only when it is told to activate. >>> >>>> >>>> Thank you again for your time >>>> >>>> Tony >>>> >>>> >>>> -----Original Message----- >>>> From: André Warnier (tomcat) [mailto:a...@ice-sa.com] >>>> Sent: Saturday, October 13, 2018 7:53 AM >>>> To: users@tomcat.apache.org >>>> Subject: Re: Tomcat 8 and authenticating Basic Auth users >>>> >>>> On 13.10.2018 04:56, Tony Esposito wrote: >>>>> 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? >>>>> >>>> No. But that is strange. >>>> Not that this would imply in any way that I encourage you to set up some >>>> form of bastard authentication without really knowing what you're doing >>>> (obviously), but here are some pointers : >>>> >>>> A browser (or any respectful-of-the-HTTP-rfc client), will *send* an >>>> "Authorization: >>>> Basic" header (which contains a user-id and password in clear, just >>>> Base64-encoded) to a server, *only* after the following has happened : >>>> 1) the client makes a first request to the server, for some URL >>>> 2) the server checks if the requested resource is "protected". >>>> If not, it sends the resource to the client and that's then end of >>>> this request. >>>> 3) If the resource is protected, the server checks if the client's request >>>> already contains some form of authorization. If the "protection" indicates >>>> that this is protected by a "HTTP Basic authentication", then what the >>>> server will be looking for, is a "Authorization:" header, with a type >>>> "Basic". >>>> 4) if the request already contains such a header, the server decodes it >>>> into a user-id/password, and /then/ checks with whatever back-end is >>>> configured (can be a file, or a database, or whatever - that's what Tomcat >>>> calls a "Realm"), to see if these credentials are correct. >>>> 5) If the credentials are ok, the server returns the requested resource, >>>> and that's the end of the request. >>>> 6) If the credentials are not ok, the server returns a response to the >>>> client, with a "status code" 401, meaning "needs authentication". If the >>>> resource is protected by an authentication "Basic", then the server >>>> response will include a "WWW-authenticate: Basic" >>>> header. >>>> 7) when the client receives this response, if it is a browser, it will >>>> then popup a login dialog, to request the user-id/password from the user. >>>> When the user has entered that userid/pw, the client will re-send the same >>>> request to the server, but this time with a "Authorization:" header >>>> containing the userid/passwrd entered by the user. >>>> (If that client is not a browser, it is supposed to fetch a userid/pw from >>>> somewhere, and do the same). >>>> 8) go back to (2) >>>> >>>> That is how Basic Auth works, in the HTTP RFC and in Tomcat. >>>> >>>> There is something special about Basic Auth, in the sense that once >>>> a client has succesfully accessed a location on the server, it will >>>> keep sending the same >>>> Authorization: header for that same location, without prompting the user >>>> again, until you close the program and start anew. >>>> >>>> Now consider the above carefully, because it has some implications : >>>> a) the server will not send a 401 rsponse to the client, if the >>>> accessed resource is not protected by a Basic authentication >>>> b) without a 401 received from the server, a normal client will not >>>> send an "Authorization:" header >>>> c) if the client nevertheless sends an Authorization header, for a >>>> resource that is not protected on the server, the server will ignore >>>> this header >>>> >>>> So there is something wrong, either in your explanations so far, or in the >>>> configuration of your server, or the client, because the server should not >>>> be "challenging" the client (with a 401), unless the application which the >>>> client tries to access is protected by a Basic authentication. >>>> And the client should not be sending a Basic Authorization header, unless >>>> it has been challenged previously by the server (with a 401). >>>> >>>> Which comes back to something Christopher mentioned already a good while >>>> back, but which you seem to keep ignoring : if you do not want the client >>>> to try to authenticate, then do not protect your application. >>>> In other words, there is no "trick" to add to stop Tomat trying to >>>> authenticate the client. By default, it doesn't. If it does, it is because >>>> it was asked to, by something added to the default configuration. >>>> >>>> Now if you want the client to send a Basic Authorization, but you want >>>> Tomcat to ignore it, then tough luck, because the two go together. You >>>> cannot eat your cake and have it. >>>> >>>> The only way you could achieve that, is by writing your own "Realm", which >>>> always responds OK, no matter what the client-id/pw are. >>>> But there you are in uncharted and unsupported territory, so beware. >>>> >>>> >>>> >>>>> >>>>> 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 >>>>>>>> username+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 > --------------------------------------------------------------------- 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
