RE: url-pattern and realms security
That is a concrete path and you must be joking if you are suggesting to explicitly define each and every URL as a web-resource. The idea of hierarchical authorization of resources is a very sound idea and other auth schemes follow this trickle-down idea that you secure the whole tree with a general user auth (everyone can see it) and then directories beneath that have content specific to groups and are secured as needed. Any new directory added that does not need special treatment is automatically secured under the general rule. Otherwise you'll likely have a heavy management burden of your deployment descriptor with 100s of web-resource tags. The spec is shallow here, I hope it will improve in the next version. From another angle, I don't want the root to be insecure and only subdirs be secured. No other option there that I know of... And yet another angle, if you use explicit url-patterns and a content developer drops in something that happens not to match it, it is not a secure item. Unless you are in complete control and have script parameters of content, it's not an option. -Original Message- From: Alexander Vavilin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 11:08 PM To: Tomcat Users List Subject: Re[2]: url-pattern and realms security Hello Colin, Of course, your /* directive will overwrite all. You should use more concrete names and paths. -- Best regards, Alexander mailto:[EMAIL PROTECTED] Friday, August 15, 2003, 4:53:36 AM, you wrote: MC Sorry sorry, web-resource-name elements are unique, just a copying MC error. MC -Original Message- MC From: Alexander Vavilin [mailto:[EMAIL PROTECTED] MC Sent: Thursday, August 14, 2003 10:33 PM MC To: Tomcat Users List MC Subject: Re: url-pattern and realms security MC Hello Colin, MC I am not sure, but I think you cannot do this, first an web-resource-name MC element means an UNIQUE name. Can you understand ? You must give it MC different names. Second thing, I never heard about http-method element. MC Hope it will help. - 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: url-pattern and realms security
Madere, Colin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] That is a concrete path and you must be joking if you are suggesting to explicitly define each and every URL as a web-resource. The idea of hierarchical authorization of resources is a very sound idea and other auth schemes follow this trickle-down idea that you secure the whole tree with a general user auth (everyone can see it) and then directories beneath that have content specific to groups and are secured as needed. Any new directory added that does not need special treatment is automatically secured under the general rule. Otherwise you'll likely have a heavy management burden of your deployment descriptor with 100s of web-resource tags. The spec is shallow here, I hope it will improve in the next version. The Servlet 2.4 spec is *very* specific here. Basically, the Servlet-Container (aka Tomcat) is required to merge security-constraints. I've heard rumors on other lists that what exactly the specifics are may change before the spec goes final, so it may not be what is currently available as pfd3. I'm not (personally) on the JCP, so you should treat this as rumor and innuendo ;-). From another angle, I don't want the root to be insecure and only subdirs be secured. No other option there that I know of... And yet another angle, if you use explicit url-patterns and a content developer drops in something that happens not to match it, it is not a secure item. Unless you are in complete control and have script parameters of content, it's not an option. -Original Message- From: Alexander Vavilin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 11:08 PM To: Tomcat Users List Subject: Re[2]: url-pattern and realms security Hello Colin, Of course, your /* directive will overwrite all. You should use more concrete names and paths. -- Best regards, Alexander mailto:[EMAIL PROTECTED] Friday, August 15, 2003, 4:53:36 AM, you wrote: MC Sorry sorry, web-resource-name elements are unique, just a copying MC error. MC -Original Message- MC From: Alexander Vavilin [mailto:[EMAIL PROTECTED] MC Sent: Thursday, August 14, 2003 10:33 PM MC To: Tomcat Users List MC Subject: Re: url-pattern and realms security MC Hello Colin, MC I am not sure, but I think you cannot do this, first an web-resource-name MC element means an UNIQUE name. Can you understand ? You must give it MC different names. Second thing, I never heard about http-method element. MC Hope it will help. - 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]
url-pattern and realms security
So I looked at the servlet spec, but it doesn't specify (as far as I read) how hierarchical security constraints should work and Tomcat 4.1.27 seems to not do hiarachical constraints :) Also searching the list I didn't turn up results of this type, although I swear I've seen this issue before... I want to secure /* with a standard role and then /stuff1 with another role and /stuff2 with yet another role. So I put in the web.xml: security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namestandard/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/stuff1/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameusertype1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/stuff2/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameusertype2/role-name /auth-constraint /security-constraint But the second two seem to be overriden by the first. (A link on a WebLogic site shows the above to work, but I don't have WebLogic) Is this known behavior or did I miss something? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: url-pattern and realms security
Hello Colin, I am not sure, but I think you cannot do this, first an web-resource-name element means an UNIQUE name. Can you understand ? You must give it different names. Second thing, I never heard about http-method element. Hope it will help. -- Best regards, Alexander mailto:[EMAIL PROTECTED] Friday, August 15, 2003, 1:38:17 AM, you wrote: MC So I looked at the servlet spec, but it doesn't specify (as far as I read) MC how hierarchical security constraints should work and Tomcat 4.1.27 seems to MC not do hiarachical constraints :) Also searching the list I didn't turn up MC results of this type, although I swear I've seen this issue before... MC I want to secure /* with a standard role and then /stuff1 with another MC role and /stuff2 with yet another role. MC So I put in the web.xml: MC security-constraint MC web-resource-collection MC web-resource-nameGeneral Secured content root/web-resource-name MC url-pattern/*/url-pattern MC http-methodGET/http-method MC http-methodPOST/http-method MC /web-resource-collection MC auth-constraint MC role-namestandard/role-name MC /auth-constraint MC /security-constraint MC security-constraint MC web-resource-collection MC web-resource-nameGeneral Secured content root/web-resource-name MC url-pattern/stuff1/url-pattern MC http-methodGET/http-method MC http-methodPOST/http-method MC /web-resource-collection MC auth-constraint MC role-nameusertype1/role-name MC /auth-constraint MC /security-constraint MC security-constraint MC web-resource-collection MC web-resource-nameGeneral Secured content root/web-resource-name MC url-pattern/stuff2/url-pattern MC http-methodGET/http-method MC http-methodPOST/http-method MC /web-resource-collection MC auth-constraint MC role-nameusertype2/role-name MC /auth-constraint MC /security-constraint MC But the second two seem to be overriden by the first. (A link on a WebLogic MC site shows the above to work, but I don't have WebLogic) MC Is this known behavior or did I miss something? MC - MC To unsubscribe, e-mail: [EMAIL PROTECTED] MC For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: url-pattern and realms security
Sorry sorry, web-resource-name elements are unique, just a copying error. -Original Message- From: Alexander Vavilin [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 10:33 PM To: Tomcat Users List Subject: Re: url-pattern and realms security Hello Colin, I am not sure, but I think you cannot do this, first an web-resource-name element means an UNIQUE name. Can you understand ? You must give it different names. Second thing, I never heard about http-method element. Hope it will help. -- Best regards, Alexander mailto:[EMAIL PROTECTED] Friday, August 15, 2003, 1:38:17 AM, you wrote: MC So I looked at the servlet spec, but it doesn't specify (as far as I MC read) how hierarchical security constraints should work and Tomcat MC 4.1.27 seems to not do hiarachical constraints :) Also searching MC the list I didn't turn up results of this type, although I swear MC I've seen this issue before... MC I want to secure /* with a standard role and then /stuff1 with MC another role and /stuff2 with yet another role. MC So I put in the web.xml: MC security-constraint MC web-resource-collection MC web-resource-nameGeneral Secured content root/web-resource-name MC url-pattern/*/url-pattern MC http-methodGET/http-method MC http-methodPOST/http-method MC /web-resource-collection MC auth-constraint MC role-namestandard/role-name MC /auth-constraint MC /security-constraint MC security-constraint MC web-resource-collection MC web-resource-nameGeneral Secured content root/web-resource-name MC url-pattern/stuff1/url-pattern MC http-methodGET/http-method MC http-methodPOST/http-method MC /web-resource-collection MC auth-constraint MC role-nameusertype1/role-name MC /auth-constraint MC /security-constraint MC security-constraint MC web-resource-collection MC web-resource-nameGeneral Secured content root/web-resource-name MC url-pattern/stuff2/url-pattern MC http-methodGET/http-method MC http-methodPOST/http-method MC /web-resource-collection MC auth-constraint MC role-nameusertype2/role-name MC /auth-constraint MC /security-constraint MC But the second two seem to be overriden by the first. (A link on a MC WebLogic site shows the above to work, but I don't have WebLogic) MC Is this known behavior or did I miss something? MC MC - MC To unsubscribe, e-mail: [EMAIL PROTECTED] MC For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re[2]: url-pattern and realms security
Hello Colin, Of course, your /* directive will overwrite all. You should use more concrete names and paths. -- Best regards, Alexander mailto:[EMAIL PROTECTED] Friday, August 15, 2003, 4:53:36 AM, you wrote: MC Sorry sorry, web-resource-name elements are unique, just a copying error. MC -Original Message- MC From: Alexander Vavilin [mailto:[EMAIL PROTECTED] MC Sent: Thursday, August 14, 2003 10:33 PM MC To: Tomcat Users List MC Subject: Re: url-pattern and realms security MC Hello Colin, MC I am not sure, but I think you cannot do this, first an web-resource-name MC element means an UNIQUE name. Can you understand ? You must give it MC different names. Second thing, I never heard about http-method element. MC Hope it will help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: url-pattern and realms security
It's a Tomcat implementation detail, but I believe that 4.1.x does a first-match (so moving /* to the end of the list should work). The Servlet 2.4 spec is much more specific about what to do in your case, so Tomcat 5 and WebLogic should do the same thing when they come out. Madere, Colin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So I looked at the servlet spec, but it doesn't specify (as far as I read) how hierarchical security constraints should work and Tomcat 4.1.27 seems to not do hiarachical constraints :) Also searching the list I didn't turn up results of this type, although I swear I've seen this issue before... I want to secure /* with a standard role and then /stuff1 with another role and /stuff2 with yet another role. So I put in the web.xml: security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namestandard/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/stuff1/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameusertype1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/stuff2/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameusertype2/role-name /auth-constraint /security-constraint But the second two seem to be overriden by the first. (A link on a WebLogic site shows the above to work, but I don't have WebLogic) Is this known behavior or did I miss something? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: url-pattern and realms security
So simple, gotta love those. All is working as desired. Thanks Bill! -Original Message- From: Bill Barker [mailto:[EMAIL PROTECTED] Sent: Thursday, August 14, 2003 11:27 PM To: [EMAIL PROTECTED] Subject: Re: url-pattern and realms security It's a Tomcat implementation detail, but I believe that 4.1.x does a first-match (so moving /* to the end of the list should work). The Servlet 2.4 spec is much more specific about what to do in your case, so Tomcat 5 and WebLogic should do the same thing when they come out. Madere, Colin [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] So I looked at the servlet spec, but it doesn't specify (as far as I read) how hierarchical security constraints should work and Tomcat 4.1.27 seems to not do hiarachical constraints :) Also searching the list I didn't turn up results of this type, although I swear I've seen this issue before... I want to secure /* with a standard role and then /stuff1 with another role and /stuff2 with yet another role. So I put in the web.xml: security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-namestandard/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/stuff1/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameusertype1/role-name /auth-constraint /security-constraint security-constraint web-resource-collection web-resource-nameGeneral Secured content root/web-resource-name url-pattern/stuff2/url-pattern http-methodGET/http-method http-methodPOST/http-method /web-resource-collection auth-constraint role-nameusertype2/role-name /auth-constraint /security-constraint But the second two seem to be overriden by the first. (A link on a WebLogic site shows the above to work, but I don't have WebLogic) Is this known behavior or did I miss something? - 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]
