ThreadLocal and NIO
Hi, Currently we use a filter and log4j's NDC to store details of the request such as our identifier for the user and their Ip address. We then have a log pattern which puts these details in the log. This way if we have any errors we can easily associate them back to the origional request. This works very well. Currently we are using 6.0.18. However, If I understand it correctly. If we change to use NIO for the connectors it isn't thread per request any longer so setting something into log4j's NDC which uses ThreadLocal may not associate the variable with the actual request. Is this correct? If it is is there any way I can consistantly append the details of the session with the current activity such as running a SQL query. I'm not keen on passing the session details through every call on our system. Regards, Wesley Acheson
interaction between .forward() and security-constraint
Hi, I want to implement discretionary access control in an app running in Tomcat - i.e. access controls on URLs served by Tomcat can be changed by users. I expect to have a 1M resources each with its own ACL. Some resources have 'public' access. No authentication should be required to access them. Access to some resources is constrained and does require authentication. The same resource may be access controlled one minute and public the next. The URL of a resource may not change when its ACL changes. I have been approaching this by trying to use the built in Tomcat authentication and creating my own authorization filter. The problem I'm hitting is that getRemoteUser is returning null. I believe the reason it is returning null is that I have no auth-constraint element in my security constraint: security-constraint display-nameAuthenticate/display-name web-resource-collection web-resource-nameresources/web-resource-name description/description url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodHEAD/http-method http-methodPUT/http-method http-methodOPTIONS/http-method http-methodTRACE/http-method http-methodDELETE/http-method /web-resource-collection /security-constraint Despite the fact that I have arranged for the incoming request to have an Authorization header (I send my own 401 responses), Tomcat does not process it unless the there is an auth-constraint that applies to the requested resource. This is consistent with what the servlet spec says: [[An authorization constraint establishes a requirement for authentication ...]] I want to have no authorization constraint because some resources have public access and no authentication is required for access to those resources. I have tried using getRequestDispatcher(...).forward(...) to forward requests for resources that require authentication to a different URL and defining a different security constraint for those URLs: security-constraint display-nameAuthenticate/display-name web-resource-collection web-resource-nameauthenticated resources/web-resource-name description/description url-pattern/authenticated/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodHEAD/http-method http-methodPUT/http-method http-methodOPTIONS/http-method http-methodTRACE/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-nameREGISTERED/role-name /auth-constraint /security-constraint getRemoteUser() still returns null. .forward() does not seem to be subject to security checks. I have found nothing in the Servlet spec that tells me what the behaviour should be. I have three questions: 1) Is there a way I can programatically cause the authentication check? [Currently I send my own 401 response if authentication is required. If a call to getRemoteUser() were to cause the processing of a present Authorization header, if that processing had not been done already, that would support my approach. I don't yet know if/how I could compute an appropriate challenge for the 401 responses I generate for digest authentication, which I would want to use preference to Basic authentication.] 2) Is there another way to implement discretionary access control, other than implementing my own authentication mechanism? Has anyone else solved this problem? 3) Is Tomcat's behaviour 'correct'? There may be good reason for the current interpretation of the spec, but from my point of view allowing .forward() to circumvent declared security constraints is questionable. I am using Tomcat 6.0.29. Sorry its such a long winded mail. Brian
Re: [OT] clear text keystore password in server.xml
On 02.09.2010 18:55, Pid wrote: On 02/09/2010 17:31, Christopher Schultz wrote: Pid, On 9/2/2010 11:51 AM, Pid wrote: ..lots of info is available by JMX, once the server is up. In Java 6 you can attach to the process locally, without having to configure the JMX ports because it injects the management agent into the virtual machine. I hadn't considered that, never having used JMX. Are you saying that anyone with local access can snoop a JVM? What are the strategies available to prohibit that? Can you disable local JMX altogether? How about some kind of authentication? Pretty much. I'm not sure how to disable it, I've only just got the hang of enabling it. http://download.oracle.com/javase/6/docs/jdk/api/attach/spec/com/sun/tools/attach/VirtualMachine.html Also: sun.management.ConnectorAddressLink, but I can't find a javadoc for that. I thought it uses a local file created by the JVM which only allows access, if you are the same user (or root). The marketing terminology for this Java 6 feature was attach on demand. See also http://weblogs.java.net/blog/emcmanus/archive/2005/09/mustang_jdk_now.html with some examples here: http://blogs.sun.com/sundararajan/entry/using_mustang_s_attach_api http://blogs.sun.com/sundararajan/entry/my_experiments_with_attach_on and API Javadoc: http://download-llnw.oracle.com/javase/6/docs/jdk/api/attach/spec/index.html Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Phantom Sessions
On 03.09.2010 00:20, Paul Szynol wrote: Hi, Chris, Thanks for your response. I do get those requests, but it seems they always generate standard user agent information, which I then store in the associated session object. These session objects don't have any user agent information--that's why I am wondering if they're generated internally. You could log a stack trace in those cases and look up the call stack, which might add information about why this happens. To keep output low, you would only produce the info, if the UA is empty. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] clear text keystore password in server.xml
On 04/09/2010 11:05, Rainer Jung wrote: On 02.09.2010 18:55, Pid wrote: On 02/09/2010 17:31, Christopher Schultz wrote: Pid, On 9/2/2010 11:51 AM, Pid wrote: ..lots of info is available by JMX, once the server is up. In Java 6 you can attach to the process locally, without having to configure the JMX ports because it injects the management agent into the virtual machine. I hadn't considered that, never having used JMX. Are you saying that anyone with local access can snoop a JVM? What are the strategies available to prohibit that? Can you disable local JMX altogether? How about some kind of authentication? Pretty much. I'm not sure how to disable it, I've only just got the hang of enabling it. http://download.oracle.com/javase/6/docs/jdk/api/attach/spec/com/sun/tools/attach/VirtualMachine.html Also: sun.management.ConnectorAddressLink, but I can't find a javadoc for that. I thought it uses a local file created by the JVM which only allows access, if you are the same user (or root). The marketing terminology for this Java 6 feature was attach on demand. OK, that useful to know. I was assuming there was a JVM option to prevent dynamic attachments, but that I just hadn't found it. File perm based restrictions makes sense. See also http://weblogs.java.net/blog/emcmanus/archive/2005/09/mustang_jdk_now.html with some examples here: http://blogs.sun.com/sundararajan/entry/using_mustang_s_attach_api http://blogs.sun.com/sundararajan/entry/my_experiments_with_attach_on and API Javadoc: http://download-llnw.oracle.com/javase/6/docs/jdk/api/attach/spec/index.html Excellent, thanks, I'll have a read. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: [OT] clear text keystore password in server.xml
On 04/09/2010 12:41, Pid wrote: On 04/09/2010 11:05, Rainer Jung wrote: On 02.09.2010 18:55, Pid wrote: On 02/09/2010 17:31, Christopher Schultz wrote: Pid, On 9/2/2010 11:51 AM, Pid wrote: ..lots of info is available by JMX, once the server is up. In Java 6 you can attach to the process locally, without having to configure the JMX ports because it injects the management agent into the virtual machine. I hadn't considered that, never having used JMX. Are you saying that anyone with local access can snoop a JVM? What are the strategies available to prohibit that? Can you disable local JMX altogether? How about some kind of authentication? Pretty much. I'm not sure how to disable it, I've only just got the hang of enabling it. http://download.oracle.com/javase/6/docs/jdk/api/attach/spec/com/sun/tools/attach/VirtualMachine.html Also: sun.management.ConnectorAddressLink, but I can't find a javadoc for that. I thought it uses a local file created by the JVM which only allows access, if you are the same user (or root). The marketing terminology for this Java 6 feature was attach on demand. OK, that useful to know. I was assuming there was a JVM option to prevent dynamic attachments, but that I just hadn't found it. File perm based restrictions makes sense. It's possible to prevent attachment via the SecurityManager. Obvious really. Doh. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: ThreadLocal and NIO
From: Wesley Acheson [mailto:wesley.ache...@gmail.com] Subject: ThreadLocal and NIO If I understand it correctly. If we change to use NIO for the connectors it isn't thread per request any longer No, the same thread still processes one request all the way through. However, there is no longer one thread per TCP connection, as there is with the blocking connector. So if a client is sending multiple requests on one TCP connect (HTTP pipelining), each request of the series may well be handled by a different thread. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: interaction between .forward() and security-constraint
From: Brian McBride [mailto:bwm.topmea...@googlemail.com] Subject: interaction between .forward() and security-constraint I want to have no authorization constraint because some resources have public access and no authentication is required for access to those resources. Declarative security is intentionally static; there's nothing in the spec that allows for the accessibility of a resource to change after deployment. If the public resources are always public, you can declare their url-pattern values in web.xml and omit the auth-constraint for those patterns - but that's only useful if everything else is protected with an auth-constraint. Is there a way I can programatically cause the authentication check? If you're using programmatic security, you are responsible for the authentication and authorization. Is there another way to implement discretionary access control, other than implementing my own authentication mechanism? Has anyone else solved this problem? What you're trying to do is completely outside the spec, so you're pretty much on your own. Is Tomcat's behaviour 'correct'? There may be good reason for the current interpretation of the spec, but from my point of view allowing .forward() to circumvent declared security constraints is questionable. This is very plainly stated in SRV.12.2: The security model applies to the static content part of the web application and to servlets and filters within the application that are requested by the client. The security model does not apply when a servlet uses the RequestDispatcher to invoke a static resource or servlet using a forward or an include. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: interaction between .forward() and security-constraint
I would look at a servlet filter to provide this sort of dynamic access control. Map urls of your choosing to pass through this servlet filter, the servlet filter could look up potentially changing list of access control rules and route request to login page or whatever page you'd like if user is not allowed to access resource. Jason On Sat, Sep 4, 2010 at 1:28 AM, Brian McBride bwm.topmea...@googlemail.comwrote: Hi, I want to implement discretionary access control in an app running in Tomcat - i.e. access controls on URLs served by Tomcat can be changed by users. I expect to have a 1M resources each with its own ACL. Some resources have 'public' access. No authentication should be required to access them. Access to some resources is constrained and does require authentication. The same resource may be access controlled one minute and public the next. The URL of a resource may not change when its ACL changes. I have been approaching this by trying to use the built in Tomcat authentication and creating my own authorization filter. The problem I'm hitting is that getRemoteUser is returning null. I believe the reason it is returning null is that I have no auth-constraint element in my security constraint: security-constraint display-nameAuthenticate/display-name web-resource-collection web-resource-nameresources/web-resource-name description/description url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodHEAD/http-method http-methodPUT/http-method http-methodOPTIONS/http-method http-methodTRACE/http-method http-methodDELETE/http-method /web-resource-collection /security-constraint Despite the fact that I have arranged for the incoming request to have an Authorization header (I send my own 401 responses), Tomcat does not process it unless the there is an auth-constraint that applies to the requested resource. This is consistent with what the servlet spec says: [[An authorization constraint establishes a requirement for authentication ...]] I want to have no authorization constraint because some resources have public access and no authentication is required for access to those resources. I have tried using getRequestDispatcher(...).forward(...) to forward requests for resources that require authentication to a different URL and defining a different security constraint for those URLs: security-constraint display-nameAuthenticate/display-name web-resource-collection web-resource-nameauthenticated resources/web-resource-name description/description url-pattern/authenticated/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodHEAD/http-method http-methodPUT/http-method http-methodOPTIONS/http-method http-methodTRACE/http-method http-methodDELETE/http-method /web-resource-collection auth-constraint role-nameREGISTERED/role-name /auth-constraint /security-constraint getRemoteUser() still returns null. .forward() does not seem to be subject to security checks. I have found nothing in the Servlet spec that tells me what the behaviour should be. I have three questions: 1) Is there a way I can programatically cause the authentication check? [Currently I send my own 401 response if authentication is required. If a call to getRemoteUser() were to cause the processing of a present Authorization header, if that processing had not been done already, that would support my approach. I don't yet know if/how I could compute an appropriate challenge for the 401 responses I generate for digest authentication, which I would want to use preference to Basic authentication.] 2) Is there another way to implement discretionary access control, other than implementing my own authentication mechanism? Has anyone else solved this problem? 3) Is Tomcat's behaviour 'correct'? There may be good reason for the current interpretation of the spec, but from my point of view allowing .forward() to circumvent declared security constraints is questionable. I am using Tomcat 6.0.29. Sorry its such a long winded mail. Brian
Re: URL Rewrite
2010/9/4 michel compu...@videotron.ca: - Original Message - From: Ognjen Blagojevic ognjen.d.blagoje...@gmail.com To: Tomcat Users List users@tomcat.apache.org Sent: Friday, September 03, 2010 6:42 AM Subject: Re: URL Rewrite On 3.9.2010 12:02, michel wrote: I have been using the tuckey urlrewrite with some results, in that if I want to have an incoming URL coming in as gallery/pic20 gets changed to gallery.jsp?pic=20 But the tool bar URL gets displayed as gallery.jsp?pic=20 and I want to display gallery/pic20 Just use rule, not outbond-rule: rule from/gallery/pic([0-9]+)/from to/gallery.jsp?pic=$1/to /rule Thanks, and I have it working at times (worked all day on this) but it seems unreliable. I am expecting that the very same code would work if I had 'forward' or 'redirect', but it doesn't. If you need a filter to be invoked not only on user's requests, but also when processing forwards and includes inside of your own webapp, you have to configure its mapping in web.xml so that those are passed to it. See the Servlet spec for details. If that is what you mean by forwards and redirects. If you do a client-side redirect (sending a response with HTTP status 302 or 301, 303, 307), the URL where you sent your client will be displayed in her browser's location bar. Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: interaction between .forward() and security-constraint
Hi Charles, Thanks for the quick answer. On 04/09/2010 15:20, Caldarale, Charles R wrote: [...] Declarative security is intentionally static; Its not the declarative access control I want to use - I'd have liked to be able to resuse the authentication code ... t [...] This is very plainly stated in SRV.12.2: The security model applies to the static content part of the web application and to servlets and filters within the application that are requested by the client. The security model does not apply when a servlet uses the RequestDispatcher to invoke a static resource or servlet using a forward or an include. I missed that, obviously:( Ok - now to figure out how to implement digest authentication ... Thanks for your help. Brian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: interaction between .forward() and security-constraint
Hi Jason, Thanks for the response. On 04/09/2010 15:27, Jason Britton wrote: I would look at a servlet filter to provide this sort of dynamic access control. That's what I'm doing. The filter needs to know the user id - and I was hoping to resuse Tomcat's authentication mechanism for that. But I don't think I can :( Thanks again Brian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JNDIRealm Question
My application uses a JNDIRealm to provide authentication, which is working fine. However within my application I now have need to query the same LDAP server which the JNDIRealm is configured to connect. Is there a way that I can either create a managed resource for LDAP connectivity that I can configure a JNDIRealm to utilize, or to obtain an LDAP context used by the JNDIRealm? What I'm trying to avoid is configuring LDAP connectivity parameters in multiple places, and it would be most convenient if I could configure a resource in the same manner I've configured my Datasource. Thanks in advance, -Ron - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: interaction between .forward() and security-constraint
Brian McBride wrote: ... Ok - now to figure out how to implement digest authentication ... Digest authentication is not very popular, and rather a pain to implement yourself. The reason why it is not very popular is that it is a bit of a halfway solution : it does avoid user passwords to be transmitted in clear over the net, but it is not safe for man-in-the-middle attacks (someone can record the digest, and use it to authenticate later as that user). And it still leaves the subsequent conversation unencrypted. If you really need security, then you should run your entire site under HTTPS. This will also allow you to do Basic authentication, or form-based authentication, since the authentication dialog is encrypted anyway by the HTTPS connection. Maybe also your needs would be a valid reason to use an Apache httpd front-end for your site, taking care of the HTTPS side and/or the authentication. httpd can then authenticate the user (using pretty much any method of your choice, there are standard modules available for all), and just pass the already-authenticated user-id to Tomcat. Tomcat can then just do the access-control part. (or if you prefer, you could even do that at the Apache httpd level also). In this case the added overhead would be minimal, because what you do at the httpd level, you do not need to do at the Tomcat level and vice-versa. It is all basically a matter of preference. Not being myself a Tomcat or Java guru, I prefer to do these things at the Apache httpd level, and keep the Tomcat side simple. Your mileage may vary. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: interaction between .forward() and security-constraint
On 04/09/2010 17:27, André Warnier wrote: Digest authentication is not very popular, and rather a pain to implement yourself. The reason why it is not very popular is that it is a bit of a halfway solution : it does avoid user passwords to be transmitted in clear over the net, but it is not safe for man-in-the-middle attacks (someone can record the digest, and use it to authenticate later as that user). No they can't. DIGEST is secure against such an attack. Any session ID, however, will be vulnerable. And it still leaves the subsequent conversation unencrypted. True. If you really need security, then you should run your entire site under HTTPS. It depends on what you are trying to protect. Generally, this is true but there will be edge cases where DIGEST is sufficient. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: interaction between .forward() and security-constraint
far easier to implement than HTTPS what can MIM access with just the session-id? is this comparison DIGEST vs HTTPS documented Martin __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. Date: Sun, 5 Sep 2010 00:23:51 +0100 From: ma...@apache.org To: users@tomcat.apache.org Subject: Re: interaction between .forward() and security-constraint On 04/09/2010 17:27, André Warnier wrote: Digest authentication is not very popular, and rather a pain to implement yourself. The reason why it is not very popular is that it is a bit of a halfway solution : it does avoid user passwords to be transmitted in clear over the net, but it is not safe for man-in-the-middle attacks (someone can record the digest, and use it to authenticate later as that user). No they can't. DIGEST is secure against such an attack. Any session ID, however, will be vulnerable. And it still leaves the subsequent conversation unencrypted. True. If you really need security, then you should run your entire site under HTTPS. It depends on what you are trying to protect. Generally, this is true but there will be edge cases where DIGEST is sufficient. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Errant slow request
Hi, I'm using Apache Bench (ab) to send 1,000 requests with a concurrency of 500 to a simple servlet on Tomcat trunk (revision 992708, 2010-09-03) which uses request.startAsync() and Executors.newFixedThreadPool(10) to do the work and return a few bytes of response and asyncContext.complete(). What I'm noticing is that every once in a while there is an errant request that takes up to 10 seconds, while the average is around half a second. I've reproduced this on both Oracle and IBM JVMs. I've looked at verbosegc and see no anomalies in pause times or heap usage. I've taken javadumps and I don't see any thread that is obviously stuck anywhere. Most importantly, if I compare this to a servlet that writes the same bytes but synchronously (i.e. a classic servlet service() method), then I don't see this aberration. I can see these long requests in my access log by changing org.apache.catalina.valves.AccessLogValve to %h %l %u %t quot;%rquot; %s %b %D, e.g.: 127.0.0.1 - - [04/Sep/2010:18:46:20 -0700] GET /myapp/ HTTP/1.0 500 207 10986 127.0.0.1 - - [04/Sep/2010:18:46:22 -0700] GET /myapp/ HTTP/1.0 500 207 10428 127.0.0.1 - - [04/Sep/2010:18:46:22 -0700] GET /myapp/ HTTP/1.0 500 207 10347 My question is: how do I debug these 500 errors? Thanks. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
