Re: Basic and Form Authentication
Hi all, Winners never quit and quitters never win See. http://marc.info/?l=tomcat-userm=126047599208053w=2 Thanks for the assistance!!! Tony Anthony Jay wrote: yes, I was aware of this, as mentioned on a previous mail, but as its neither production ready nor complete it would be a huge risk. I am beginning to think that I am attempting the impossible... After several weeks banging my head against a wall (I have a sore neck) I am giving this one more day then giving up ;-( On this list, we dislike it when people give up. Give us all a feeling of failure. Come on, a bit of perseverance may be the key. What about my other post of yesterday, on the thread : Re: Contexts and Path and Authentication ? Does at least the initial description match what you would need ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
yes, I was aware of this, as mentioned on a previous mail, but as its neither production ready nor complete it would be a huge risk. I am beginning to think that I am attempting the impossible... After several weeks banging my head against a wall (I have a sore neck) I am giving this one more day then giving up ;-( Regards, Tony Hi. I got some (as yet partial) answers on this on the Apache httpd forum. Check out this : http://httpd.apache.org/docs/trunk/mod/mod_auth_form.html In summary, and subject to more confirmation by the Apache developers : A series of new Apache modules is due to appear in Apache 2.4 (the next production release version). They include mod_session and mod_auth_form, which should provide a generic form-based authentication framework. These modules are currently available in the test version of Apache (2.34). I do not know yet if they are, or can be, back-ported for Apache 2.2.14, the current production version. But all in all, it seems that this provides the as-yet missing standard form-based authentication framework which would be needed by the original poster on this thread, if he wanted to resolve his issue by using an httpd front-end (which he uses anyway for other purposes right now). Well, at least it would be a start. It remains to be seen in detail how one would set this up under Apache httpd. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Anthony Jay wrote: yes, I was aware of this, as mentioned on a previous mail, but as its neither production ready nor complete it would be a huge risk. I am beginning to think that I am attempting the impossible... After several weeks banging my head against a wall (I have a sore neck) I am giving this one more day then giving up ;-( On this list, we dislike it when people give up. Give us all a feeling of failure. Come on, a bit of perseverance may be the key. What about my other post of yesterday, on the thread : Re: Contexts and Path and Authentication ? Does at least the initial description match what you would need ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Hi. I got some (as yet partial) answers on this on the Apache httpd forum. Check out this : http://httpd.apache.org/docs/trunk/mod/mod_auth_form.html In summary, and subject to more confirmation by the Apache developers : A series of new Apache modules is due to appear in Apache 2.4 (the next production release version). They include mod_session and mod_auth_form, which should provide a generic form-based authentication framework. These modules are currently available in the test version of Apache (2.34). I do not know yet if they are, or can be, back-ported for Apache 2.2.14, the current production version. But all in all, it seems that this provides the as-yet missing standard form-based authentication framework which would be needed by the original poster on this thread, if he wanted to resolve his issue by using an httpd front-end (which he uses anyway for other purposes right now). Well, at least it would be a start. It remains to be seen in detail how one would set this up under Apache httpd. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 12/1/2009 6:57 AM, André Warnier wrote: Peter Crowther wrote: 2009/12/1 Anthony Jay anthony...@fastmail.fm: As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. This may be one of the few appropriate times where you may want to put code for the singletons (and all the classes that might be referenced by your singletons) in common/lib. It's not an ideal solution, but it may save you considerable effort as those classes will then be loaded by a single classloader, rather than the per-webapp classloaders. Or then, this may be a case where you want to explore front-ending these applications with an Apache httpd server, linked to Tomcat via an AJP connector. There is considerably more flexibility in Apache httpd regarding AAA (since for one it is not bound by the servlet spec), and once a request is authenticated, Apache and the connector will happily pass this authenticated id to Tomcat. And you would have to change nothing to your servlet-engine side code, singletons and all. Yeah, the problem is that AFAICT there is no standard way to do form-based authentication with Apache httpd. HTTP BASIC AUTH works wonderfully, but how would one implement form-based credential gathering? Is a custom module required for this, or does httpd come packaged with something that would work, even if a custom form /page/ would have to be developed that POSTs to a special URL? - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksWpSEACgkQ9CaO5/Lv0PD+jQCgm7QDsfdi+cfwF/n4mlo1ZHus bO0An1qrEFK3doN0l6D4zSkRREJ33YZ8 =vnb7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
On 02/12/2009 17:34, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 12/1/2009 6:57 AM, André Warnier wrote: Peter Crowther wrote: 2009/12/1 Anthony Jayanthony...@fastmail.fm: As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. This may be one of the few appropriate times where you may want to put code for the singletons (and all the classes that might be referenced by your singletons) in common/lib. It's not an ideal solution, but it may save you considerable effort as those classes will then be loaded by a single classloader, rather than the per-webapp classloaders. Or then, this may be a case where you want to explore front-ending these applications with an Apache httpd server, linked to Tomcat via an AJP connector. There is considerably more flexibility in Apache httpd regarding AAA (since for one it is not bound by the servlet spec), and once a request is authenticated, Apache and the connector will happily pass this authenticated id to Tomcat. And you would have to change nothing to your servlet-engine side code, singletons and all. Yeah, the problem is that AFAICT there is no standard way to do form-based authentication with Apache httpd. HTTP BASIC AUTH works wonderfully, but how would one implement form-based credential gathering? Is a custom module required for this, or does httpd come packaged with something that would work, even if a custom form /page/ would have to be developed that POSTs to a special URL? The only HTTPD module that supports form auth that I've heard of is mod_auth_cookie, but it's not included with the distribution has had, I believe, varying levels of support during its life. p - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksWpSEACgkQ9CaO5/Lv0PD+jQCgm7QDsfdi+cfwF/n4mlo1ZHus bO0An1qrEFK3doN0l6D4zSkRREJ33YZ8 =vnb7 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 12/1/2009 6:57 AM, André Warnier wrote: Peter Crowther wrote: 2009/12/1 Anthony Jay anthony...@fastmail.fm: As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. This may be one of the few appropriate times where you may want to put code for the singletons (and all the classes that might be referenced by your singletons) in common/lib. It's not an ideal solution, but it may save you considerable effort as those classes will then be loaded by a single classloader, rather than the per-webapp classloaders. Or then, this may be a case where you want to explore front-ending these applications with an Apache httpd server, linked to Tomcat via an AJP connector. There is considerably more flexibility in Apache httpd regarding AAA (since for one it is not bound by the servlet spec), and once a request is authenticated, Apache and the connector will happily pass this authenticated id to Tomcat. And you would have to change nothing to your servlet-engine side code, singletons and all. Yeah, the problem is that AFAICT there is no standard way to do form-based authentication with Apache httpd. HTTP BASIC AUTH works wonderfully, but how would one implement form-based credential gathering? Is a custom module required for this, or does httpd come packaged with something that would work, even if a custom form /page/ would have to be developed that POSTs to a special URL? Yes, the OP already hit that wall too. There exist a plethora of Apache/mod_perl modules that do that, available on CPAN, and being myself a mod_perl guy and using such modules all the time, I never throught it could be an issue. But strangely enough indeed, it does not appear that there exists a standard Apache module, part of the standard distribution, which handles form-based logins. I find that quite puzzling, and cannot quite believe this. I will enquire on the Apache forum about it. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Pid wrote: On 02/12/2009 17:34, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 12/1/2009 6:57 AM, André Warnier wrote: Peter Crowther wrote: 2009/12/1 Anthony Jayanthony...@fastmail.fm: As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. This may be one of the few appropriate times where you may want to put code for the singletons (and all the classes that might be referenced by your singletons) in common/lib. It's not an ideal solution, but it may save you considerable effort as those classes will then be loaded by a single classloader, rather than the per-webapp classloaders. Or then, this may be a case where you want to explore front-ending these applications with an Apache httpd server, linked to Tomcat via an AJP connector. There is considerably more flexibility in Apache httpd regarding AAA (since for one it is not bound by the servlet spec), and once a request is authenticated, Apache and the connector will happily pass this authenticated id to Tomcat. And you would have to change nothing to your servlet-engine side code, singletons and all. Yeah, the problem is that AFAICT there is no standard way to do form-based authentication with Apache httpd. HTTP BASIC AUTH works wonderfully, but how would one implement form-based credential gathering? Is a custom module required for this, or does httpd come packaged with something that would work, even if a custom form /page/ would have to be developed that POSTs to a special URL? The only HTTPD module that supports form auth that I've heard of is mod_auth_cookie, but it's not included with the distribution has had, I believe, varying levels of support during its life. At the last ApacheCON Europe in Amsterdam, there was I believe also talk about a new Apache mod_session module. But I've never seen any mention of it since. I'll ask about that too. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Thanks all for your comments, I do appreciate the expert assistance. As I suspected I will have to split the webapp into seperate apps based on the authentication method required. Seems like a funny way to arrange an application but such is life. As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. In terms of hacking code to fudge application access, this would be low on my list, I would not like to alter or maintain security related code. Many thanks again. (Much head scratching to continue) Tony -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony, On 11/30/2009 4:53 AM, Anthony Jay wrote: Is is possible to have an application that serves content protected by BASIC and FORM based auth? As Mark points out, the servlet spec says not in the same webapp. Tomcat implements the servlet specification and no more, so you are out of luck, there. I could deploy seperate apps for each type but I would then lose access to application specific information e.g. Singletons and Statics, which will cause big problems. I would strongly advise you to separate your webapps: one webapp for your XML-based API and the other for human interaction. Don't forget that your human UI could make use of the XML API behind the scenes. This is typically called drinking your own Cool-Aid. If it's possible for you to do so, you could put your shared singleton/static classes into a shared ClassLoader. What kinds of things are you using that you would need to share across webapps? Could those things be converted into services that both webapps could share? Note that an XML service whose URL contains a jsessionid parameter will be associated with the indicated session. You could use such a URL to avoid the FORM authentication (but getting the session id is, of course, an issue unresolved by this). Finally, you could go out on your own and implement your own authentication mechanism. Securityfilter is a simple, filter-based authentication and authorization mechanism that you could hack-up to do this type of thing. Actually, you could use it out-of-the-box and just use a Filter configured /in front/ of it to trick sf into trusting a Principal configured by your Filter (which comes from the request's HTTP AUTH data). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUHsEACgkQ9CaO5/Lv0PD/jACeKCyBSKRnZtnso5EzEPROUMXO i74An09m3QZY0GTl47KplbdCSu/NG1wr =t+z3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
2009/12/1 Anthony Jay anthony...@fastmail.fm: As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. This may be one of the few appropriate times where you may want to put code for the singletons (and all the classes that might be referenced by your singletons) in common/lib. It's not an ideal solution, but it may save you considerable effort as those classes will then be loaded by a single classloader, rather than the per-webapp classloaders. - Peter - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Peter Crowther wrote: 2009/12/1 Anthony Jay anthony...@fastmail.fm: As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. This may be one of the few appropriate times where you may want to put code for the singletons (and all the classes that might be referenced by your singletons) in common/lib. It's not an ideal solution, but it may save you considerable effort as those classes will then be loaded by a single classloader, rather than the per-webapp classloaders. Or then, this may be a case where you want to explore front-ending these applications with an Apache httpd server, linked to Tomcat via an AJP connector. There is considerably more flexibility in Apache httpd regarding AAA (since for one it is not bound by the servlet spec), and once a request is authenticated, Apache and the connector will happily pass this authenticated id to Tomcat. And you would have to change nothing to your servlet-engine side code, singletons and all. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Hi, Thanks for the great advice. On placing singletons etc in jar libraries in tommcat /lib directory, that would be a very simple hack that could keep code pretty much as is. Thank you for that suggestion, it may well be a runner, I didnt think that was possible. In terms of fronting everything with apache, I am currently doing this already via mod_jk (loadbalancing to 2 tomcats), although I might use mod_proxy_ajp in future as it is now bundled with apache2. However, I could not find any viable implementation for form based authentication, although there is one in the pipeline but may not be available in a stable form for many months to come. That was a big disappointment! Many thanks, Tony Peter Crowther wrote: 2009/12/1 Anthony Jay anthony...@fastmail.fm: As for cross application communication I will have to revisit our own code to see if there are static/singleton services that can be re-engineered and decoupled. This may be one of the few appropriate times where you may want to put code for the singletons (and all the classes that might be referenced by your singletons) in common/lib. It's not an ideal solution, but it may save you considerable effort as those classes will then be loaded by a single classloader, rather than the per-webapp classloaders. Or then, this may be a case where you want to explore front-ending these applications with an Apache httpd server, linked to Tomcat via an AJP connector. There is considerably more flexibility in Apache httpd regarding AAA (since for one it is not bound by the servlet spec), and once a request is authenticated, Apache and the connector will happily pass this authenticated id to Tomcat. And you would have to change nothing to your servlet-engine side code, singletons and all. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Basic and Form Authentication
Hi, Is is possible to have an application that serves content protected by BASIC and FORM based auth? i.e. JSP protected by FORM Servlets that process XML use http BASIC? I could deploy seperate apps for each type but I would then lose access to application specific information e.g. Singletons and Statics, which will cause big problems. Any words of wisdom? Tony - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Anthony Jay wrote: Hi, Is is possible to have an application that serves content protected by BASIC and FORM based auth? i.e. JSP protected by FORM Servlets that process XML use http BASIC? There is a rather extensive description available here : http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html and it also points you to the relevant section of the Servlet Specification (2.4 or 2.5), section SRV 12.1 and following. From reading it in diagonals, to me it seems possible to do that, if the URLs for the two types of servlets above can be distinguished. But you may want to wait for a more authoritative answer than mine. The above is all about container-based security. There is another philosophy available, namely servlet-filter based security, which may do what you want. The expert on that is Christopher, who will be having a look here in a few hours. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
Anthony Jay wrote: Hi, Is is possible to have an application that serves content protected by BASIC and FORM based auth? i.e. JSP protected by FORM Servlets that process XML use http BASIC? The Servlet spec does not support this. There is a maximum of one login method allowed per web app. That doesn't you doing more, but you have to provide all of the authentication plumbing yourself. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Basic and Form Authentication
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony, On 11/30/2009 4:53 AM, Anthony Jay wrote: Is is possible to have an application that serves content protected by BASIC and FORM based auth? As Mark points out, the servlet spec says not in the same webapp. Tomcat implements the servlet specification and no more, so you are out of luck, there. I could deploy seperate apps for each type but I would then lose access to application specific information e.g. Singletons and Statics, which will cause big problems. I would strongly advise you to separate your webapps: one webapp for your XML-based API and the other for human interaction. Don't forget that your human UI could make use of the XML API behind the scenes. This is typically called drinking your own Cool-Aid. If it's possible for you to do so, you could put your shared singleton/static classes into a shared ClassLoader. What kinds of things are you using that you would need to share across webapps? Could those things be converted into services that both webapps could share? Note that an XML service whose URL contains a jsessionid parameter will be associated with the indicated session. You could use such a URL to avoid the FORM authentication (but getting the session id is, of course, an issue unresolved by this). Finally, you could go out on your own and implement your own authentication mechanism. Securityfilter is a simple, filter-based authentication and authorization mechanism that you could hack-up to do this type of thing. Actually, you could use it out-of-the-box and just use a Filter configured /in front/ of it to trick sf into trusting a Principal configured by your Filter (which comes from the request's HTTP AUTH data). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksUHsEACgkQ9CaO5/Lv0PD/jACeKCyBSKRnZtnso5EzEPROUMXO i74An09m3QZY0GTl47KplbdCSu/NG1wr =t+z3 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
