Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Not yet, but it is one of the thing I want to do when I've found spare time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager + jsr115) since with 115, the policy provider is called everytime hasUser/ResourcePermission are called, and this approach cannot beat the current way of doing. On the original topic, I think I've missed the spec change from pfd3 and fcs. I was under the wrong impression that Bill's last changes on the RealmAdapter was related to that changes (I was completely wrong). I will try to find the reason whythe change was make... Now the only problem I'm seeing with Phillipe's work is Strings are used everywhere and that may have a performance impact. It may be time to start using MessageByte. So, now that the problems have been resolved (even the performance ones :) ), can you plan to add your JSR 115 (with a flag somewhere to enable it, likely on the realm :) ) stuff on top of Bill's stuff ? Zzzzoui :-) I will do that (on my own time unfortunalty, so may take a couple of weeks) First, it would be easier just to convert the web.xml into security permissions, and to keep internal collections, for unchecked, excluded, and role permissions than to do all this constraint processing work. A simple call to collection.implies, could then be used for the decision logic (which would be just one step short of integrating with an external jsr 115 policy provider). Then a full jsr115 implementation can happen once I'm sure step one works :-) -- Jeanfrancois Rémy - 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: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Jeanfrancois Arcand wrote: Zzzzoui :-) I will do that (on my own time unfortunalty, so may take a couple of weeks) First, it would be easier just to convert the web.xml into security permissions, and to keep internal collections, for unchecked, excluded, and role permissions than to do all this constraint processing work. A simple call to collection.implies, could then be used for the decision logic (which would be just one step short of integrating with an external jsr 115 policy provider). Then a full jsr115 implementation can happen once I'm sure step one works :-) Mmm, ok. I'm not quite following very well, since I didn't read the spec yet ;-) If I understand, you would implement something which would work as the JSR 115 security policy provider, but (likely :) ) simpler ? Would it be equivalent performance wise to the current solution if JSR 115 support is disabled ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Zzzzoui :-) I will do that (on my own time unfortunalty, so may take a couple of weeks) First, it would be easier just to convert the web.xml into security permissions, and to keep internal collections, for unchecked, excluded, and role permissions than to do all this constraint processing work. A simple call to collection.implies, could then be used for the decision logic (which would be just one step short of integrating with an external jsr 115 policy provider). Then a full jsr115 implementation can happen once I'm sure step one works :-) Mmm, ok. I'm not quite following very well, since I didn't read the spec yet ;-) If I understand, you would implement something which would work as the JSR 115 security policy provider, but (likely :) ) simpler ? Yes, as a first steps. It will also works without a security manager (Costin was asking for that if I remember correctly). It is a required steps to supports jsr115 anyway. Would it be equivalent performance wise to the current solution if JSR 115 support is disabled ? Yes, it could be if ByteChunk/MessageByte etc. are used ( can be slower also, probably the first implementation will be slower ). One way to do that will be to create our own Permission collections that re-use what we already have. I still have to think of it...I would like to do something similar to what you have done with the Mapper ( avoiding String etc.) -- Jeanfrancois Rémy - 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: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Jeanfrancois Arcand wrote: Mmm, ok. I'm not quite following very well, since I didn't read the spec yet ;-) If I understand, you would implement something which would work as the JSR 115 security policy provider, but (likely :) ) simpler ? Yes, as a first steps. It will also works without a security manager (Costin was asking for that if I remember correctly). It is a required steps to supports jsr115 anyway. Good :) Would it be equivalent performance wise to the current solution if JSR 115 support is disabled ? Yes, it could be if ByteChunk/MessageByte etc. are used ( can be slower also, probably the first implementation will be slower ). One way to do that will be to create our own Permission collections that re-use what we already have. I still have to think of it...I would like to do something similar to what you have done with the Mapper ( avoiding String etc.) Depending on what you're trying to match and if you can have multiple matches, String.regionMatcher (currently used) works good, since it uses the internal char array of the two String objects. It's the same as using a CharChunk, obviously. Very good plan overall. Now the big question: do we plan to have that JSR 115 support for the next stable release, or is it too early to have it done ? Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Mmm, ok. I'm not quite following very well, since I didn't read the spec yet ;-) If I understand, you would implement something which would work as the JSR 115 security policy provider, but (likely :) ) simpler ? Yes, as a first steps. It will also works without a security manager (Costin was asking for that if I remember correctly). It is a required steps to supports jsr115 anyway. Good :) Would it be equivalent performance wise to the current solution if JSR 115 support is disabled ? Yes, it could be if ByteChunk/MessageByte etc. are used ( can be slower also, probably the first implementation will be slower ). One way to do that will be to create our own Permission collections that re-use what we already have. I still have to think of it...I would like to do something similar to what you have done with the Mapper ( avoiding String etc.) Depending on what you're trying to match and if you can have multiple matches, String.regionMatcher (currently used) works good, since it uses the internal char array of the two String objects. It's the same as using a CharChunk, obviously. Very good plan overall. Now the big question: do we plan to have that JSR 115 support for the next stable release, or is it too early to have it done ? Since there is still some gray area I need to think of, I would say no. But let me think of it :-) -- Jeanfrancois Rémy - 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: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Jeanfrancois Arcand wrote: Now the big question: do we plan to have that JSR 115 support for the next stable release, or is it too early to have it done ? Since there is still some gray area I need to think of, I would say no. But let me think of it :-) Well, since we don't have any really urgent issues to fix in 5.0.16 (a, a quality initial release at last), we don't have to release 5.0.17 within two weeks ;-) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Bill Barker wrote: Ok, I take back my whine/. It seems that they have really made a hash out of the security-constraints. Something like Philippe's implementation is required. Section 12.8.3 requires that only the 'best match' constraints are processed, and those in a 'grant' fashion (i.e. you get the least restrictive privilege of the most restrictive constraints). Now you just need to be a rocket-scientist to figure out how your security-constraints work ;-). So in my example below, a request for /myapp/clients/product1/ will only consider the 'product1' constraint, and ignore the constraint for '/clients/*'. If I had added a security-constraint for '*.jsp', then a request for /myapp/clients/product1/index.jsp would use the 'product1' constraint, and ignore the '*.jsp' constraint. Isn't life going to be fun on the user-list ;-). This means that RealmBase.findSecurityConstraints is going to have to change to only pass back the 'best-match' constraints. At least this isn't an interface change. The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. I don't care much about this problem. Constraint composition is too complex for the real world, and generally container provided auth is just bad to use in real websites. This plus the fact that those changes are brand new (and apparently not tested by Sun's compatibility kit, or Jean François would have done something about it). So this should not impact many people. I'm ok to change the Realm interface, as there's a RealmBase abstract class. I would believe most realms extend it, so there shouldn't be too much trouble. We should take ample time to fix this, to make sure this is correct when done :) Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. I'll be looking into this. I don't know yet if the web related parts belong more to the appserver (JBoss), or more to the servlet container. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. All you have to do to comply with jsr115 is to extends RealmBase and override: - hasUserDataPermission - hasRole - hasResourcePermission - findSecurityConstraint A couple of months ago (search the tomcat-dev list) we have discussed the possibility of implementing jsr115 directly into Tomcat. Still on my plate (don't know when) J2EE 1.4 RI contains Tomcat 5 powered by jsr 115. The problem with jsr115 is you have to run under a Security Manager, and this is for sure slower than the current native implementation. -- Jeanfrancois Brian Stansberry WAN Concepts, Inc. www.wanconcepts.com Tel:(510) 894-0114 x 116 Fax:(510) 797-3005 - 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: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Jeanfrancois Arcand wrote: Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. All you have to do to comply with jsr115 is to extends RealmBase and override: - hasUserDataPermission - hasRole - hasResourcePermission - findSecurityConstraint A couple of months ago (search the tomcat-dev list) we have discussed the possibility of implementing jsr115 directly into Tomcat. Still on my plate (don't know when) J2EE 1.4 RI contains Tomcat 5 powered by jsr 115. The problem with jsr115 is you have to run under a Security Manager, and this is for sure slower than the current native implementation. I think you'll have an opportunity to make your changes if you want to, since we'll have some refactoring to do on the realm before the next stable 5.0.x release occurs. Did you do benches ? Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example. I wouldn't be surprised if the last one benches as well as the first one (which would be really cool). Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Remy Maucherat wrote: Jeanfrancois Arcand wrote: Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. All you have to do to comply with jsr115 is to extends RealmBase and override: - hasUserDataPermission - hasRole - hasResourcePermission - findSecurityConstraint A couple of months ago (search the tomcat-dev list) we have discussed the possibility of implementing jsr115 directly into Tomcat. Still on my plate (don't know when) J2EE 1.4 RI contains Tomcat 5 powered by jsr 115. The problem with jsr115 is you have to run under a Security Manager, and this is for sure slower than the current native implementation. I think you'll have an opportunity to make your changes if you want to, since we'll have some refactoring to do on the realm before the next stable 5.0.x release occurs. That's a pretty good opportunityFor reference, here is the link to my original proposal http://www.mail-archive.com/[EMAIL PROTECTED]/msg39894.html My original idea was to remove the current Authenticator - Realm dependency. Currently, the Realm is doing Authorization and Authentication, which I think should be splitted. Did you do benches ? Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example. I wouldn't be surprised if the last one benches as well as the first one (which would be really cool). Not yet, but it is one of the thing I want to do when I've found spare time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager + jsr115) since with 115, the policy provider is called everytime hasUser/ResourcePermission are called, and this approach cannot beat the current way of doing. On the original topic, I think I've missed the spec change from pfd3 and fcs. I was under the wrong impression that Bill's last changes on the RealmAdapter was related to that changes (I was completely wrong). I will try to find the reason whythe change was make... Now the only problem I'm seeing with Phillipe's work is Strings are used everywhere and that may have a performance impact. It may be time to start using MessageByte. -- Jeanfrancois Rémy - 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: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Jeanfrancois Arcand wrote: Remy Maucherat wrote: Jeanfrancois Arcand wrote: Brian Stansberry wrote: At 10:03 PM 12/8/2003 -0800, you wrote: The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. So soon after such a major release it seems foolhardy to bring this up, but Phillipe's post seems to have opened a can of worms Are there any plans to do anything about JSR-115? As it's part of the J2EE 1.4 spec, I would think that for a compliant appserver to embed Tomcat (any others besides JBoss??), Tomcat would need to comply. I bring this up because if there is consideration of API changes to deal w/ the Servlet 2.4 authorization handling, it might be a good time to look into it. I'd be happy to help in such an effort if there is any interest. All you have to do to comply with jsr115 is to extends RealmBase and override: - hasUserDataPermission - hasRole - hasResourcePermission - findSecurityConstraint A couple of months ago (search the tomcat-dev list) we have discussed the possibility of implementing jsr115 directly into Tomcat. Still on my plate (don't know when) J2EE 1.4 RI contains Tomcat 5 powered by jsr 115. The problem with jsr115 is you have to run under a Security Manager, and this is for sure slower than the current native implementation. I think you'll have an opportunity to make your changes if you want to, since we'll have some refactoring to do on the realm before the next stable 5.0.x release occurs. That's a pretty good opportunityFor reference, here is the link to my original proposal http://www.mail-archive.com/[EMAIL PROTECTED]/msg39894.html My original idea was to remove the current Authenticator - Realm dependency. Currently, the Realm is doing Authorization and Authentication, which I think should be splitted. Did you do benches ? Comparing (4.1.x) vs (5.0.x) vs (5.0.x + sec manager), for example. I wouldn't be surprised if the last one benches as well as the first one (which would be really cool). Not yet, but it is one of the thing I want to do when I've found spare time. For sure (5.0.x + sec manager) is faster than (5.0.x + sec manager + jsr115) since with 115, the policy provider is called everytime hasUser/ResourcePermission are called, and this approach cannot beat the current way of doing. On the original topic, I think I've missed the spec change from pfd3 and fcs. I was under the wrong impression that Bill's last changes on the RealmAdapter was related to that changes (I was completely wrong). I will try to find the reason whythe change was make... Now the only problem I'm seeing with Phillipe's work is Strings are used everywhere and that may have a performance impact. It may be time to start using MessageByte. That's the idea. If you're inside the container and you consider it a critical section for whatever reason, then strings are really evil, and you should use MessageBytes instead (or even ByteChunks if manipulating header values) ;-) I see supporing JSR 115 would be good, but making it disabled by default when there's a security manager would be the most reasonable. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Hi all, I am new to Tomcat's mailing lists, and I don't really know if this list is the right place for such a post : excuse me if it is not the case. I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems to do exactly what developers want it to do, but more a difference between the implementation of authorization policy (the handling of a Web Application web.xml security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says. Example of the problem (from the Tomcat Jsp-examples WebApp) : ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=admin password=tomcat roles=admin,manager,tomcat/ /tomcat-users tomcat-users.xml security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-nametomcat/role-name /auth-constraint /security-constraint security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-namerole1/role-name /auth-constraint /security-constraint !-- Default login configuration uses form-based authentication -- login-config auth-methodFORM/auth-method realm-nameExample Form-Based Authentication Area/realm-name form-login-config form-login-page/security/protected/login.jsp/form-login-page form-error-page/security/protected/error.jsp/form-error-page /form-login-config /login-config !-- Security roles referenced by this web application -- security-role role-namerole1/role-name /security-role security-role role-nametomcat/role-name /security-role webapps/jsp-examples/WEB-INF/web.xml (excerpt) I've been adding a new security-constraint element, separing the authorized roles each in its security-constraint According to what the Servlet 2.4 says (see below for exact reference), two security constraints on the same (url-pattern, http-method) should result in the addition of the given authorizations and so in this case, users tomcat, role1 and both should be authorized to access the protected resource. But here, it is the contrary : you can't access http://10.160.4.205:8080/jsp-examples/security/protected/ under tomcat or role1 identity any more, but you can still using the both identity : Tomcat has realized the intersection of the authorizations instead of doing the union. Analyze of the problem After inverstigating a while in the code, here is what I noticed : First, In SecurityConstraint[] RealmBase.findSecurityConstraints(HttpRequest request, Context context) (the method begins at l. 445 of the org.apache.catalina.realm.RealmBase file), each and every SecurityConstraint (= security-constraint in web.xml) containing a SecurityCollection (= web-ressource-collection in web.xml) containing a url-pattern matching the User's request URI and defining a restriction on the http-method used by the user for his request is retrieved, using boolean SecurityConstraint.included(String uri, String method) (method starts at line 343 of org.apache.catalina.deploy.SecurityConstraint) While only SecurityConstraints containing SecurityCollections containing the url-pattern which is the best-match to the User's request URI amongst all the url-patterns defined in web.xml should be retained first, and then amongst these remaining constraints we shall keep only the ones defining a restriction on the same method (or no restriction on the method, as stated in servlet-2_4-fr-spec.pdf, ch SRV 12-8-3, pp 100-101) Second in public boolean hasResourcePermission(HttpRequest request, HttpResponse response, SecurityConstraint constraint, Context context) (the method begins at line 501 of the org.apache.catalina.realm.RealmBase file) the restrictions on the
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Yes, this looks like it changed between pfd3 to fr :(. Security-constraints now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4 security model all but useless. whine It would be natural to configure something like: security-constraint web-resource-collection web-resource-nameClient Area/web-resource-name url-pattern/clients/*/url-pattern /web-resource-collection auth-constraint !-- Any authenticated user -- role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct1 Client Area/web-resource-name url-pattern/clients/product1/*/url-pattern /web-resource-collection auth-constraint !-- Any product1 user -- role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct2 Client Area/web-resource-name url-pattern/clients/product2/*/url-pattern /web-resource-collection auth-constraint !-- Any product2 user -- role-nameproduct2/role-name /auth-constraint /security-constraint The way the 2.4 spec is written, all authenticated users have access to everything under /myapp/clients/. To get what I want is now a configuration nightmare :(. /whine Now back to fixing things. I sort of like the idea of changing the Realm interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take a SecurityConstraint []. However, after a GA release, this may be a bit much. Philippe's solution looks a bit over-kill to me, but I'm not going to object if someone wants to commit it. I'm thinking of moving the header-setting stuff out of RealmBase and into AuthenticatorBase. It may cause some custom realms to stop working, but there shouldn't be that many for TC 5 yet :). Of course, I'm volunteering for the code-monkey (copy; Pier) part of this. Since anyway we go is a pretty big change, I just wanted to get a consensus first. Opinions, Comments, Flames? - Original Message - From: philippe.leothaud [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:43 PM Subject: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Hi all, I am new to Tomcat's mailing lists, and I don't really know if this list is the right place for such a post : excuse me if it is not the case. I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems to do exactly what developers want it to do, but more a difference between the implementation of authorization policy (the handling of a Web Application web.xml security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says. Example of the problem (from the Tomcat Jsp-examples WebApp) : ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=admin password=tomcat roles=admin,manager,tomcat/ /tomcat-users tomcat-users.xml security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-nametomcat/role-name /auth-constraint /security-constraint security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url-pattern !-- If you list http methods, only those methods are protected -- http-methodDELETE/http-method http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint !-- Anyone with one of the listed roles may access this area -- role-namerole1/role-name /auth-constraint /security-constraint !-- Default login configuration uses form-based authentication -- login-config auth-methodFORM/auth-method realm-nameExample Form-Based Authentication Area/realm-name form-login-config form-login-page/security/protected/login.jsp/form-login-page form-error-page/security/protected/error.jsp/form-error-page /form-login-config /login-config !-- Security roles referenced by this web application -- security-role role-namerole1/role-name /security-role
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Hi Bill, I totally agree with you, this security model is going to be a pain somewhere to correctly configure access rights... As of my solution, the real interest is that (as far as I can see) it doesn't change at all any API : the only thing that changes is the body of the method SecurityConstraint[] findSecurityConstraints(HttpRequest request, Context context) in org.apache.catalina.realm.RealmBase (starting at line 438), I only changed the body so that it calls the new MergedConstraintBuilder class. In any case, the signature remains the same. Today : 1- AuthenticatorBase gets all possible Constraints mathing the request, by calling SecurityConstraint [] constraints = realm.findSecurityConstraints(hrequest, this.context); (AuthenticatorBase , l. 502) 2- RealmBase handles that request, returning an array of all the Constraints matching the URI and the HTTP method of the request 3- AuthenticatorBase retrieves all these Constraints, cast the Request and Response into HttpServletRequest and HttpServletResponse (l 515-525) 4- For each Constraint of the array, AuthenticatorBase asks RealmBase if the UserDataPermission is OK 5- For each Constraint of the array, AuthenticatorBase asks RealmBase if the AuthConstraint is OK All that I change is what is happening in step 2 : - RealmBase asks the new Class to retrieve an Array of matching Constraints - The new Class builds a fake Constraint representing all possible AuthConstraints and UserDataConstraints for this (URI, HTTPMethod) - It returns an array of SecurityConstraints, just like before. The only difference is that now this array has only one (or zero) element, but neither RealmBase neither AuthenticatorBase are aware of that. All the remaining methods calls are just the same, they will just be faster because there is only one Constraint in the array (and I think that if the 10 lines of code needed to cache the fake Constraints are added in this new Class, it may really be faster and compute-time saving) . I used that for a custom authorization framework I'm working on and it's OK for me. Thanks for having replied quickly (It's difficult to work seriously while you're looking at your mail-box every minute to see if a response wasn't posted ;-) - Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Tuesday, December 09, 2003 6:00 AM Subject: Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Yes, this looks like it changed between pfd3 to fr :(. Security-constraints now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4 security model all but useless. whine It would be natural to configure something like: security-constraint web-resource-collection web-resource-nameClient Area/web-resource-name url-pattern/clients/*/url-pattern /web-resource-collection auth-constraint !-- Any authenticated user -- role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct1 Client Area/web-resource-name url-pattern/clients/product1/*/url-pattern /web-resource-collection auth-constraint !-- Any product1 user -- role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct2 Client Area/web-resource-name url-pattern/clients/product2/*/url-pattern /web-resource-collection auth-constraint !-- Any product2 user -- role-nameproduct2/role-name /auth-constraint /security-constraint The way the 2.4 spec is written, all authenticated users have access to everything under /myapp/clients/. To get what I want is now a configuration nightmare :(. /whine Now back to fixing things. I sort of like the idea of changing the Realm interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take a SecurityConstraint []. However, after a GA release, this may be a bit much. Philippe's solution looks a bit over-kill to me, but I'm not going to object if someone wants to commit it. I'm thinking of moving the header-setting stuff out of RealmBase and into AuthenticatorBase. It may cause some custom realms to stop working, but there shouldn't be that many for TC 5 yet :). Of course, I'm volunteering for the code-monkey (copy; Pier) part of this. Since anyway we go is a pretty big change, I just wanted to get a consensus first. Opinions, Comments, Flames? - Original Message - From: philippe.leothaud [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:43 PM Subject: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec - To unsubscribe, e
Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec
Ok, I take back my whine/. It seems that they have really made a hash out of the security-constraints. Something like Philippe's implementation is required. Section 12.8.3 requires that only the 'best match' constraints are processed, and those in a 'grant' fashion (i.e. you get the least restrictive privilege of the most restrictive constraints). Now you just need to be a rocket-scientist to figure out how your security-constraints work ;-). So in my example below, a request for /myapp/clients/product1/ will only consider the 'product1' constraint, and ignore the constraint for '/clients/*'. If I had added a security-constraint for '*.jsp', then a request for /myapp/clients/product1/index.jsp would use the 'product1' constraint, and ignore the '*.jsp' constraint. Isn't life going to be fun on the user-list ;-). This means that RealmBase.findSecurityConstraints is going to have to change to only pass back the 'best-match' constraints. At least this isn't an interface change. The decision on whether to change the Realm interface, or move the header processing to AuthenticatorBase is still open. - Original Message - From: Bill Barker [EMAIL PROTECTED] To: Tomcat Developers List [EMAIL PROTECTED] Sent: Monday, December 08, 2003 9:00 PM Subject: Re: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Yes, this looks like it changed between pfd3 to fr :(. Security-constraints now work like 'grants' instead of 'constraints'. IMHO, this make the 2.4 security model all but useless. whine It would be natural to configure something like: security-constraint web-resource-collection web-resource-nameClient Area/web-resource-name url-pattern/clients/*/url-pattern /web-resource-collection auth-constraint !-- Any authenticated user -- role-name*/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct1 Client Area/web-resource-name url-pattern/clients/product1/*/url-pattern /web-resource-collection auth-constraint !-- Any product1 user -- role-nameproduct1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameProduct2 Client Area/web-resource-name url-pattern/clients/product2/*/url-pattern /web-resource-collection auth-constraint !-- Any product2 user -- role-nameproduct2/role-name /auth-constraint /security-constraint The way the 2.4 spec is written, all authenticated users have access to everything under /myapp/clients/. To get what I want is now a configuration nightmare :(. /whine Now back to fixing things. I sort of like the idea of changing the Realm interface so that 'hasUserDataPermissions' and 'hasResourcePermissions' take a SecurityConstraint []. However, after a GA release, this may be a bit much. Philippe's solution looks a bit over-kill to me, but I'm not going to object if someone wants to commit it. I'm thinking of moving the header-setting stuff out of RealmBase and into AuthenticatorBase. It may cause some custom realms to stop working, but there shouldn't be that many for TC 5 yet :). Of course, I'm volunteering for the code-monkey (copy; Pier) part of this. Since anyway we go is a pretty big change, I just wanted to get a consensus first. Opinions, Comments, Flames? - Original Message - From: philippe.leothaud [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, December 08, 2003 6:43 PM Subject: Tomcat authorization handling seems not to function according to Servlet 2.4 Spec Hi all, I am new to Tomcat's mailing lists, and I don't really know if this list is the right place for such a post : excuse me if it is not the case. I wonder if I didn't notice something which is not a real bug in Tomcat, as it seems to do exactly what developers want it to do, but more a difference between the implementation of authorization policy (the handling of a Web Application web.xml security-constraint elements) in Tomcat5 and what the Servlet 2.4 Spec says. Example of the problem (from the Tomcat Jsp-examples WebApp) : ?xml version='1.0' encoding='utf-8'? tomcat-users role rolename=tomcat/ role rolename=role1/ role rolename=manager/ role rolename=admin/ user username=tomcat password=tomcat roles=tomcat/ user username=both password=tomcat roles=tomcat,role1/ user username=role1 password=tomcat roles=role1/ user username=admin password=tomcat roles=admin,manager,tomcat/ /tomcat-users tomcat-users.xml security-constraint display-nameExample Security Constraint/display-name web-resource-collection web-resource-nameProtected Area/web-resource-name !-- Define the context-relative URL(s) to be protected -- url-pattern/security/protected/*/url
