Re: basic auth required on https but not required on http
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Andrew, On 2/21/13 2:21 PM, Andrew Winter wrote: > On Wed, Feb 20, 2013 at 10:38 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > > André, > > On 2/20/13 1:40 PM, André Warnier wrote: Andrew Winter wrote: > On Wed, Feb 20, 2013 at 5:13 AM, André Warnier > wrote: Okay, I have this resolved, now. I > went with the FORM authentication method and created a > servlet that will create a login screen on an isSecure() > connection. For standard HTTP requests I pass over a self > submitting form with the credentials included. This will > work for the human interfaces and I will just have to deal > with any programmatic access problems as I find them. > You could probably just "force" an authenticated user into Tomcat (userPrincipal and that kind of thing) when the connection is internal. That would also probably solve your programmatic access case. > > Or just use HttpServletRequest.login(String username, String > password). No need to force an actual form. > > I have tried the HttpServletRequest.login(String username, String > password). I find that it works if I put it in the servlet I made > for the FORM login. But it requires a second request to actually > reach the page. The first request serves to authenticate only. Is > there a way to do this so that I can get to the web app with the > same request that does the log in? I'm not sure exactly what you mean. In a typical FORM login configuration, the user has to request a protected page /first/, and then gets a login form as a challenge. After successful authentication, the user is redirected to the original resource and all is well. For your users, they can skip the login form altogether. If they attempt to access a protected resource before you call login(), they will get the login page which isn't what you want. Instead, you want them to hit a separate, non-protected resource that can call login() if they are connecting over HTTPS. You might be able to do it like this: All users hit an unprotected resource, e.g. /access /access is mapped to a servlet that a) detects whether HTTPS is in use and b) calls login if HTTPS and redirects to "home" page or c) redirects to "home" page which triggers the contained-managed authentication described above. Users who are using HTTPS and directly-request protected pages will always get the login page -- there's no way around that without writing a Tomcat Valve and loading it earlier in the valve chain than the authenticator valve. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEmdW8ACgkQ9CaO5/Lv0PB1SQCfX8mtoJdqscZasFDEej2FnaPX Ou0AoJi0o5Jfj3Zn9sFDMOg0xmOhnvum =cgOw -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: basic auth required on https but not required on http
On Wed, Feb 20, 2013 at 10:38 PM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > André, > > On 2/20/13 1:40 PM, André Warnier wrote: > > Andrew Winter wrote: > >> On Wed, Feb 20, 2013 at 5:13 AM, André Warnier > >> wrote: Okay, I have this resolved, now. I went with the FORM > >> authentication method and created a servlet that will create a > >> login screen on an isSecure() connection. For standard HTTP > >> requests I pass over a self submitting form with the credentials > >> included. This will work for the human interfaces and I will > >> just have to deal with any programmatic access problems as I find > >> them. > >> > > You could probably just "force" an authenticated user into Tomcat > > (userPrincipal and that kind of thing) when the connection is > > internal. That would also probably solve your programmatic access > > case. > > Or just use HttpServletRequest.login(String username, String > password). No need to force an actual form. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEAREIAAYFAlEllrwACgkQ9CaO5/Lv0PCQeQCfV7OMDpuC7PnQK3pcCVksM5lg > MhcAn1TYFdV+9lXESMxeYOeXcYGrFyXi > =hSIr > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > I have tried the HttpServletRequest.login(String username, String password). I find that it works if I put it in the servlet I made for the FORM login. But it requires a second request to actually reach the page. The first request serves to authenticate only. Is there a way to do this so that I can get to the web app with the same request that does the log in?
Re: basic auth required on https but not required on http
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 André, On 2/20/13 1:40 PM, André Warnier wrote: > Andrew Winter wrote: >> On Wed, Feb 20, 2013 at 5:13 AM, André Warnier >> wrote: Okay, I have this resolved, now. I went with the FORM >> authentication method and created a servlet that will create a >> login screen on an isSecure() connection. For standard HTTP >> requests I pass over a self submitting form with the credentials >> included. This will work for the human interfaces and I will >> just have to deal with any programmatic access problems as I find >> them. >> > You could probably just "force" an authenticated user into Tomcat > (userPrincipal and that kind of thing) when the connection is > internal. That would also probably solve your programmatic access > case. Or just use HttpServletRequest.login(String username, String password). No need to force an actual form. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEAREIAAYFAlEllrwACgkQ9CaO5/Lv0PCQeQCfV7OMDpuC7PnQK3pcCVksM5lg MhcAn1TYFdV+9lXESMxeYOeXcYGrFyXi =hSIr -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: basic auth required on https but not required on http
Andrew Winter wrote: On Wed, Feb 20, 2013 at 5:13 AM, André Warnier wrote: The standard modus operandi of this list is to not top-post (makes it more difficult to follow the logical flow of conversation). So I've copied your response and my further comments at end. Andrew Winter wrote: I work on an intranet type application. While on the local network calls are made to regular http and authentication is not allowed due to a large number of established services that call the server without providing authentication. However, the server accepts calls from the outside over SSL (regular http port is blocked by firewall). In these cases the use of basic authentication is required. I don't see a way to have work like this. With our older setup we used Apache as a front end and had a virtual host file for each port. One used https and basic auth and the other didn't. Both pointed to the same web app. Now I must send calls directly to Tomcat as we are implementing asynchronous requests. What can I do here? Do the same as under httpd (except one thing) : use separate 's within the Tomcat configuration (same as under Apache). Deploy a separate copy of your webapps within each 's "appBase". In one , you protect them via Basic Auth, in the other you do not. Under Tomcat, it is not recommended to use the same "appBase" (roughly the same as Apache's "DocumentRoot") for two separate 's, because this creates problems of double deployment etc. So use two separate sets of webapps. They are still the same webapp, just deployed twice, in different locations. Is that a problem for you ? Roughly (check the proper syntax on tomcat.apache.org) : server.xml : ... ... ... /some/dir/number1 |- ROOT/ |- webapp1 |- webapp2 /some/dir/number2 |- ROOT/ |- webapp1 |- webapp2 the 2 "webapp1" are the same (same code, same files,..) (*) the 2 "webapp2" are the same (*) actually, almost the same, since their WEB-INF/web.xml will be different : one has to be accessed via HTTPS and use Basic Auth, the other one not. Andrew Winter wrote: Thanks. A lot of file IO goes on with this app. There are a couple of files in particular that are held open for the life of the app and written to sporadically. I am thinking that having the same code as two web apps would lead to those files getting clobbered. Is there a way to make the 'same appbase with 2 hosts' version work? On Feb 19, 2013 5:57 PM, "André Warnier" wrote: Well, at first I'd say no. Even if you were to point both appBase's at the same disk location (and turn off "auto-deploy" !), you would still logically have different "instances" of the webapp running at the same time (one for each host, at least). There are certainly other ways to achieve what you want to do, but I am getting a bit out of my depth here, so be careful of what I'm saying next, and maybe wait for other more qualified people's comments. One way that I could imagine would be to have a single with an alias, and wrap your webapp inside of a "servlet filter", which would check the host/port that the request came in from. If it came in through the HTTPS connection (or the appropriate HTTPS hostname, or a not-from-Intranet IP address), the filter would allow the request to proceed only if it is authenticated, and otherwise redirect it to a login page e.g. Maybe the URLRewriteFilter servlet filter (www.tuckey.org) would allow such a thing. It's a bit like the workhorse for things like that. Otherwise you'd have to write your own (or get it written). As a servlet-filter based solution, that would not require any modification to your webapp. It would not even know that it is being "wrapped" that way. There are certainly people on this list who would be available for a little job like that. (Not me though). Okay, I have this resolved, now. I went with the FORM authentication method and created a servlet that will create a login screen on an isSecure() connection. For standard HTTP requests I pass over a self submitting form with the credentials included. This will work for the human interfaces and I will just have to deal with any programmatic access problems as I find them. You could probably just "force" an authenticated user into Tomcat (userPrincipal and that kind of thing) when the connection is internal. That would also probably solve your programmatic access case. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: basic auth required on https but not required on http
On Wed, Feb 20, 2013 at 5:13 AM, André Warnier wrote: > The standard modus operandi of this list is to not top-post (makes it more > difficult to follow the logical flow of conversation). > So I've copied your response and my further comments at end. > > >> Andrew Winter wrote: >>> >>> I work on an intranet type application. While on the local network calls are made to regular http and authentication is not allowed due to a large number of established services that call the server without providing authentication. However, the server accepts calls from the outside over SSL (regular http port is blocked by firewall). In these cases the use of basic authentication is required. I don't see a way to have work like this. With our older setup we used Apache as a front end and had a virtual host file for each port. One used https and basic auth and the other didn't. Both pointed to the same web app. Now I must send calls directly to Tomcat as we are implementing asynchronous requests. What can I do here? Do the same as under httpd (except one thing) : use separate 's >>> within the Tomcat configuration (same as under Apache). >>> Deploy a separate copy of your webapps within each 's "appBase". In >>> one , you protect them via Basic Auth, in the other you do >>> not. >>> >>> Under Tomcat, it is not recommended to use the same "appBase" (roughly >>> the >>> same >>> as Apache's "DocumentRoot") for two separate 's, because this >>> creates problems of double deployment etc. So use two separate sets of >>> webapps. They are still the same webapp, just deployed twice, in >>> different >>> locations. Is that a problem for you ? >>> >>> Roughly (check the proper syntax on tomcat.apache.org) : >>> >>> server.xml : >>> >>> >>> >>> >>> >>> >>>... >>> >>> >>> >>>... >>> >>> >>> ... >>> >>> /some/dir/number1 >>> |- ROOT/ >>> |- webapp1 >>> |- webapp2 >>> >>> /some/dir/number2 >>> |- ROOT/ >>> |- webapp1 >>> |- webapp2 >>> >>> the 2 "webapp1" are the same (same code, same files,..) (*) >>> the 2 "webapp2" are the same >>> >>> (*) actually, almost the same, since their WEB-INF/web.xml will be >>> different : one has to be accessed via HTTPS and use Basic Auth, the >>> other >>> one not. >>> >>> >>> Andrew Winter wrote: > > Thanks. A lot of file IO goes on with this app. There are a couple of > files > > in particular that are held open for the life of the app and written to > > sporadically. I am thinking that having the same code as two web apps > would > > lead to those files getting clobbered. Is there a way to make the 'same > > appbase with 2 hosts' version work? > > On Feb 19, 2013 5:57 PM, "André Warnier" wrote: > > Well, at first I'd say no. Even if you were to point both appBase's at > the same disk location (and turn off "auto-deploy" !), you would still > logically have different "instances" of the webapp running at the same time > (one for each host, at least). > > There are certainly other ways to achieve what you want to do, but I am > getting a bit out of my depth here, so be careful of what I'm saying next, > and maybe wait for other more qualified people's comments. > > One way that I could imagine would be to have a single with an > alias, and wrap your webapp inside of a "servlet filter", which would check > the host/port that the request came in from. If it came in through the > HTTPS connection (or the appropriate HTTPS hostname, or a not-from-Intranet > IP address), the filter would allow the request to proceed only if it is > authenticated, and otherwise redirect it to a login page e.g. > Maybe the URLRewriteFilter servlet filter (www.tuckey.org) would allow > such a thing. It's a bit like the workhorse for things like that. > Otherwise you'd have to write your own (or get it written). > As a servlet-filter based solution, that would not require any > modification to your webapp. It would not even know that it is being > "wrapped" that way. > There are certainly people on this list who would be available for a > little job like that. > (Not me though). > > > > > Okay, I have this resolved, now. I went with the FORM authentication method and created a servlet that will create a login screen on an isSecure() connection. For standard HTTP requests I pass over a self submitting form with the credentials included. This will work for the human interfaces and I will just have to deal with any programmatic access problems as I find them. Thank you for all your help!
Re: basic auth required on https but not required on http
On Feb 20, 2013 5:13 AM, "André Warnier" wrote: > > The standard modus operandi of this list is to not top-post (makes it more difficult to follow the logical flow of conversation). > So I've copied your response and my further comments at end. > > >> >>> Andrew Winter wrote: >>> I work on an intranet type application. While on the local network calls are made to regular http and authentication is not allowed due to a large number of established services that call the server without providing authentication. However, the server accepts calls from the outside over SSL (regular http port is blocked by firewall). In these cases the use of basic authentication is required. I don't see a way to have work like this. With our older setup we used Apache as a front end and had a virtual host file for each port. One used https and basic auth and the other didn't. Both pointed to the same web app. Now I must send calls directly to Tomcat as we are implementing asynchronous requests. What can I do here? >>> Do the same as under httpd (except one thing) : use separate 's >>> within the Tomcat configuration (same as under Apache). >>> Deploy a separate copy of your webapps within each 's "appBase". In >>> one , you protect them via Basic Auth, in the other you do not. >>> >>> Under Tomcat, it is not recommended to use the same "appBase" (roughly the >>> same >>> as Apache's "DocumentRoot") for two separate 's, because this >>> creates problems of double deployment etc. So use two separate sets of >>> webapps. They are still the same webapp, just deployed twice, in different >>> locations. Is that a problem for you ? >>> >>> Roughly (check the proper syntax on tomcat.apache.org) : >>> >>> server.xml : >>> >>> >>> >>> >>> >>> >>>... >>> >>> >>> >>>... >>> >>> >>> ... >>> >>> /some/dir/number1 >>> |- ROOT/ >>> |- webapp1 >>> |- webapp2 >>> >>> /some/dir/number2 >>> |- ROOT/ >>> |- webapp1 >>> |- webapp2 >>> >>> the 2 "webapp1" are the same (same code, same files,..) (*) >>> the 2 "webapp2" are the same >>> >>> (*) actually, almost the same, since their WEB-INF/web.xml will be >>> different : one has to be accessed via HTTPS and use Basic Auth, the other >>> one not. >>> >>> > Andrew Winter wrote: > > Thanks. A lot of file IO goes on with this app. There are a couple of files > > in particular that are held open for the life of the app and written to > > sporadically. I am thinking that having the same code as two web apps would > > lead to those files getting clobbered. Is there a way to make the 'same > > appbase with 2 hosts' version work? > > On Feb 19, 2013 5:57 PM, "André Warnier" wrote: > > Well, at first I'd say no. Even if you were to point both appBase's at the same disk location (and turn off "auto-deploy" !), you would still logically have different "instances" of the webapp running at the same time (one for each host, at least). > > There are certainly other ways to achieve what you want to do, but I am getting a bit out of my depth here, so be careful of what I'm saying next, and maybe wait for other more qualified people's comments. > > One way that I could imagine would be to have a single with an alias, and wrap your webapp inside of a "servlet filter", which would check the host/port that the request came in from. If it came in through the HTTPS connection (or the appropriate HTTPS hostname, or a not-from-Intranet IP address), the filter would allow the request to proceed only if it is authenticated, and otherwise redirect it to a login page e.g. > Maybe the URLRewriteFilter servlet filter (www.tuckey.org) would allow such a thing. It's a bit like the workhorse for things like that. > Otherwise you'd have to write your own (or get it written). > As a servlet-filter based solution, that would not require any modification to your webapp. It would not even know that it is being "wrapped" that way. > There are certainly people on this list who would be available for a little job like that. > (Not me though). > > > > The problem I ran into earlier with the URLRewriteFilter servlet is that it broke the asynchronous request operation. It may be worth another try as that was when I was using the comet implementation and I have since rewritten it in the servlet api 3 version. I guess my only other option at this point would be to modify the tomcat source to add a port attribute to the web.xml section that defines which resources are too be secured with basic auth? > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: basic auth required on https but not required on http
The standard modus operandi of this list is to not top-post (makes it more difficult to follow the logical flow of conversation). So I've copied your response and my further comments at end. Andrew Winter wrote: I work on an intranet type application. While on the local network calls are made to regular http and authentication is not allowed due to a large number of established services that call the server without providing authentication. However, the server accepts calls from the outside over SSL (regular http port is blocked by firewall). In these cases the use of basic authentication is required. I don't see a way to have work like this. With our older setup we used Apache as a front end and had a virtual host file for each port. One used https and basic auth and the other didn't. Both pointed to the same web app. Now I must send calls directly to Tomcat as we are implementing asynchronous requests. What can I do here? Do the same as under httpd (except one thing) : use separate 's within the Tomcat configuration (same as under Apache). Deploy a separate copy of your webapps within each 's "appBase". In one , you protect them via Basic Auth, in the other you do not. Under Tomcat, it is not recommended to use the same "appBase" (roughly the same as Apache's "DocumentRoot") for two separate 's, because this creates problems of double deployment etc. So use two separate sets of webapps. They are still the same webapp, just deployed twice, in different locations. Is that a problem for you ? Roughly (check the proper syntax on tomcat.apache.org) : server.xml : ... ... ... /some/dir/number1 |- ROOT/ |- webapp1 |- webapp2 /some/dir/number2 |- ROOT/ |- webapp1 |- webapp2 the 2 "webapp1" are the same (same code, same files,..) (*) the 2 "webapp2" are the same (*) actually, almost the same, since their WEB-INF/web.xml will be different : one has to be accessed via HTTPS and use Basic Auth, the other one not. Andrew Winter wrote: > Thanks. A lot of file IO goes on with this app. There are a couple of files > in particular that are held open for the life of the app and written to > sporadically. I am thinking that having the same code as two web apps would > lead to those files getting clobbered. Is there a way to make the 'same > appbase with 2 hosts' version work? > On Feb 19, 2013 5:57 PM, "André Warnier" wrote: Well, at first I'd say no. Even if you were to point both appBase's at the same disk location (and turn off "auto-deploy" !), you would still logically have different "instances" of the webapp running at the same time (one for each host, at least). There are certainly other ways to achieve what you want to do, but I am getting a bit out of my depth here, so be careful of what I'm saying next, and maybe wait for other more qualified people's comments. One way that I could imagine would be to have a single with an alias, and wrap your webapp inside of a "servlet filter", which would check the host/port that the request came in from. If it came in through the HTTPS connection (or the appropriate HTTPS hostname, or a not-from-Intranet IP address), the filter would allow the request to proceed only if it is authenticated, and otherwise redirect it to a login page e.g. Maybe the URLRewriteFilter servlet filter (www.tuckey.org) would allow such a thing. It's a bit like the workhorse for things like that. Otherwise you'd have to write your own (or get it written). As a servlet-filter based solution, that would not require any modification to your webapp. It would not even know that it is being "wrapped" that way. There are certainly people on this list who would be available for a little job like that. (Not me though). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: basic auth required on https but not required on http
Thanks. A lot of file IO goes on with this app. There are a couple of files in particular that are held open for the life of the app and written to sporadically. I am thinking that having the same code as two web apps would lead to those files getting clobbered. Is there a way to make the 'same appbase with 2 hosts' version work? On Feb 19, 2013 5:57 PM, "André Warnier" wrote: > Andrew Winter wrote: > >> I work on an intranet type application. While on the local network calls >> are made to regular http and authentication is not allowed due to a large >> number of established services that call the server without providing >> authentication. However, the server accepts calls from the outside over >> SSL (regular http port is blocked by firewall). In these cases the use of >> basic authentication is required. I don't see a way to have work like >> this. With our older setup we used Apache as a front end and had a >> virtual >> host file for each port. One used https and basic auth and the other >> didn't. Both pointed to the same web app. Now I must send calls directly >> to Tomcat as we are implementing asynchronous requests. What can I do >> here? >> >> > Do the same as under httpd (except one thing) : use separate 's > within the Tomcat configuration (same as under Apache). > Deploy a separate copy of your webapps within each 's "appBase". In > one , you protect them via Basic Auth, in the other you do not. > > Under Tomcat, it is not recommended to use the same "appBase" (roughly the > same > as Apache's "DocumentRoot") for two separate 's, because this > creates problems of double deployment etc. So use two separate sets of > webapps. They are still the same webapp, just deployed twice, in different > locations. Is that a problem for you ? > > Roughly (check the proper syntax on tomcat.apache.org) : > > server.xml : > > > > > > >... > > > >... > > > ... > > /some/dir/number1 > |- ROOT/ > |- webapp1 > |- webapp2 > > /some/dir/number2 > |- ROOT/ > |- webapp1 > |- webapp2 > > the 2 "webapp1" are the same (same code, same files,..) (*) > the 2 "webapp2" are the same > > (*) actually, almost the same, since their WEB-INF/web.xml will be > different : one has to be accessed via HTTPS and use Basic Auth, the other > one not. > > > --**--**- > To unsubscribe, e-mail: > users-unsubscribe@tomcat.**apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: basic auth required on https but not required on http
Andrew Winter wrote: I work on an intranet type application. While on the local network calls are made to regular http and authentication is not allowed due to a large number of established services that call the server without providing authentication. However, the server accepts calls from the outside over SSL (regular http port is blocked by firewall). In these cases the use of basic authentication is required. I don't see a way to have work like this. With our older setup we used Apache as a front end and had a virtual host file for each port. One used https and basic auth and the other didn't. Both pointed to the same web app. Now I must send calls directly to Tomcat as we are implementing asynchronous requests. What can I do here? Do the same as under httpd (except one thing) : use separate 's within the Tomcat configuration (same as under Apache). Deploy a separate copy of your webapps within each 's "appBase". In one , you protect them via Basic Auth, in the other you do not. Under Tomcat, it is not recommended to use the same "appBase" (roughly the same as Apache's "DocumentRoot") for two separate 's, because this creates problems of double deployment etc. So use two separate sets of webapps. They are still the same webapp, just deployed twice, in different locations. Is that a problem for you ? Roughly (check the proper syntax on tomcat.apache.org) : server.xml : ... ... ... /some/dir/number1 |- ROOT/ |- webapp1 |- webapp2 /some/dir/number2 |- ROOT/ |- webapp1 |- webapp2 the 2 "webapp1" are the same (same code, same files,..) (*) the 2 "webapp2" are the same (*) actually, almost the same, since their WEB-INF/web.xml will be different : one has to be accessed via HTTPS and use Basic Auth, the other one not. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
