Re: interaction between .forward() and security-constraint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, I'm fumbling about seeking the hardness knob that controls my thinking ... I know its there somewhere ... :) Me, too. You can never be too paranoid about authentication code. I'm learning from the discussion on this list that DIGEST is not very popular. However, it is a published algorithm and therefore has a bit more credibility than one I cooked up. It's not very popular for two reasons: 1. Use of MD5 2. Spotty browser support (due to spotty server support) Basically, it was a good idea that wasn't well-implemented, so nobody ever really bothered to fully support it. Most OSS code works just fine - -- because someone like you was sufficiently motivated to make it work and, well, support the standard. The standard sucks, though :( Note that DIGEST AUTH does use nonce values during communication, even if you can't really use them as permanent salt values. One thing I'm slightly nervous of is reuse of the SSL session id. The SSL spec says the server gets to choose the ID for an SSL session so I need to know that the server doesn't reuse them in a way that might compromise this approach. OpenSSH states that it uses a random number as wide as the protocol allows. Haven't found a statement about what JSSE does and haven't had an answer yet to my question to the forum. I expect its fine - it would just be nice to have it in writing. You could use the APR connector (and you probably should, if Tomcat will be terminating the SSL connection, because it generally performs better than the pure Java I/O connectors) and then you'll be using OpenSSL under the hood: problem solved. :) Hope that helps, - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyPgi4ACgkQ9CaO5/Lv0PAyEACgu+Yvmcdros13eKsr/9Ugu22B tQ4AoL1ZXr34rTCbaW8ah8Wbs5uilcrh =NBR/ -END PGP SIGNATURE- - 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 9/12/2010 4:18 PM, Brian McBride wrote: On 09/09/2010 19:47, Christopher Schultz wrote: I'm sure there are some edge cases where an authenticated user might end up looking like a guest, but you cna probably solve those. That's a bit of a worry. Can you say any more about the edge cases I should be concerned about. Well, if Tomcat intercepts a request in order to perform authentication, then the filter will not be called during that request/response transaction. That's probably - specifically - not a problem because the whole point of the transaction is authentication... presumably you're not delivering protected resources /during/ authentication. I hadn't really thought about what those edge cases were... I just wanted to point out that, when considering authentication and authorization code, you really need to think /hard/ about every possibility, because failure to do so may leave you open to exploitation. If you always use HTTP Authentication (it wasn't clear what was really going on, with all that talk about DIGEST authentication), then you can always get the username from the request headers. In that case, your filter can use that as a source of authentication data, too. I was hoping to use http authentication so I could use well debugged code rather than write my own. But I've currently given up on that. I meant using HTTP BASIC vs FORM authentication -- both are well-tested. I wasn't happy with BASIC authentication on the grounds the password leaves the user's machine. Even if its safe on the wire because of SSL, there is always the chance it will leak from the server end somehow. I want to be sure I never know the user's actual password. Sounds like a good idea. I don't want to store users passwords, I want to store some digest of them. To protect against dictionary attacks on the password database I want to store salted passwords - i.e. add a larg'ish random number to each users password before taking the digest. I couldn't see how to use salted password storage along with HTTP DIGEST authentication. Neither FORM nor BASIC/DIGEST authentication in Tomcat support salted passwords without you writing some of your own code. So I've written my own based on HTTP DIGEST but where the challenge includes the salt so the client can compute the users effective password. Do you intend for regular web browsers to be able to support this? I don't think this is possible in the real world unless you control 100% of the clients. HTTP DIGEST authentication is, unfortunately, likely to just die and go away. It's been designed around the MD5 digest algorithm which is, these days, considered relatively unsafe. There is no protocol through which the client and server can negotiate a digest algorithm, so MD5 is always assumed. Hopefully, DIGEST will be replaced by something like DIGEST2 with a better negotiation protocol so that it can be extended into the future as new crypto primitives become available and old ones are retired. Another variation I am trying is to associate a user not with a session but with an SSL session. Each SSL session must be authenticated. This prevents someone snooping/guessing the JSESSIONID ( some of my traffic is in clear and the JSESSIONID is therefor not secure) and using a different SSL connection and faking the JSESSIONID to get access. That might work, but SSL sessions and user sessions aren't always 1:1. For instance, the SSL session might expire and be renegotiated while the user session should remain the same. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyOdFYACgkQ9CaO5/Lv0PCU/gCgq98nOlMMX/NnRYdQU0ikoEre BHcAn2e1u/ggle9cjWmNebKLXAXHuSah =co+W -END PGP SIGNATURE- - 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 Christopher, On 13/09/2010 19:58, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- [...] That's a bit of a worry. Can you say any more about the edge cases I should be concerned about. Well, if Tomcat intercepts a request in order to perform authentication, then the filter will not be called during that request/response transaction. That's probably - specifically - not a problem because the whole point of the transaction is authentication... presumably you're not delivering protected resources /during/ authentication. Your are right. The filter may kick in during a 'normal' transaction to require authentication before it can proceed, but no restricted resources are delivered during authentication. I hadn't really thought about what those edge cases were... I just wanted to point out that, when considering authentication and authorization code, you really need to think /hard/ about every possibility, because failure to do so may leave you open to exploitation. I'm fumbling about seeking the hardness knob that controls my thinking ... I know its there somewhere ... :) [...] I don't want to store users passwords, I want to store some digest of them. To protect against dictionary attacks on the password database I want to store salted passwords - i.e. add a larg'ish random number to each users password before taking the digest. I couldn't see how to use salted password storage along with HTTP DIGEST authentication. Neither FORM nor BASIC/DIGEST authentication in Tomcat support salted passwords without you writing some of your own code. It's good to have that confirmed. So I've written my own based on HTTP DIGEST but where the challenge includes the salt so the client can compute the users effective password. Do you intend for regular web browsers to be able to support this? I don't think this is possible in the real world unless you control 100% of the clients. I have two sorts of clients - applications where I can specify what's required, and browsers where I can assume the use javascript. I have some javascript that will compute the response to a challenge and send it off to the server. HTTP DIGEST authentication is, unfortunately, likely to just die and go away. I'm learning from the discussion on this list that DIGEST is not very popular. However, it is a published algorithm and therefore has a bit more credibility than one I cooked up. It's been designed around the MD5 digest algorithm which is, these days, considered relatively unsafe. The basic changes I have made are to switch from MD5 to SHA-256 and add a 64 bit salt to the users password. There is no protocol through which the client and server can negotiate a digest algorithm, so MD5 is always assumed. Hopefully, DIGEST will be replaced by something like DIGEST2 with a better negotiation protocol so that it can be extended into the future as new crypto primitives become available and old ones are retired. That would be great. Another variation I am trying is to associate a user not with a session but with an SSL session. Each SSL session must be authenticated. This prevents someone snooping/guessing the JSESSIONID ( some of my traffic is in clear and the JSESSIONID is therefor not secure) and using a different SSL connection and faking the JSESSIONID to get access. That might work, but SSL sessions and user sessions aren't always 1:1. For instance, the SSL session might expire and be renegotiated while the user session should remain the same. Hmmm, yes, that could be bad. Well at least that way round its secure - it just means the client may have to authenticate again. I don't know what control I can have over SSL sessions expiring. The other issue is multiple SSL sessions in the same user session. A programmatic client can take care of that - the browser access should not need multiple sessions - but I'll only know if this is a problem when I've built enough of it to tell. One thing I'm slightly nervous of is reuse of the SSL session id. The SSL spec says the server gets to choose the ID for an SSL session so I need to know that the server doesn't reuse them in a way that might compromise this approach. OpenSSH states that it uses a random number as wide as the protocol allows. Haven't found a statement about what JSSE does and haven't had an answer yet to my question to the forum. I expect its fine - it would just be nice to have it in writing. I appreciate the input and comments. Brian - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyOdFYACgkQ9CaO5/Lv0PCU/gCgq98nOlMMX/NnRYdQU0ikoEre BHcAn2e1u/ggle9cjWmNebKLXAXHuSah =co+W -END PGP SIGNATURE- - 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 Christopher On 09/09/2010 19:47, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- [...] Here's something you can do. Write a filter that you attach to URLs that /are/ used for authentication, and then copy the user's username into the session. Yes, that's the approach I'm trying now. In your authentication filter, use the username stored in the session instead of calling request.getRemoteUser. Alternatively, you can wrap the request in your own wrapper and override getRemoteUser to get the username from the session if it's not available from the request. I'm sure there are some edge cases where an authenticated user might end up looking like a guest, but you cna probably solve those. That's a bit of a worry. Can you say any more about the edge cases I should be concerned about. If you always use HTTP Authentication (it wasn't clear what was really going on, with all that talk about DIGEST authentication), then you can always get the username from the request headers. In that case, your filter can use that as a source of authentication data, too. I was hoping to use http authentication so I could use well debugged code rather than write my own. But I've currently given up on that. I wasn't happy with BASIC authentication on the grounds the password leaves the user's machine. Even if its safe on the wire because of SSL, there is always the chance it will leak from the server end somehow. I want to be sure I never know the user's actual password. I don't want to store users passwords, I want to store some digest of them. To protect against dictionary attacks on the password database I want to store salted passwords - i.e. add a larg'ish random number to each users password before taking the digest. I couldn't see how to use salted password storage along with HTTP DIGEST authentication. So I've written my own based on HTTP DIGEST but where the challenge includes the salt so the client can compute the users effective password. Another variation I am trying is to associate a user not with a session but with an SSL session. Each SSL session must be authenticated. This prevents someone snooping/guessing the JSESSIONID ( some of my traffic is in clear and the JSESSIONID is therefor not secure) and using a different SSL connection and faking the JSESSIONID to get access. Thanks again for all the input. Brian - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJK9sACgkQ9CaO5/Lv0PCyBwCfexhjBY+HPaAkrKgxonWjY/Xs kyEAn3OvtkaAdgoruHvSkn2oEt5HFl6z =dnvR -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: interaction between .forward() and security-constraint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Brian, On 9/4/2010 11:42 AM, Brian McBride wrote: 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 :( Here's something you can do. Write a filter that you attach to URLs that /are/ used for authentication, and then copy the user's username into the session. In your authentication filter, use the username stored in the session instead of calling request.getRemoteUser. Alternatively, you can wrap the request in your own wrapper and override getRemoteUser to get the username from the session if it's not available from the request. I'm sure there are some edge cases where an authenticated user might end up looking like a guest, but you cna probably solve those. If you always use HTTP Authentication (it wasn't clear what was really going on, with all that talk about DIGEST authentication), then you can always get the username from the request headers. In that case, your filter can use that as a source of authentication data, too. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyJK9sACgkQ9CaO5/Lv0PCyBwCfexhjBY+HPaAkrKgxonWjY/Xs kyEAn3OvtkaAdgoruHvSkn2oEt5HFl6z =dnvR -END PGP SIGNATURE- - 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
Thanks to all who have responded. The advice and comments have been very helpful. For my application, the MIM vulnerability is a concern, so I expect to be using HTTPS for at least some of the traffic. Next steps are to clarify my confidentiality requirements and see what I can find on the performance implications of using HTTPS, i.e. is it cheap enough that I don't have to worry about using it for all traffic. Brian On 04/09/2010 17:27, André Warnier wrote: 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 - 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 06/09/2010 16:04, Brian McBride wrote: Thanks to all who have responded. The advice and comments have been very helpful. For my application, the MIM vulnerability is a concern, so I expect to be using HTTPS for at least some of the traffic. Next steps are to clarify my confidentiality requirements and see what I can find on the performance implications of using HTTPS, i.e. is it cheap enough that I don't have to worry about using it for all traffic. Assuming you're not running on hamster powered servers, yes, with modern software hardware it's quite cheap. p Brian On 04/09/2010 17:27, André Warnier wrote: 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: interaction between .forward() and security-constraint
Pid wrote: ... Assuming you're not running on hamster powered servers, yes, with modern software hardware it's quite cheap. I find this remark very discriminatory toward hamsters. What makes you think that hamsters are worse than tomcats or penguins or even apples, he ? We've got several parallel-multi-hamster servers here, and they are doing just fine, even with java. They are also much quieter, more energy-efficient and easier to care for than tomcats or camels. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Re: interaction between .forward() and security-constraint
On 06/09/2010 17:51, André Warnier wrote: Pid wrote: ... Assuming you're not running on hamster powered servers, yes, with modern software hardware it's quite cheap. I find this remark very discriminatory toward hamsters. What makes you think that hamsters are worse than tomcats or penguins or even apples, he ? We've got several parallel-multi-hamster servers here, and they are doing just fine, even with java. They are also much quieter, more energy-efficient and easier to care for than tomcats or camels. Hamsters are fickle, unpredictable workers and are notorious for having a short life. A hamster wheel, contrary to your assertion, is not quiet. N.B. An average sized camel won't fit inside the average sized server chassis. p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
RE: [OT] Re: interaction between .forward() and security-constraint
From: Pid [mailto:p...@pidster.com] Subject: [OT] Re: interaction between .forward() and security-constraint An average sized camel won't fit inside the average sized server chassis. But it will fit on a stick. Since we're completely off in the weeds, I'd like to point out that one of the new food items introduced at the Minnesota State Fair this year was camel-on-a-stick: http://minnesota.publicradio.org/display/web/2010/08/30/fair-food/ (For those not familiar with US culture, deep-fried food on a stick is a mainstay of state fairs, especially midwestern ones. Notable recent inventions include deep-fried butter on a stick, and deep-fried beer on a stick. Cholesterol is your friend...) - 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: [OT] Re: interaction between .forward() and security-constraint
Pid wrote: On 06/09/2010 17:51, André Warnier wrote: Pid wrote: ... Assuming you're not running on hamster powered servers, yes, with modern software hardware it's quite cheap. I find this remark very discriminatory toward hamsters. What makes you think that hamsters are worse than tomcats or penguins or even apples, he ? We've got several parallel-multi-hamster servers here, and they are doing just fine, even with java. They are also much quieter, more energy-efficient and easier to care for than tomcats or camels. Hamsters are fickle, unpredictable workers and are notorious for having a short life. A hamster wheel, contrary to your assertion, is not quiet. N.B. An average sized camel won't fit inside the average sized server chassis. Neither will a tomcat or a penguin. I mean, they can be made to fit, but they clog the ventilation channels and that leads to severe overheating. Chuck's stick option is interesting however, and I'll bring it up at the next hardware planning meeting. To get back to hamsters, contrarily to what you assert they are very diligent and fast, and they compensate their limited memory with their built-in storage and pipelining capabilities; they easily fit into server racks (specially our Roborowskis), and they have a few other logistical advantages : they do not generate a lot of heat, so we don't need expensive cooling systems; their lifetime approximately matches those of Intel chips, so we haven't had to buy new processors in the last couple of years : we just breed them. This way we have a natural permanent upgrade process, with always at least 33% last-generation processors. Their one real inconvenient is that they look like mice, so we have to keep them separate from our tomcats. But for that we use separate racks, with mod_jk connections. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: interaction between .forward() and security-constraint
On 06/09/2010 20:26, André Warnier wrote: Pid wrote: On 06/09/2010 17:51, André Warnier wrote: Pid wrote: ... Assuming you're not running on hamster powered servers, yes, with modern software hardware it's quite cheap. I find this remark very discriminatory toward hamsters. What makes you think that hamsters are worse than tomcats or penguins or even apples, he ? We've got several parallel-multi-hamster servers here, and they are doing just fine, even with java. They are also much quieter, more energy-efficient and easier to care for than tomcats or camels. Hamsters are fickle, unpredictable workers and are notorious for having a short life. A hamster wheel, contrary to your assertion, is not quiet. N.B. An average sized camel won't fit inside the average sized server chassis. Neither will a tomcat or a penguin. I mean, they can be made to fit, but they clog the ventilation channels and that leads to severe overheating. Chuck's stick option is interesting however, and I'll bring it up at the next hardware planning meeting. To get back to hamsters, contrarily to what you assert they are very diligent and fast, and they compensate their limited memory with their built-in storage and pipelining capabilities; they easily fit into server racks (specially our Roborowskis), and they have a few other logistical advantages : they do not generate a lot of heat, so we don't need expensive cooling systems; their lifetime approximately matches those of Intel chips, so we haven't had to buy new processors in the last couple of years : we just breed them. This way we have a natural permanent upgrade process, with always at least 33% last-generation processors. Their one real inconvenient is that they look like mice, so we have to keep them separate from our tomcats. But for that we use separate racks, with mod_jk connections. LOL p 0x62590808.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: interaction between .forward() and security-constraint
Mark Thomas wrote: 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. You are right, the part between () was not correct. But the MIM vulnerability still exists. A MIM can tell the client to use Basic auth, catch the client responses, do Digest auth with the server, and this way get the user id/pw. And neither client or server would be the wiser. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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: 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: 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
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
