Using Tomcat 5.5 clustering, container managed security info does not propagate to other instances
hi all, we are having a problem with our Tomcat 5.5.9 cluster. We run 2 Tomcat instances on physically different machines. For security we use normal container managed security, configured in the web.xml. Session replication works fine, and session id's are same across the two instances. We only have trouble with the authentication. For instance, if you are logged in on instance1, if load balancer redirects subsequent request to instance2, you have to login again. Turning on Single Signon did not help. Does anybody know if we should be able to get this working, and how? Browsing through the Tomcat source code I noticed that very explicit the security Principal is not saved in a serialized session. Could this be the reason why login information is not propagated to other instances? Has anybody an idea why this is not done? Configuration: - OS: RH 4 - App server: Tomcat 5.5.9 - Session replication: in-memory, pooled - Load balancing via hardware load balancer (Cisco) tia, Dirk - Lost Boys creates and delivers internet mobile solutions - Dirk de Kok | Java Specialist Lost Boys B.V. | Joop Geesinkweg 209 | 1096 AV Amsterdam The Netherlands | Tel: +31 20 4604500 | Fax: +31 20 4604501 | [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] | www.lostboys.nl http://www.lostboys.nl/
Re: AW: Container Managed Security and mod_jk/Static Contents
If I use htaccess, is the user not going to be prompted an authentication dialog? That would be not so nice, if the user has already completed the form based authentication, and then has to authenticate for htaccess as well. I guess what I want to do is simply not possible and doesn't make sense. If Tomcat is bypassed by Apache for static content, how should it handle security for these requests. Edao, Aliye schrieb: Hi, Why don`t you use Apache to protect your static contents?? You might want to use .htaccess ?? http://www.csoft.net/docs/micro/htaccess.html.en Mit freundlichem Gru / kind regards Dr. Aliye Edao -Ursprngliche Nachricht- Von: Torsten Rmer [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 17. Juni 2005 00:42 An: Tomcat Users List Betreff: Container Managed Security and mod_jk/Static Contents Hello! In order to improve performance for static contents I have setup Apache with mod_jk. Now only Struts' *.do requests are served by Tomcat, the rest is done by Apache. Works fine. Now I want to restrict access to some resources using using container managed security. That also works fine, but, and that is now my question: I also want to protect static contents, but that won't work with container managed security, because these requests are handled by Apache and don't even make it to Tomcat. Of course I could just mount the contents to be protected to Tomcat, but then I'll lose the performance advantage of having them served by Apache. Do I have to live with that or do I have a stupid setup? Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container Managed Security and mod_jk/Static Contents
how do you authenticate ? basic ? form based ? - Original Message - From: Torsten Rmer [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Thursday, June 16, 2005 11:42 PM Subject: Container Managed Security and mod_jk/Static Contents Hello! In order to improve performance for static contents I have setup Apache with mod_jk. Now only Struts' *.do requests are served by Tomcat, the rest is done by Apache. Works fine. Now I want to restrict access to some resources using using container managed security. That also works fine, but, and that is now my question: I also want to protect static contents, but that won't work with container managed security, because these requests are handled by Apache and don't even make it to Tomcat. Of course I could just mount the contents to be protected to Tomcat, but then I'll lose the performance advantage of having them served by Apache. Do I have to live with that or do I have a stupid setup? Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container Managed Security and mod_jk/Static Contents
Sorry, should have mentioned that. Using form based authentication. Gurumoorthy schrieb: how do you authenticate ? basic ? form based ? - Original Message - From: Torsten Rmer [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Thursday, June 16, 2005 11:42 PM Subject: Container Managed Security and mod_jk/Static Contents Hello! In order to improve performance for static contents I have setup Apache with mod_jk. Now only Struts' *.do requests are served by Tomcat, the rest is done by Apache. Works fine. Now I want to restrict access to some resources using using container managed security. That also works fine, but, and that is now my question: I also want to protect static contents, but that won't work with container managed security, because these requests are handled by Apache and don't even make it to Tomcat. Of course I could just mount the contents to be protected to Tomcat, but then I'll lose the performance advantage of having them served by Apache. Do I have to live with that or do I have a stupid setup? Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Container Managed Security and mod_jk/Static Contents
Hello! In order to improve performance for static contents I have setup Apache with mod_jk. Now only Struts' *.do requests are served by Tomcat, the rest is done by Apache. Works fine. Now I want to restrict access to some resources using using container managed security. That also works fine, but, and that is now my question: I also want to protect static contents, but that won't work with container managed security, because these requests are handled by Apache and don't even make it to Tomcat. Of course I could just mount the contents to be protected to Tomcat, but then I'll lose the performance advantage of having them served by Apache. Do I have to live with that or do I have a stupid setup? Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Container Managed Security and mod_jk/Static Contents
Hi, Why don`t you use Apache to protect your static contents?? You might want to use .htaccess ?? http://www.csoft.net/docs/micro/htaccess.html.en Mit freundlichem Gru / kind regards Dr. Aliye Edao -Ursprngliche Nachricht- Von: Torsten Rmer [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 17. Juni 2005 00:42 An: Tomcat Users List Betreff: Container Managed Security and mod_jk/Static Contents Hello! In order to improve performance for static contents I have setup Apache with mod_jk. Now only Struts' *.do requests are served by Tomcat, the rest is done by Apache. Works fine. Now I want to restrict access to some resources using using container managed security. That also works fine, but, and that is now my question: I also want to protect static contents, but that won't work with container managed security, because these requests are handled by Apache and don't even make it to Tomcat. Of course I could just mount the contents to be protected to Tomcat, but then I'll lose the performance advantage of having them served by Apache. Do I have to live with that or do I have a stupid setup? Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container Managed Security?
Use LDAP Based authentication ... I have this working very nicely only our servers Read JNDI Realm topic of tomcat Gurus - Original Message - From: Bjørn T Johansen [EMAIL PROTECTED] To: 'Tomcat Users List' tomcat-user@jakarta.apache.org Sent: Thursday, April 07, 2005 7:05 AM Subject: Container Managed Security? I have a small question... I am used to providing my own authentication system when developing web systems, but I am now looking into providing container based security instead. But when writing authentication myself, I have full control and can put differenf information that I need into the session scope. How do I do this using Tomcat's FORM-based authentication? Is there some listener I can hook onto or similar? Regards, BTJ -- -- - Bjørn T Johansen [EMAIL PROTECTED] -- - Someone wrote: I understand that if you play a Windows CD backwards you hear strange Satanic messages To which someone replied: It's even worse than that; play it forwards and it installs Windows -- - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container Managed Security?
That doesn't help with my problem, does it? I need to create a session object when a user logs in, is this possible? BTJ Gurumoorthy wrote: Use LDAP Based authentication ... I have this working very nicely only our servers Read JNDI Realm topic of tomcat Gurus - Original Message - From: Bjørn T Johansen [EMAIL PROTECTED] To: 'Tomcat Users List' tomcat-user@jakarta.apache.org Sent: Thursday, April 07, 2005 7:05 AM Subject: Container Managed Security? I have a small question... I am used to providing my own authentication system when developing web systems, but I am now looking into providing container based security instead. But when writing authentication myself, I have full control and can put differenf information that I need into the session scope. How do I do this using Tomcat's FORM-based authentication? Is there some listener I can hook onto or similar? Regards, BTJ -- -- - Bjørn T Johansen [EMAIL PROTECTED] -- - Someone wrote: I understand that if you play a Windows CD backwards you hear strange Satanic messages To which someone replied: It's even worse than that; play it forwards and it installs Windows -- - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container Managed Security?
javax.servlet.http.SessionListener For a summary, read the javadocs. For full details read the spec. Mark Bjørn T Johansen wrote: I have a small question... I am used to providing my own authentication system when developing web systems, but I am now looking into providing container based security instead. But when writing authentication myself, I have full control and can put differenf information that I need into the session scope. How do I do this using Tomcat's FORM-based authentication? Is there some listener I can hook onto or similar? Regards, BTJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container Managed Security?
Opps. Typo. That should be: javax.servlet.http.HttpSessionListener Mark Thomas wrote: javax.servlet.http.SessionListener For a summary, read the javadocs. For full details read the spec. Mark Bjørn T Johansen wrote: I have a small question... I am used to providing my own authentication system when developing web systems, but I am now looking into providing container based security instead. But when writing authentication myself, I have full control and can put differenf information that I need into the session scope. How do I do this using Tomcat's FORM-based authentication? Is there some listener I can hook onto or similar? Regards, BTJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container Managed Security?
That seems to be what I am looking for I will look into this... Thx... :) BTJ Mark Thomas wrote: Opps. Typo. That should be: javax.servlet.http.HttpSessionListener Mark Thomas wrote: javax.servlet.http.SessionListener For a summary, read the javadocs. For full details read the spec. Mark Bjørn T Johansen wrote: I have a small question... I am used to providing my own authentication system when developing web systems, but I am now looking into providing container based security instead. But when writing authentication myself, I have full control and can put differenf information that I need into the session scope. How do I do this using Tomcat's FORM-based authentication? Is there some listener I can hook onto or similar? Regards, BTJ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Container Managed Security?
I have a small question... I am used to providing my own authentication system when developing web systems, but I am now looking into providing container based security instead. But when writing authentication myself, I have full control and can put differenf information that I need into the session scope. How do I do this using Tomcat's FORM-based authentication? Is there some listener I can hook onto or similar? Regards, BTJ -- --- Bjørn T Johansen [EMAIL PROTECTED] --- Someone wrote: I understand that if you play a Windows CD backwards you hear strange Satanic messages To which someone replied: It's even worse than that; play it forwards and it installs Windows --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to disable PUT, DELETE http methods etc if not using container managed security?
Sorry, I blanked on this one. You also need the http-methodGET/http-method etc on the second (SSL) constraint. It's a pain, but the servlet-spec says you get the least restrictive combination of constraints. Ted Anagnost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Thanks Bill but I'm not sure it's working. Per your suggestion here's what I have now: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method http-methodPUT/http-method http-methodDELETE/http-method http-methodTRACE/http-method http-methodOPTIONS/http-method /web-resource-collection auth-constraint / /security-constraint security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint But, how do I verify that PUT's and DELETE's are blocked now? My vulnerability scanner still shows them as open: It seems that the PUT method is enabled on your web server Although we could not exploit this, you'd better disable it Solution : disable this method Risk factor : High BID : 12141 If I try to delete index.jsp through a telnet session: DELETE /index.jsp HTTP/1.1 I get this as a response: HTTP/1.1 400 Bad Request What's a good way to verify that DELETE is blocked? Can someone give a definitive test? Thanks - Original Message - From: Bill Barker [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Saturday, February 26, 2005 3:33 PM Subject: Re: How to disable PUT, DELETE http methods etc if not using container managed security? For TC 5.x.x, you need two security-constraints to do what you want. One of them looks like your first example, and the other like your second example (except that you probably want auth-constraint /, which is deny all, instead of role-name/ which is deny to all but the blank role). Since you are forbidding all access, you could also drop the user-data-constraint on the second one (since with it, TC will first redirect a PUT to SSL, and then deny it). Ted Anagnost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there a way to prevent PUT or DELETE http methods if you're not using container managed security? If so, how? I already have this to force the use of https: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint What changes are needed? I tried this but it didn't seem to work: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method -- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Inserting these statements seems to turn off the automatic enforcement of https which was achieved with the first version. Any ideas? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to disable PUT, DELETE http methods etc if not using container managed security?
Thanks Bill but I'm not sure it's working. Per your suggestion here's what I have now: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method http-methodPUT/http-method http-methodDELETE/http-method http-methodTRACE/http-method http-methodOPTIONS/http-method /web-resource-collection auth-constraint / /security-constraint security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint But, how do I verify that PUT's and DELETE's are blocked now? My vulnerability scanner still shows them as open: It seems that the PUT method is enabled on your web server Although we could not exploit this, you'd better disable it Solution : disable this method Risk factor : High BID : 12141 If I try to delete index.jsp through a telnet session: DELETE /index.jsp HTTP/1.1 I get this as a response: HTTP/1.1 400 Bad Request What's a good way to verify that DELETE is blocked? Can someone give a definitive test? Thanks - Original Message - From: Bill Barker [EMAIL PROTECTED] To: tomcat-user@jakarta.apache.org Sent: Saturday, February 26, 2005 3:33 PM Subject: Re: How to disable PUT, DELETE http methods etc if not using container managed security? For TC 5.x.x, you need two security-constraints to do what you want. One of them looks like your first example, and the other like your second example (except that you probably want auth-constraint /, which is deny all, instead of role-name/ which is deny to all but the blank role). Since you are forbidding all access, you could also drop the user-data-constraint on the second one (since with it, TC will first redirect a PUT to SSL, and then deny it). Ted Anagnost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there a way to prevent PUT or DELETE http methods if you're not using container managed security? If so, how? I already have this to force the use of https: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint What changes are needed? I tried this but it didn't seem to work: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method -- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Inserting these statements seems to turn off the automatic enforcement of https which was achieved with the first version. Any ideas? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to disable PUT, DELETE http methods etc if not using container managed security?
transport-guaranteeCONFIDENTIAL/transport-guarantee means that request must be encrypted (use ssl) Unless the default servlet (in conf/web.xml) is configured to allow put and delete - there is not worry. (As long as your don't write any servlets to handle put and delete) -Tim Ted Anagnost wrote: Is there a way to prevent PUT or DELETE http methods if you're not using container managed security? If so, how? I already have this to force the use of https: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint What changes are needed? I tried this but it didn't seem to work: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method-- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Inserting these statements seems to turn off the automatic enforcement of https which was achieved with the first version. Any ideas? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to disable PUT, DELETE http methods etc if not using container managed security?
For TC 5.x.x, you need two security-constraints to do what you want. One of them looks like your first example, and the other like your second example (except that you probably want auth-constraint /, which is deny all, instead of role-name/ which is deny to all but the blank role). Since you are forbidding all access, you could also drop the user-data-constraint on the second one (since with it, TC will first redirect a PUT to SSL, and then deny it). Ted Anagnost [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Is there a way to prevent PUT or DELETE http methods if you're not using container managed security? If so, how? I already have this to force the use of https: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint What changes are needed? I tried this but it didn't seem to work: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method-- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Inserting these statements seems to turn off the automatic enforcement of https which was achieved with the first version. Any ideas? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to disable PUT, DELETE http methods etc if not using container managed security?
Is there a way to prevent PUT or DELETE http methods if you're not using container managed security? If so, how? I already have this to force the use of https: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern /web-resource-collection !-- auth-constraint goes here if you requre authentication -- user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint What changes are needed? I tried this but it didn't seem to work: security-constraint web-resource-collection web-resource-nameProtected Context/web-resource-name url-pattern/*/url-pattern http-methodHEAD/http-method -- http-methodPUT/http-method-- http-methodDELETE/http-method -- http-methodTRACE/http-method-- http-methodOPTIONS/http-method -- /web-resource-collection auth-constraint role-name/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint Inserting these statements seems to turn off the automatic enforcement of https which was achieved with the first version. Any ideas? Thanks
RE: [newbie] Container Managed Security - preventing direct accessto .jsp
Thanks for the help and discussion Ben. /robert Yep, they look the same. Glad to help, even if I've done nothing more than validate your assumptions ;) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [newbie] Container Managed Security - preventing direct access to .jsp
I get what you are trying to do. I could be wrong, but the spec seems written more towards protecting data from unauthorized users rather than protecting jsp files from direct client access. Here are some suggestions I thought of: - Precompile the jsp source to .class files. Then remove the jsp source from the binary dist. - Introduce a token that's created in the controller servlet and removed in the jsp. If it doesn't exist when the jsp starts processing, the client made a direct access and the jsp can then do an internal forward to the controller or error page. - Write a filter to watch for direct jsp access and handle it. - Have the jsp analyze the request to determine whether it was called directly or via the internal forward mechanism and then do something about it. The first one is a must if you are worried about the client getting the jsp source somehow. The remaining three would help take care of the case where the jsp needs some data from the controller and will die a horrible death without it. I don't have code to share for these suggestions -- just trying to give you some ideas to work with. --David Robert Taylor wrote: I'm not trying to re-invent anything. I'm just trying to leverage the specification to secure resources. Personally I prefer WEB-INF to contain web application configuration and information resources instead of content and other non-configuration resources. IMHO, its intuitive that way. For anyone else that may even be remotely interested in this topic, some further googling produced some interesting results. I searched using the string: preventing direct access to .jsp files It appears that there is no standard way to do this even though it's implied in the spec. Here's a good example: http://forums.bea.com/bea/message.jspa?messageID=202433201 Oh well... /robert -Original Message- From: Hassan Schroeder [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 5:55 PM To: Tomcat Users List Subject: Re: [newbie] Container Managed Security - preventing direct access to .jsp Robert Taylor wrote: Does this not imply that I can do what I am trying to do? I suppose; I'm just baffled why you want to reinvent this particular built-in wheel, but don't let that stop you :-) -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct accessto .jsp
That is exactly how I want to do it. In fact, if you look at my original message I describe what you recommend almost exactly. Anyhow, I finally created a VERY simple security example web app with the following web.xml: ?xml version=1.0 encoding=ISO-8859-1? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 descriptionSimple Security Example/description display-nameSimple Security Example/display-name welcome-file-list welcome-fileindex.jsp/welcome-file /welcome-file-list error-page error-code403/error-code location/403.jsp/location /error-page security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/secure/*/url-pattern /web-resource-collection auth-constraint/ /security-constraint /web-app And it work! Yeeeha! Thanks for the help and discussion Ben. /robert -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 10:35 PM To: Tomcat Users List Subject: RE: [newbie] Container Managed Security - preventing direct accessto .jsp It appears that there is no standard way to do this even though it's implied in the spec. I don't know how standard this is but it works. The trick is in the auth-constraint node (note the commented out role-name). Since it is exclusive. Not declaring a role-name for the protected resource denies access to everyone. You then catch the 403 error with an error page mapping and you're good to go. The JSPs can still be accessed from the request dispatcher so you can reach them through the MVC pattern. I suppose a simpler solution would be simply to create a servelet-mapping with a url pattern of *.jsp and map it to an error servlet. If you want to test this out quickly grab the SimpleMVC.war from http://simple.souther.us and replace the web.xml file with this one. You'd have to create your own no-jsp-4-u.html page. Hope it helps -Ben ?xml version=1.0 encoding=ISO-8859-1? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 servlet servlet-name ControllerServlet /servlet-name servlet-class us.souther.simple.mvc.ControllerServlet/servlet-class /servlet servlet-mapping servlet-nameControllerServlet/servlet-name url-pattern/simple-mvc/url-pattern /servlet-mapping security-constraint web-resource-collection web-resource-name off-limits /web-resource-name url-pattern *.jsp /url-pattern /web-resource-collection auth-constraint !--role-name manager /role-name-- /auth-constraint /security-constraint error-page error-code403/error-code location/no-jsp-4-u.html/location /error-page /web-app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct access to .jsp
Ping... Please let me know if this questions is just too obvious and I'll gladly RTFM...even more. And yes, I know this list is not here just to serve _my_ interests. It just seems like a common idiom to provide a portable mechanism for protecting direct access to .jsp so as to enforce access through some controller. I have in the past placed .jsp files behind WEB-INF, but I don't believe that is portable and would like to use CMS to achieve this. Thanks again. /robert -Original Message- From: Robert Taylor [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 8:59 PM To: [EMAIL PROTECTED] Subject: [newbie] Container Managed Security - preventing direct access to .jsp Greetings, I'm new to Tomcat and this mailing list, and have a question regarding configuring Tomcat to simply disallow access to .jsp pages which I have been protected via the security-constraint/ in my web app web.xml file. From what I understand, the following should do the trick and cause a 403 error to be sent to the browser by the container. I would like to trap that error code and display a user friendly page (I chose any page so I would know it's working). I've simply modified the Tomcat jsp-examples web app. Here's a snippet of the necessary artifacts in the web.xml file. error-page error-code403/error-code location/dates/date.jsp/location /error-page security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/security/protected/*/url-pattern /web-resource-collection /security-constraint I believe the constraint is working, but I don't think the error-page/ is catching the 403 status code. This is probably because a 403 status code is not returned, but rather a 200 (I verified this by looking at the response headers). Anyhow, the content of the returned page is below within the content/: content You are logged in as remote user null in session D97EE937BEC953A7E82E42B3956AED86 No user principal could be identified. To check whether your username has been granted a particular role, enter it here: If you have configured this app for form-based authentication, you can log off by clicking here. This should cause you to be returned to the logon page after the redirect that is performed. /content I'm sure this has happened to someone else, I just cannot find where. I googled and didn't come up with much. I searched the archives using You are logged in as remote user null in session and no matches were found. Any help would be greatly appreciated. /robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct access to .jsp
Filters are portable. On Tue, 2004-12-14 at 12:32, Robert Taylor wrote: Ping... Please let me know if this questions is just too obvious and I'll gladly RTFM...even more. And yes, I know this list is not here just to serve _my_ interests. It just seems like a common idiom to provide a portable mechanism for protecting direct access to .jsp so as to enforce access through some controller. I have in the past placed .jsp files behind WEB-INF, but I don't believe that is portable and would like to use CMS to achieve this. Thanks again. /robert -Original Message- From: Robert Taylor [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 8:59 PM To: [EMAIL PROTECTED] Subject: [newbie] Container Managed Security - preventing direct access to .jsp Greetings, I'm new to Tomcat and this mailing list, and have a question regarding configuring Tomcat to simply disallow access to .jsp pages which I have been protected via the security-constraint/ in my web app web.xml file. From what I understand, the following should do the trick and cause a 403 error to be sent to the browser by the container. I would like to trap that error code and display a user friendly page (I chose any page so I would know it's working). I've simply modified the Tomcat jsp-examples web app. Here's a snippet of the necessary artifacts in the web.xml file. error-page error-code403/error-code location/dates/date.jsp/location /error-page security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/security/protected/*/url-pattern /web-resource-collection /security-constraint I believe the constraint is working, but I don't think the error-page/ is catching the 403 status code. This is probably because a 403 status code is not returned, but rather a 200 (I verified this by looking at the response headers). Anyhow, the content of the returned page is below within the content/: content You are logged in as remote user null in session D97EE937BEC953A7E82E42B3956AED86 No user principal could be identified. To check whether your username has been granted a particular role, enter it here: If you have configured this app for form-based authentication, you can log off by clicking here. This should cause you to be returned to the logon page after the redirect that is performed. /content I'm sure this has happened to someone else, I just cannot find where. I googled and didn't come up with much. I searched the archives using You are logged in as remote user null in session and no matches were found. Any help would be greatly appreciated. /robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [newbie] Container Managed Security - preventing direct access to .jsp
Robert Taylor wrote: Please let me know if this questions is just too obvious and I'll gladly RTFM... See below :-) It just seems like a common idiom to provide a portable mechanism for protecting direct access to .jsp so as to enforce access through some controller. I have in the past placed .jsp files behind WEB-INF, but I don't believe that is portable and would like to use CMS to achieve this. Given that the Java Servlet Specification Version 2.4, page 70 sez: A special directory exists within the application hierarchy named WEB-INF. This directory contains all things related to the application that aren't in the document root of the application. The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. I don't know how much more portable you want it to be :-) HTH! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct accessto .jsp
Yes. That would be an alternative approach. However, I want to use CMS (Container Managed Security) to protect direct access to .jsp pages. This should be possible as per the Servlet specification. /robert -Original Message- From: Ben Souther [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 1:16 PM To: Tomcat Users List Subject: RE: [newbie] Container Managed Security - preventing direct accessto .jsp Filters are portable. On Tue, 2004-12-14 at 12:32, Robert Taylor wrote: Ping... Please let me know if this questions is just too obvious and I'll gladly RTFM...even more. And yes, I know this list is not here just to serve _my_ interests. It just seems like a common idiom to provide a portable mechanism for protecting direct access to .jsp so as to enforce access through some controller. I have in the past placed .jsp files behind WEB-INF, but I don't believe that is portable and would like to use CMS to achieve this. Thanks again. /robert -Original Message- From: Robert Taylor [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 8:59 PM To: [EMAIL PROTECTED] Subject: [newbie] Container Managed Security - preventing direct access to .jsp Greetings, I'm new to Tomcat and this mailing list, and have a question regarding configuring Tomcat to simply disallow access to .jsp pages which I have been protected via the security-constraint/ in my web app web.xml file. From what I understand, the following should do the trick and cause a 403 error to be sent to the browser by the container. I would like to trap that error code and display a user friendly page (I chose any page so I would know it's working). I've simply modified the Tomcat jsp-examples web app. Here's a snippet of the necessary artifacts in the web.xml file. error-page error-code403/error-code location/dates/date.jsp/location /error-page security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/security/protected/*/url-pattern /web-resource-collection /security-constraint I believe the constraint is working, but I don't think the error-page/ is catching the 403 status code. This is probably because a 403 status code is not returned, but rather a 200 (I verified this by looking at the response headers). Anyhow, the content of the returned page is below within the content/: content You are logged in as remote user null in session D97EE937BEC953A7E82E42B3956AED86 No user principal could be identified. To check whether your username has been granted a particular role, enter it here: If you have configured this app for form-based authentication, you can log off by clicking here. This should cause you to be returned to the logon page after the redirect that is performed. /content I'm sure this has happened to someone else, I just cannot find where. I googled and didn't come up with much. I searched the archives using You are logged in as remote user null in session and no matches were found. Any help would be greatly appreciated. /robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct access to .jsp
Thanks Hassan. I didn't realize that was added to the 2.4 spec. Thanks for pointing that out. Even so, it would be nice to know how to use CMS to achieve this. Maybe a better way to form the question would be how do I use CMS to protect .jsp pages from direct access and return a user friendly page/message when a .jsp page is requested without going through the controller? /robert -Original Message- From: Hassan Schroeder [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 2:21 PM To: Tomcat Users List Subject: Re: [newbie] Container Managed Security - preventing direct access to .jsp Robert Taylor wrote: Please let me know if this questions is just too obvious and I'll gladly RTFM... See below :-) It just seems like a common idiom to provide a portable mechanism for protecting direct access to .jsp so as to enforce access through some controller. I have in the past placed .jsp files behind WEB-INF, but I don't believe that is portable and would like to use CMS to achieve this. Given that the Java Servlet Specification Version 2.4, page 70 sez: A special directory exists within the application hierarchy named WEB-INF. This directory contains all things related to the application that aren't in the document root of the application. The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. I don't know how much more portable you want it to be :-) HTH! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [newbie] Container Managed Security - preventing direct access to .jsp
I have not run into that kind of problem before... typically if you hit a JSP without hitting its controller first you will just get nothing (an HTML screen with no data). when it gets routed back to the controller, it will then register a failure due to lack of data. Problem solved. [EMAIL PROTECTED] 12-14-2004 12:20 Robert Taylor wrote: Please let me know if this questions is just too obvious and I'll gladly RTFM... See below :-) It just seems like a common idiom to provide a portable mechanism for protecting direct access to .jsp so as to enforce access through some controller. I have in the past placed .jsp files behind WEB-INF, but I don't believe that is portable and would like to use CMS to achieve this. Given that the Java Servlet Specification Version 2.4, page 70 sez: A special directory exists within the application hierarchy named WEB-INF. This directory contains all things related to the application that aren't in the document root of the application. The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. I don't know how much more portable you want it to be :-) HTH! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct access to .jsp
Fair enough. When I mention Container Managed Security, I am refering to using security constraints defined in web.xml to prevent direct access to resources. More specifically in Section 12.8 of the 2.4 specification: Security constraints are a declarative way of defining the protection of web content. A security constraint associates authorization and or user data constraints with HTTP operations on web resources. A security constraint, which is represented by security-constraint in deployment descriptor, consists of the following elements: web resource collection (web-resource-collection in deployment descriptor) authorization constraint (auth-constraint in deployment descriptor) user data constraint (user-data-constraint in deployment descriptor) The HTTP operations and web resources to which a security constraint applies (i.e. the constrained requests) are identified by one or more web resource collections. A web resource collection consists of the following elements: URL patterns (url-pattern in deployment descriptor) HTTP methods (http-method in deployment descriptor) An authorization constraint establishes a requirement for authentication and names the authorization roles permitted to perform the constrained requests. A user must be a member of at least one of the named roles to be permitted to perform the constrained requests. The special role name * is a shorthand for all role names defined in the deployment descriptor. An authorization constraint that names no roles indicates that access to the constrained requests must not be permitted under any circumstances. Does this not imply that I can do what I am trying to do? /robert -Original Message- From: Hassan Schroeder [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 5:07 PM To: Tomcat Users List Subject: Re: [newbie] Container Managed Security - preventing direct access to .jsp Robert Taylor wrote: I didn't realize that was added to the 2.4 spec. It was in 2.3, too. I'd guess it was in the spec from the get-go, but don't have an older copy to hand to confirm. Even so, it would be nice to know how to use CMS to achieve this. What is your definition of Container Managed Security, then, if not this? The container prevents direct access to the resources placed within WEB-INF, without you having to do anything else. Maybe a better way to form the question would be how do I use CMS to protect .jsp pages from direct access as above. and return a user friendly page/message when a .jsp page is requested without going through the controller? A custom 404 page should take care of it. And you can get as fancy with that as you like :-) FWIW! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [newbie] Container Managed Security - preventing direct access to .jsp
Robert Taylor wrote: Does this not imply that I can do what I am trying to do? I suppose; I'm just baffled why you want to reinvent this particular built-in wheel, but don't let that stop you :-) -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct access to .jsp
I'm not trying to re-invent anything. I'm just trying to leverage the specification to secure resources. Personally I prefer WEB-INF to contain web application configuration and information resources instead of content and other non-configuration resources. IMHO, its intuitive that way. For anyone else that may even be remotely interested in this topic, some further googling produced some interesting results. I searched using the string: preventing direct access to .jsp files It appears that there is no standard way to do this even though it's implied in the spec. Here's a good example: http://forums.bea.com/bea/message.jspa?messageID=202433201 Oh well... /robert -Original Message- From: Hassan Schroeder [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 5:55 PM To: Tomcat Users List Subject: Re: [newbie] Container Managed Security - preventing direct access to .jsp Robert Taylor wrote: Does this not imply that I can do what I am trying to do? I suppose; I'm just baffled why you want to reinvent this particular built-in wheel, but don't let that stop you :-) -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [newbie] Container Managed Security - preventing direct access to .jsp
Have you tried writing a session bean??? if not just write a session bean and import it as a header in all you *.jsp pages. The sessions will controll the flow of the application. ex: %@ include file=Secrity_stuff.jsp % This is common in writing applications. Robert Taylor wrote: Thanks Hassan. I didn't realize that was added to the 2.4 spec. Thanks for pointing that out. Even so, it would be nice to know how to use CMS to achieve this. Maybe a better way to form the question would be how do I use CMS to protect .jsp pages from direct access and return a user friendly page/message when a .jsp page is requested without going through the controller? /robert -Original Message- From: Hassan Schroeder [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 14, 2004 2:21 PM To: Tomcat Users List Subject: Re: [newbie] Container Managed Security - preventing direct access to .jsp Robert Taylor wrote: Please let me know if this questions is just too obvious and I'll gladly RTFM... See below :-) It just seems like a common idiom to provide a portable mechanism for protecting direct access to .jsp so as to enforce access through some controller. I have in the past placed .jsp files behind WEB-INF, but I don't believe that is portable and would like to use CMS to achieve this. Given that the Java Servlet Specification Version 2.4, page 70 sez: A special directory exists within the application hierarchy named WEB-INF. This directory contains all things related to the application that aren't in the document root of the application. The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. I don't know how much more portable you want it to be :-) HTH! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Dwayne A. Ghant Application Developer Temple University 215.204. [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [newbie] Container Managed Security - preventing direct access to .jsp
Robert Taylor wrote: I didn't realize that was added to the 2.4 spec. It was in 2.3, too. I'd guess it was in the spec from the get-go, but don't have an older copy to hand to confirm. Even so, it would be nice to know how to use CMS to achieve this. What is your definition of Container Managed Security, then, if not this? The container prevents direct access to the resources placed within WEB-INF, without you having to do anything else. Maybe a better way to form the question would be how do I use CMS to protect .jsp pages from direct access as above. and return a user friendly page/message when a .jsp page is requested without going through the controller? A custom 404 page should take care of it. And you can get as fancy with that as you like :-) FWIW! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [newbie] Container Managed Security - preventing direct access to .jsp
From: Hassan Schroeder [EMAIL PROTECTED] Given that the Java Servlet Specification Version 2.4, page 70 sez: A special directory exists within the application hierarchy named WEB-INF. This directory contains all things related to the application that aren't in the document root of the application. The WEB-INF node is not part of the public document tree of the application. No file contained in the WEB-INF directory may be served directly to a client by the container. I don't know how much more portable you want it to be :-) Except that I think at least one commercial Servlet container interpreted it more strictly and refused to serve anything under WEB-INF, even with a forward. IOW, the specification says the container MAY NOT serve anything under WEB-INF directly, but it doesn't say that the container MUST serve those things INdirectly. No idea which one that was, I just remember being warned when I put things under WEB-INF, that it wouldn't work everywhere. Since I never plan to use anything but Tomcat, it wasn't a problem. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct access to .jsp
It appears that there is no standard way to do this even though it's implied in the spec. I don't know how standard this is but it works. The trick is in the auth-constraint node (note the commented out role-name). Since it is exclusive. Not declaring a role-name for the protected resource denies access to everyone. You then catch the 403 error with an error page mapping and you're good to go. The JSPs can still be accessed from the request dispatcher so you can reach them through the MVC pattern. I suppose a simpler solution would be simply to create a servelet-mapping with a url pattern of *.jsp and map it to an error servlet. If you want to test this out quickly grab the SimpleMVC.war from http://simple.souther.us and replace the web.xml file with this one. You'd have to create your own no-jsp-4-u.html page. Hope it helps -Ben ?xml version=1.0 encoding=ISO-8859-1? web-app xmlns=http://java.sun.com/xml/ns/j2ee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd; version=2.4 servlet servlet-name ControllerServlet /servlet-name servlet-class us.souther.simple.mvc.ControllerServlet/servlet-class /servlet servlet-mapping servlet-nameControllerServlet/servlet-name url-pattern/simple-mvc/url-pattern /servlet-mapping security-constraint web-resource-collection web-resource-name off-limits /web-resource-name url-pattern *.jsp /url-pattern /web-resource-collection auth-constraint !--role-name manager /role-name-- /auth-constraint /security-constraint error-page error-code403/error-code location/no-jsp-4-u.html/location /error-page /web-app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[newbie] Container Managed Security - preventing direct access to .jsp
Greetings, I'm new to Tomcat and this mailing list, and have a question regarding configuring Tomcat to simply disallow access to .jsp pages which I have been protected via the security-constraint/ in my web app web.xml file. From what I understand, the following should do the trick and cause a 403 error to be sent to the browser by the container. I would like to trap that error code and display a user friendly page (I chose any page so I would know it's working). I've simply modified the Tomcat jsp-examples web app. Here's a snippet of the necessary artifacts in the web.xml file. error-page error-code403/error-code location/dates/date.jsp/location /error-page security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/security/protected/*/url-pattern /web-resource-collection /security-constraint I believe the constraint is working, but I don't think the error-page/ is catching the 403 status code. This is probably because a 403 status code is not returned, but rather a 200 (I verified this by looking at the response headers). Anyhow, the content of the returned page is below within the content/: content You are logged in as remote user null in session D97EE937BEC953A7E82E42B3956AED86 No user principal could be identified. To check whether your username has been granted a particular role, enter it here: If you have configured this app for form-based authentication, you can log off by clicking here. This should cause you to be returned to the logon page after the redirect that is performed. /content I'm sure this has happened to someone else, I just cannot find where. I googled and didn't come up with much. I searched the archives using You are logged in as remote user null in session and no matches were found. Any help would be greatly appreciated. /robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [newbie] Container Managed Security - preventing direct access to .jsp
Sorry. I left off some info: Tomcat 5.0.25 Win2k JDK1.4.2 /robert -Original Message- From: Robert Taylor [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 8:59 PM To: [EMAIL PROTECTED] Subject: [newbie] Container Managed Security - preventing direct access to .jsp Greetings, I'm new to Tomcat and this mailing list, and have a question regarding configuring Tomcat to simply disallow access to .jsp pages which I have been protected via the security-constraint/ in my web app web.xml file. From what I understand, the following should do the trick and cause a 403 error to be sent to the browser by the container. I would like to trap that error code and display a user friendly page (I chose any page so I would know it's working). I've simply modified the Tomcat jsp-examples web app. Here's a snippet of the necessary artifacts in the web.xml file. error-page error-code403/error-code location/dates/date.jsp/location /error-page security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/security/protected/*/url-pattern /web-resource-collection /security-constraint I believe the constraint is working, but I don't think the error-page/ is catching the 403 status code. This is probably because a 403 status code is not returned, but rather a 200 (I verified this by looking at the response headers). Anyhow, the content of the returned page is below within the content/: content You are logged in as remote user null in session D97EE937BEC953A7E82E42B3956AED86 No user principal could be identified. To check whether your username has been granted a particular role, enter it here: If you have configured this app for form-based authentication, you can log off by clicking here. This should cause you to be returned to the logon page after the redirect that is performed. /content I'm sure this has happened to someone else, I just cannot find where. I googled and didn't come up with much. I searched the archives using You are logged in as remote user null in session and no matches were found. Any help would be greatly appreciated. /robert - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Container managed security in tomcat 5.x, need j_password in struts web app, ServletFilter or IntermediateServlet? [Auf Viren geprüft]
Subject: Container managed security in tomcat 5.x, need j_password in struts web app, ServletFilter or IntermediateServlet? Background: = I'm writing a web front-end to a back-end system which has 1000 user accounts and each user has different rights (ACIs, ACLs) in that back-end (think of LDAP Directory, RDBMS, Filessystem = any Data-Store with user-dependend access-rights) I use J2EE, Tomcat 5.0.27, Struts 1.1+Tiles as front-end, Sun One LDAP as back-end. Requirement(s): - I want to user container managed security to leverage Realms and JNDI/JAAS. - I want to connect to the same back-end with the same user used by container managed security - Therefore I need principal *and* credential of that user by whatever means - authorization is not managed by security-roles in J2EE sphere but by security rules of backend which automatically apply to the logged on user Problem: authorization in back-end: == I can use container-managed security (JNDI-Realm) to authenticate users, *but* can't connect to the back-end as the current user because my application doesn't know the password(credential) of the current user. I can get the Principal, which is not enough. So I can't leverage the ACIs, ACLs of my Back-End System because I have to logon as Superuser/root/DBA who is allowed everything. Solution(s): = 1. Intermediate Servlet -- - User request protected resource - Container forwards to my configured login.jsp - User enters j_username and j_password and submits - login.jsp does not POST to container servlet /j_security_check directly but to by servlet which copies j_username and j_password in the session context and *then* forwards or redirects /j_security_check - Problem: /j_security_check as a servlet mapping magically disappeares by that time in Tomcat 5.0.x, so it complains it can't find '/j_security_check' :-P Part of my LoginAction: ActionForward forward = new ActionForward(); forward.setName(securityCheck); forward.setPath(/j_security_check); // forward.setPath(/../j_security_check); // forward.setPath(http://localhost:8080/j_security_check;); forward.setContextRelative(false); forward.setRedirect(false); // forward.setRedirect(true); 2. ServletFilter -- - User request protected resource - Container forwards to my configured login.jsp - User enters j_username and j_password and submits - login.jsp POSTS to /j_security_check - Container is configured as to apply MyServletFilter to the URL pattern /j_security_check - MyServletFilter gets the POSTed j_username, j_password out of the request, copies them into the session.context and chains to the Servlet /j_security_check which authentificates the user as normal - Problem: MyServletFilter gets called for all URL patterns with the one exeption being '/j_security_check'. :-P Part of my FilterMapping in web.xml: filter-mapping filter-nameLoginFilter/filter-name url-pattern/j_security_check/url-pattern dispatcherREQUEST/dispatcher dispatcherFORWARD/dispatcher /filter-mapping Part of my LoginFilter: log.warn(*** Executing LoginFilter doFilter()); chain.doFilter(request, response); Being J2EE conform? === Both solutions are J2EE conform. Standards were a bit ambigous at that point but I don't consider both solutions valid. The ServletFilter-solution is described for IBM Webpshere in developerWorks and the Intermediate Servlet was proposed by people on the tomcat mailing and seemed to work on tomcat 4.x Struts and Tiles: I use struts and tiles for the front-end. form-based authentification via login.jsp does work, even with struts and tiles, if I call /j_security_servlet directly in a non Struts-action. The Intermediate Servlet is my Action servlet from struts. j_username and j_password are in an action form bean. I use an ActionForward to '/j_security_check'. Because Struts appends the name of the web-app I tried '/../j_security_check' and 'http://localhost:8080/j_security_check' with forward or redirect but to no success. All *.do URLs are secure and protect be container-managed security. All resources to build the login.jsp are not protected. Subquestion: How do I forward to URIs outside my current web-app? Now it gets appended so I end up with /web-app/j_security_check which cannot be found? I don't think I'm the only one with this problem. What did I wrong? Did I overlook anything? Are my solutions valid. Are there more solutions? I don't want to use ServletFiltering for my proprietary SecurityFilter like the sourceforge.net project but stay with container-managed security. All help is welcome, TIA, Frerk Meyer EDEKA Aktiengesellschaft GB Datenverarbeitung Frerk Meyer CC Web Technologien New-York-Ring 6 22297 Hamburg Tel: 040/6377 - 3272 Fax: 040/6377 - 41268
Re: Container managed security in tomcat 5.x, need j_password in struts web app, ServletFilter or IntermediateServlet? [Auf Viren geprüft]
It sounds like you'll need to create your own realm. You might be able to extend JNDIRealm. You cannot run filters on /j_security_check. The spec says so. Websphere might allow it - but tomcat doesn't. -Tim [EMAIL PROTECTED] wrote: http://marc.theaimsgroup.com/?l=tomcat-userm=109282146309790w=2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security in tomcat 5.x, need j_password in struts web app, ServletFilter or IntermediateServlet? [Auf Viren geprüft]
Thanks Tim Funk for the quick answer,
In FormAuthenticator there is a line:
principal =
context.getRealm().authenticate(username, password);
It returns an
interface java.security.Principal
The Principal stores the username (uid), not the password (Credential).
I only can call getName().
Furthermore any Realm has no access to the users session.
So I can't get the password from the realm.
I could of course write the password as cleartext or obscured code in my
own Realm to an external
data store. But I don't want that. It's dirty and unsafe and against the
security requirements of
this web-app.
I've searched the Java Servlet Specification v.2.4
http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html
but haven't found a place where applying ServletFilters to
/j_security_check is forbidden.
Could you please provide me with an pointer to the spec you have forbidding
this kind
of filtering?
One of many same questions I have found on
http://www.mail-archive.com/[EMAIL PROTECTED]/msg117539.html
(Message 1117539 on this list)
was answered by yourself with the suggestion of using a valve.
Could you please me more detail on that solution?
On the same answer there was mentioned that BEA WebLogic provides a hook
named
auth-filter
which would solve my problem too (in a proprietary way). With Websphere
this is the second App-Server which could solve my problem.
I have a Sun ONE Web App Server 7 at hands, so will try eventually
the ServletFilter-method too.
Another thread on this list with the same requirement is number 111855:
servlet sendRedirect() to j_security_check problem (remember me)
http://www.mail-archive.com/[EMAIL PROTECTED]/msg111855.html
It announces Matt Raibles solution, programmed into his example application
AppFuse.
It works y submitting a subrequest vie HttpClient lib which seems rather
strange to me.
It cites an earlier posting number 111700
http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/msg111700.html
One more question:
In the Tomcat 5.0.27 source in FormAuthentificator.java it says
// Save the authenticated Principal in our session
session.setNote(Constants.FORM_PRINCIPAL_NOTE, principal);
// If we are not caching, save the username and password as well
if (!cache) {
session.setNote(Constants.SESS_USERNAME_NOTE, username);
session.setNote(Constants.SESS_PASSWORD_NOTE, password);
}
Am I able to session.getNote(Constants.SESS_PASSWORD_NOTE, password) in my
web-app?
It seems to be stored in the session, or am I wrong?
Frerk Meyer
EDEKA Aktiengesellschaft
GB Datenverarbeitung
Frerk Meyer
CC Web Technologien
New-York-Ring 6
22297 Hamburg
Tel: 040/6377 - 3272
Fax: 040/6377 - 41268
mailto:[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security in tomcat 5.x, need j_password in struts web app, ServletFilter or IntermediateServlet? [Auf Viren geprüft]
http://issues.apache.org/bugzilla/show_bug.cgi?id=21795
You can always write your own Realm which creates your own custom Principal
which can store the password in it. This does require some casting but not
uncommon.
-Tim
[EMAIL PROTECTED] wrote:
Thanks Tim Funk for the quick answer,
In FormAuthenticator there is a line:
principal =
context.getRealm().authenticate(username, password);
It returns an
interface java.security.Principal
The Principal stores the username (uid), not the password (Credential).
I only can call getName().
Furthermore any Realm has no access to the users session.
So I can't get the password from the realm.
I could of course write the password as cleartext or obscured code in my
own Realm to an external
data store. But I don't want that. It's dirty and unsafe and against the
security requirements of
this web-app.
I've searched the Java Servlet Specification v.2.4
http://jcp.org/aboutJava/communityprocess/final/jsr154/index.html
but haven't found a place where applying ServletFilters to
/j_security_check is forbidden.
Could you please provide me with an pointer to the spec you have forbidding
this kind
of filtering?
One of many same questions I have found on
http://www.mail-archive.com/[EMAIL PROTECTED]/msg117539.html
(Message 1117539 on this list)
was answered by yourself with the suggestion of using a valve.
Could you please me more detail on that solution?
On the same answer there was mentioned that BEA WebLogic provides a hook
named
auth-filter
which would solve my problem too (in a proprietary way). With Websphere
this is the second App-Server which could solve my problem.
I have a Sun ONE Web App Server 7 at hands, so will try eventually
the ServletFilter-method too.
Another thread on this list with the same requirement is number 111855:
servlet sendRedirect() to j_security_check problem (remember me)
http://www.mail-archive.com/[EMAIL PROTECTED]/msg111855.html
It announces Matt Raibles solution, programmed into his example application
AppFuse.
It works y submitting a subrequest vie HttpClient lib which seems rather
strange to me.
It cites an earlier posting number 111700
http://www.mail-archive.com/tomcat-user%40jakarta.apache.org/msg111700.html
One more question:
In the Tomcat 5.0.27 source in FormAuthentificator.java it says
// Save the authenticated Principal in our session
session.setNote(Constants.FORM_PRINCIPAL_NOTE, principal);
// If we are not caching, save the username and password as well
if (!cache) {
session.setNote(Constants.SESS_USERNAME_NOTE, username);
session.setNote(Constants.SESS_PASSWORD_NOTE, password);
}
Am I able to session.getNote(Constants.SESS_PASSWORD_NOTE, password) in my
web-app?
It seems to be stored in the session, or am I wrong?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security in tomcat 5.x, need j_password in struts web app, ServletFilter or IntermediateServlet? [Auf Viren geprüft]
Thanks again Tim Funk. Your answer is another solution I didn't think of and it sounds standard conform and secure and clean to me. I'll develop my own JNDIRealm / JAASRealm and my own Principal, so I get not only the name and roles of the user out of the directory but every other information that is store (UserBean) and the login password. Very well, Frerk Meyer EDEKA Aktiengesellschaft GB Datenverarbeitung Frerk Meyer CC Web Technologien New-York-Ring 6 22297 Hamburg Tel: 040/6377 - 3272 Fax: 040/6377 - 41268 mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security
On Thu, Jul 08, 2004 at 11:19:39PM -0500, Steve Luzynski wrote: : Using Tomcat 5.0.25 on Mac OS X (10.3.4 specifically). Trying to : implement container managed security. : : [snip: deployment descriptor] : : When I try to hit a url like : http://localhost:9006/IPBoss/add/add_network.html, which as near as I : can tell should trigger authentication, I just get the page I'm asking : for - no login. Humor me -- is there an Apache server in front of Tomcat that's intercepting the .html? (I hate to ask this) but did you restart Tomcat after making the web.xml changes? Otherwise, web.xml looks spec-compliant as far as I can tell. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security
On Jul 9, 2004, at 8:11 AM, QM wrote: On Thu, Jul 08, 2004 at 11:19:39PM -0500, Steve Luzynski wrote: : Using Tomcat 5.0.25 on Mac OS X (10.3.4 specifically). Trying to : implement container managed security. : : [snip: deployment descriptor] : : When I try to hit a url like : http://localhost:9006/IPBoss/add/add_network.html, which as near as I : can tell should trigger authentication, I just get the page I'm asking : for - no login. Humor me -- is there an Apache server in front of Tomcat that's intercepting the .html? Nope, Tomcat is running an http connector directly on port 9006. (I hate to ask this) but did you restart Tomcat after making the web.xml changes? Repeatedly. :) Otherwise, web.xml looks spec-compliant as far as I can tell. I thought so. Any other ideas? I'm stumped. Thanks much, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security
Have you tried adding http-method/ elements to web-resource-collection ? web-resource-collection http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection Steve Luzynski wrote: On Jul 9, 2004, at 8:11 AM, QM wrote: On Thu, Jul 08, 2004 at 11:19:39PM -0500, Steve Luzynski wrote: : Using Tomcat 5.0.25 on Mac OS X (10.3.4 specifically). Trying to : implement container managed security. : : [snip: deployment descriptor] : : When I try to hit a url like : http://localhost:9006/IPBoss/add/add_network.html, which as near as I : can tell should trigger authentication, I just get the page I'm asking : for - no login. Humor me -- is there an Apache server in front of Tomcat that's intercepting the .html? Nope, Tomcat is running an http connector directly on port 9006. (I hate to ask this) but did you restart Tomcat after making the web.xml changes? Repeatedly. :) Otherwise, web.xml looks spec-compliant as far as I can tell. I thought so. Any other ideas? I'm stumped. Thanks much, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security
On Jul 9, 2004, at 12:40 PM, Robert F. Hall wrote: Have you tried adding http-method/ elements to web-resource-collection ? web-resource-collection http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection No go there either, tried it with and without. Is there some logging or debugging I can turn on? The stock logs aren't showing me anything other than just a normal access to the resources that I'm wanting to protect. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security
On Fri, Jul 09, 2004 at 03:20:39PM -0500, Steve Luzynski wrote: : Is there some logging or debugging I can turn on? The stock logs aren't : showing me anything other than just a normal access to the resources : that I'm wanting to protect. Another silly question, then: what's the deployed webapp? Is IPBoss a proper context, or is IPBoss the subdir of something mapped to the root context? Yes, I'm grasping ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security
On Jul 9, 2004, at 5:52 PM, QM wrote: On Fri, Jul 09, 2004 at 03:20:39PM -0500, Steve Luzynski wrote: : Is there some logging or debugging I can turn on? The stock logs aren't : showing me anything other than just a normal access to the resources : that I'm wanting to protect. Another silly question, then: what's the deployed webapp? Is IPBoss a proper context, or is IPBoss the subdir of something mapped to the root context? It's a context. Does it matter that there are no actual servlets in the web.xml file yet? I'm in the process of switching away from Struts to a different framework and decided this was a good time to move to container managed security since I destroyed the entire view anyway. :) So because of that there is no servlet mapping yet, I'm just trying to get Tomcat to properly access control some static HTML right now. (I'm grasping too...) Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Container managed security
Steve Luzynski [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Jul 9, 2004, at 12:40 PM, Robert F. Hall wrote: Have you tried adding http-method/ elements to web-resource-collection ? web-resource-collection http-methodHEAD/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method http-methodDELETE/http-method /web-resource-collection No go there either, tried it with and without. Is there some logging or debugging I can turn on? The stock logs aren't showing me anything other than just a normal access to the resources that I'm wanting to protect. You could try setting debug=10 on your Context and/or Realm element. That should tell you in pretty good detail what Tomcat is trying to do with the request. Thanks, Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Container managed security
I've been scratching my head most of the day on this... Using Tomcat 5.0.25 on Mac OS X (10.3.4 specifically). Trying to implement container managed security. I have a JDBC Realm set up in server.xml for the context in question. The web.xml file for the application is set up just like the examples: ?xml version=1.0 encoding=UTF-8? !DOCTYPE web-app PUBLIC -//Sun Microsystems, Inc.//DTD Web Application 2.3//EN http://java.sun.com/dtd/web-app_2_3.dtd; web-app display-nameIPBoss/display-name security-contraint web-resource-collection web-resource-namerestricted pages/web-resource-name url-pattern/add/*/url-pattern url-pattern/edit/*/url-pattern url-pattern/delete/*/url-pattern /web-resource-collection auth-contraint role-nameuser/role-name /auth-contraint /security-contraint login-config auth-methodFORM/auth-method realm-nameIPBoss application/realm-name form-login-config form-login-page/index.html/form-login-page form-error-page/index.html/form-error-page /form-login-config /login-config security-role description The role of any user of this application. /description role-nameuser/role-name /security-role welcome-file-list welcome-fileindex.html/welcome-file /welcome-file-list /web-app When I try to hit a url like http://localhost:9006/IPBoss/add/add_network.html, which as near as I can tell should trigger authentication, I just get the page I'm asking for - no login. I'm sure I'm missing something easy but I just can't figure it out. Thanks! -Steve
How to logout using container managed security
Hi, I am using Tomcat managed security where I am using JAASRealm. I have implemented a LoginModule ... using which I can login easily. But how to logout ... doing session.invalidate() was what I thought would do the trick. It did ... BUT ... after having logged out it is impossible to login the way I want to login. Actually, I set up some attributes in the session after a successfull login. Everything goes fine upto authentication. But the moment I try to setup the attributes in the session I get a LoginException because I try to add attributes into a session already invalidated What is the way to logout ? How can I tell Tomcat to perform the logout procedure from the LoginModule I implemented rather than doing a session.invalidate() ??? Thanks regards, -- Gagan
JAAS and container managed security
I used container managed security (I mean declaring security issues in web.xml, and using security standard servlet API isUserInRole, getUserPrincipal and so on) for several webapp, but I'm now facing the following need that this approach seem not to satisfy: I have to authenticate users based on both 1) A usual username, password mechanism; 2) A OTP (One Time Password) mechanism, something like a complex string parameter on a URL (sent by e-mail), stored in the DB that uniquely identifies the identity of the user. Now, I'm doing some little tries with JAAS to achieve this, but I have the following doubt: If I understand well I cannot merge the two approaches, that is use servlet declarative and programmatic security with JAAS. If I use JAAS LoginModules, I will not have the isUserInRole and other API's working... Is that right ?? Any help is very appreciated Renato Renato Romano Sistemi e Telematica S.p.A. Calata Grazie - Vial Al Molo Giano 16127 - GENOVA e-mail: [EMAIL PROTECTED] Tel.: 010 2712603 _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JAAS and container managed security
On 03/04/2004 04:12 PM Renato Romano wrote: I used container managed security (I mean declaring security issues in web.xml, and using security standard servlet API isUserInRole, getUserPrincipal and so on) for several webapp, but I'm now facing the following need that this approach seem not to satisfy: I have to authenticate users based on both 1) A usual username, password mechanism; 2) A OTP (One Time Password) mechanism, something like a complex string parameter on a URL (sent by e-mail), stored in the DB that uniquely identifies the identity of the user. Now, I'm doing some little tries with JAAS to achieve this, but I have the following doubt: If I understand well I cannot merge the two approaches, that is use servlet declarative and programmatic security with JAAS. If I use JAAS LoginModules, I will not have the isUserInRole and other API's working... Is that right ?? JAAS will integrate with container-managed security in tomcat. You can use your login modules. The principal that you fill out in the login module must contain the role objects. Those methods will work. Adam -- struts 1.1 + tomcat 5.0.16 + java 1.4.2 Linux 2.4.20 Debian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Container managed security
Howdy, App1 and App2 can have completely separate realms. Read the Realm configuration reference. Yoav Shapira Millennium ChemInformatics -Original Message- From: Stephen Ting [mailto:[EMAIL PROTECTED] Sent: Sunday, June 22, 2003 11:17 PM To: [EMAIL PROTECTED]; 'Jboss Mailing List' Subject: Container managed security Hi All, May i know is it possible to have more than one login config for a single container. Says i have 2 applications running on different context; APP1 and APP2 both of them using container managed security. But required seperate login credential. Can i mantain 2 or more set of users and roles data? I need to do this because both APP1 and APP2 is the same application running in same container and configured with same ROLES rules. But the applications are used by different group of users and have different set of data. Therefore users who can logon to APP1 can't logon to APP2 and reverse. Can anyone shows me how to archive this? I am using JBoss 3.0.7 bunble with Tomcat 4.1.24 Any help are very much appreciated. Regards, Stephen Ting This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Container managed security
Hi All, May i know is it possible to have more than one login config for a single container. Says i have 2 applications running on different context; APP1 and APP2 both of them using container managed security. But required seperate login credential. Can i mantain 2 or more set of users and roles data? I need to do this because both APP1 and APP2 is the same application running in same container and configured with same ROLES rules. But the applications are used by different group of users and have different set of data. Therefore users who can logon to APP1 can't logon to APP2 and reverse. Can anyone shows me how to archive this? I am using JBoss 3.0.7 bunble with Tomcat 4.1.24 Any help are very much appreciated. Regards, Stephen Ting
RE: Question about container-managed security
The other weird thing is that request parameters don't propagate either across the protected/unprotected boundary. If the user is viewing a form on a protected page and submits with an action that subsequently does a forward (via a forward mapping in a Struts action) to an unprotected page, the parameters don't show up in the request object. I'm thinking this could be a bug in the JBoss security implementation, a bug in Struts, or maybe a bug in Tomcat. Either that, or it might be a design decision -- I remember reading a few days ago that session data does not remain valid when switching between HTTP and HTTPS. Is this the case with protected/unprotected pages as well for both user credentials and parameters? -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 6:02 PM To: Tomcat Users List Subject: Re: Question about container-managed security On Tue, 2 Apr 2002, Wellie W. Chao wrote: Date: Tue, 2 Apr 2002 16:59:38 -0500 From: Wellie W. Chao [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Question about container-managed security I'm using Tomcat 4.0.2 and noticed that the security attributes returned by request.getRemoteUser(), request.isUserInRole(x), and request.getUserPrincipal() seem to only be present when the user is in a protected directory, even if he has already logged in. That is to say, the user can log in and go to a protected URL, and request.getRemoteUser() works fine. If he then goes to a common area that is not protected by a security-constraint block in web.xml, request.getRemoteUser() returns null. If he then goes back to a different protected page, request.getRemoteUser() returns the username again, so clearly Tomcat is storing the information. Does anyone know how to get access to the authentication information on a non-protected page after the user has logged in? I could set a session attribute right after login, but I figured that Tomcat already has the information, so it would be nice to not have to resort to a hack. As long as your common area is within the same web application, you should continue to see the security attributes, even when accessing an unprotected resource. However, if your common area is in some other webapp, then the attributes won't be set, because they are specific to a particular webapp only. Craig -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Question about container-managed security
I'm using Tomcat 4.0.2 and noticed that the security attributes returned by request.getRemoteUser(), request.isUserInRole(x), and request.getUserPrincipal() seem to only be present when the user is in a protected directory, even if he has already logged in. That is to say, the user can log in and go to a protected URL, and request.getRemoteUser() works fine. If he then goes to a common area that is not protected by a security-constraint block in web.xml, request.getRemoteUser() returns null. If he then goes back to a different protected page, request.getRemoteUser() returns the username again, so clearly Tomcat is storing the information. Does anyone know how to get access to the authentication information on a non-protected page after the user has logged in? I could set a session attribute right after login, but I figured that Tomcat already has the information, so it would be nice to not have to resort to a hack. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Question about container-managed security
On Tue, 2 Apr 2002, Wellie W. Chao wrote: Date: Tue, 2 Apr 2002 16:59:38 -0500 From: Wellie W. Chao [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Question about container-managed security I'm using Tomcat 4.0.2 and noticed that the security attributes returned by request.getRemoteUser(), request.isUserInRole(x), and request.getUserPrincipal() seem to only be present when the user is in a protected directory, even if he has already logged in. That is to say, the user can log in and go to a protected URL, and request.getRemoteUser() works fine. If he then goes to a common area that is not protected by a security-constraint block in web.xml, request.getRemoteUser() returns null. If he then goes back to a different protected page, request.getRemoteUser() returns the username again, so clearly Tomcat is storing the information. Does anyone know how to get access to the authentication information on a non-protected page after the user has logged in? I could set a session attribute right after login, but I figured that Tomcat already has the information, so it would be nice to not have to resort to a hack. As long as your common area is within the same web application, you should continue to see the security attributes, even when accessing an unprotected resource. However, if your common area is in some other webapp, then the attributes won't be set, because they are specific to a particular webapp only. Craig -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Question about container-managed security
It's within the same webapp (the context path is the same). At first I thought it was a cache issue, but I hit reload on both protected and unprotected pages and it shows what I originally pulled up on each particular page. That is, users remain logged in, but when they visit unprotected sites, request.getRemoteUser() and other authentication methods behave as if the user is unauthenticated until the user revisits a protected page, at which point the authentication methods return valid information. Tomcat does not ask the user to log back in, so it remembers. I can visit other web sites and return to my application, and Tomcat still remembers authentication information, and Tomcat still returns null for request.getRemoteUser() on the unprotected pages (most served by Struts and Tiles). Do you think using Struts or Tiles could influence the scope of the security attributes so that they only showed up in the protected areas? I'm also running an integrated JBoss. It's almost as if the cookie used for security only has scope within a subtree of the application -- I'm just speculating wildly here. The problem is not that severe since I can create a session attribute that stores the authentication information, but it is mildly annoying. -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 02, 2002 6:02 PM To: Tomcat Users List Subject: Re: Question about container-managed security On Tue, 2 Apr 2002, Wellie W. Chao wrote: Date: Tue, 2 Apr 2002 16:59:38 -0500 From: Wellie W. Chao [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Question about container-managed security I'm using Tomcat 4.0.2 and noticed that the security attributes returned by request.getRemoteUser(), request.isUserInRole(x), and request.getUserPrincipal() seem to only be present when the user is in a protected directory, even if he has already logged in. That is to say, the user can log in and go to a protected URL, and request.getRemoteUser() works fine. If he then goes to a common area that is not protected by a security-constraint block in web.xml, request.getRemoteUser() returns null. If he then goes back to a different protected page, request.getRemoteUser() returns the username again, so clearly Tomcat is storing the information. Does anyone know how to get access to the authentication information on a non-protected page after the user has logged in? I could set a session attribute right after login, but I figured that Tomcat already has the information, so it would be nice to not have to resort to a hack. As long as your common area is within the same web application, you should continue to see the security attributes, even when accessing an unprotected resource. However, if your common area is in some other webapp, then the attributes won't be set, because they are specific to a particular webapp only. Craig -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Question about container-managed security
On Tue, Apr 02, 2002 at 06:42:40PM -0500, Wellie W. Chao wrote: It's within the same webapp (the context path is the same). At first I thought it was a cache issue, but I hit reload on both protected and unprotected pages and it shows what I originally pulled up on each particular page. That is, users remain logged in, but when they visit unprotected sites, request.getRemoteUser() and other authentication methods behave as if the user is unauthenticated until the user revisits a protected page, at which point the authentication methods return valid information. Tomcat does not ask the user to log back in, so it remembers. I can visit other web sites and return to my application, and Tomcat still remembers authentication information, and Tomcat still returns null for request.getRemoteUser() on the unprotected pages (most served by Struts and Tiles). are both protected and uprotected pages using the same scheme; ie. https for both or http for both? because the logged-in cookie doesn't work across schemes... Adi -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Tomcat container managed security for swing clients?
Hi Does anyone know how to take advantage of Tomcat 4.0 container managed security features using a swing client? I appreciate that the using j_security_check flag from a jsp client sets the user's credentials which are intercepted by the container. Then container can then perform the realm queries etc. But how I can take advantage of this type of container managed security from a swing client? How can I set the users credentials from a swing client so that the container may intercept the call? Do I have to code a POST request from the swing client which uses the j_security_check OR is this completely the wrong way to go about it? hope someone can help -Daniel
Container Managed Security - Basic authentication will not work.
Hi, TCversion: 3.1 Java version: "1.3.0-C" OS: Win 2000 (SP 1) Has anyone else tested the Example Basic Authentication Area (see TOMCAT_HOME\readme.txt) in the example web app? I placed an index.html in '/examples/jsp/security/protected'directory and triedthe following URLs: 1: http://localhost:8080/examples/jsp/security/protected/ 2: http://localhost:8080/examples/jsp/security/protected/index.html 3: http://localhost:8080/examples/jsp/security/protected/index.jsp In each case a Basic Authentication dialog opens OK I enter a user ID and password combination as defined in TOMCAT_HOME/conf/tomcat-users.xml. This is what happens:- 1: A listing of directories that DO NOT EXIST within 'examples/jsp/security/protected' - they are in the 'examples' directory. Directory Listing for: /examples/jsp/security/protected/ Up to: /examples/jsp/security Subdirectories: images/ Sun, 05 Nov 2000 14:26 GMT+01:00 jsp/ Sun, 05 Nov 2000 14:26 GMT+01:00 servlets/ Sun, 05 Nov 2000 14:26 GMT+01:00 Tomcat Web Server v3.1 2: Error 404 Error: 404 Location: /examples/jsp/security/protected/index.html File Not Found/examples/jsp/security/protected/index.html There is DEFINITELY an index.html in this location 3: Error 404 - same as above but for 'index.jsp' If I pressmake 3 bad attempts to log-inOR press cancel I get a blank page - wonderful! Any ideas? - please. Finally: The project I am involved in intends to run TomCat as a standalone - no Apache. * Can anyone direct me to a decent source of info on how to configure Basic and other forms of access control to protected resources using JUST TomCat? * Is it possible to hook TomCat up to an LDAP server (users, groups roles)? * Can I define users (as in TOMCAT_HOME/conf/tomcat-users.xml) separately for each web app? Thanks in advance . ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø Miles DaffinJava Developer, Netherlands. Land: +31 (0)10 476 2412Mobile: +31 (0)6 2959 1423Permanent email: [EMAIL PROTECTED] ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤øø
Re: Container Managed Security - Basic authentication will not work.
Miles Daffin wrote: Hi,TC version: 3.1Java version: "1.3.0-C"OS: Win 2000 (SP 1)Has anyone else tested the Example Basic Authentication Area (see TOMCAT_HOME\readme.txt) in the example web app?I placed an index.html in '/examples/jsp/security/protected' directory and tried the following URLs:1: http://localhost:8080/examples/jsp/security/protected/2: http://localhost:8080/examples/jsp/security/protected/index.html3: http://localhost:8080/examples/jsp/security/protected/index.jspIn each case a Basic Authentication dialog opens OK I enter a user ID and password combination as defined in TOMCAT_HOME/conf/tomcat-users.xml. Container managed security in Tomcat 3.1 is broken. Use 3.2 or 4.0. Craig McClanahan
