RE: Tomcat 8 and authenticating Basic Auth users
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 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: > BASIC > /opt/apache-tomcat-8.0.22/webapps/examples/WEB-INF/web.xml:272: > FORM > /opt/apache-tomcat-8.0.22/webapps/manager/WEB-INF/web.xml:165: > BASIC > >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
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 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: BASIC /opt/apache-tomcat-8.0.22/webapps/examples/WEB-INF/web.xml:272: FORM /opt/apache-tomcat-8.0.22/webapps/manager/WEB-INF/web.xml:165: BASIC 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
RE: Tomcat 8 and authenticating Basic Auth users
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: BASIC /opt/apache-tomcat-8.0.22/webapps/examples/WEB-INF/web.xml:272: FORM /opt/apache-tomcat-8.0.22/webapps/manager/WEB-INF/web.xml:165: BASIC 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 A
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 down
RE: Tomcat 8 and authenticating Basic Auth users
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)? 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 : --> What you could try is to copy the following tags to a non-commented-out section like this : 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 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 thi
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 : --> What you could try is to copy the following tags to a non-commented-out section like this : 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 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_Valve 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 alw
RE: Tomcat 8 and authenticating Basic Auth users
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? 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 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_Valve 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 /webapps/WEB-INF/myapp/web.xml file for each >> app has no security constraints. >> The /conf/web.xml file also has no security >> constraints. >> There is no web.xml file under >> /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 > "Author
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 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_Valve 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 /webapps/WEB-INF/myapp/web.xml file for each app has no security constraints. The /conf/web.xml file also has no security constraints. There is no web.xml file under /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
RE: Tomcat 8 and authenticating Basic Auth users
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. 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) I was told by the previous web admin that Basic Auth was turned off. 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 /webapps/WEB-INF/myapp/web.xml file for each > app has no security constraints. > The /conf/web.xml file also has no security > constraints. > There is no web.xml file under > /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: hea
Re: Tomcat 8 and authenticating Basic Auth users
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 Cc: Tony Esposito 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 serv
RE: Tomcat 8 and authenticating Basic Auth users
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 /webapps/WEB-INF/myapp/web.xml file for each app has no security constraints. The /conf/web.xml file also has no security constraints. There is no web.xml file under /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 > Cc: Tony Esposito > 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
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 Cc: Tony Esposito 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 happi
RE: Tomcat 8 and authenticating Basic Auth users
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). Tony -Original Message- From: Tony Esposito Sent: Friday, October 12, 2018 4:42 PM To: Tomcat Users List Cc: Tony Esposito 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 an
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 >>
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
RE: Tomcat 8 and authenticating Basic Auth users
Hello Christopher, 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? Tony -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 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 "authent
Re: Tomcat 8 and authenticating Basic Auth users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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:
RE: Tomcat 8 and authenticating Basic Auth users
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). 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. I need Tomcat to pass this request on through, ignoring the Basic Auth in the header. Tony -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 -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 &g
Re: Tomcat 8 and authenticating Basic Auth users
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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 > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvA9ScACgkQHPApP6U8 pFizahAAk4TDR1Jo5+xTNzQaeJxji8mwRl7LHj0FbSz3vwFwf6QHpWJHgIjzAQEV EdOnjUN7jpX1ux4Ehnh6wriBvrxbONPJjNbpfyKakvpjbb16VGX9mStvu/UnmR0P cPAZUHKQL1iZrYjas7+wby77kb2BeeeIaN8F7cJd/73HPciE2CvsVEM3pElRY27n lCLmHmFMYtUJfkPwvONMdTVVcT5RJqODk0D9l0Kg6cC3R9UbVu+IOwVgNWpkCxEw Wzw8cgICNFhI+cm1l9GZ2t9YmA61rvjwARBpAoVJX114nfC5sGwElHzaX5
RE: Tomcat 8 and authenticating Basic Auth users
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). 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? Tony Esposito Sr. ETL Developer / DBA Region 10 ESC Technology and Data Services O: 972-348-1284 -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
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
RE: Tomcat 8 and authenticating Basic Auth users
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
