Ok. That makes sense. Thanks again, Mark. On Tue, Mar 3, 2020 at 8:18 AM Mark Thomas <ma...@apache.org> wrote:
> On 03/03/2020 13:50, Christopher Schultz wrote: > > Richard, > > > > On 3/3/20 08:26, Richard Monson-Haefel wrote: > >> Thank you, Mark. I was actually aware of how to do it using the > >> web.xml. > > > >> I was looking for a valve that could do the same thing, and here is > >> the reason: > > > >> If I, as the Tomcat admin, want to manage access permissions > >> (authorization) I can use the /tomcat/conf/web.xml file. However, > >> this file is overridden by matching elements in an individual WAR. > > > > This will never work. If conf/web.xml is even allowed to set > > <security-constraints> (and I'm not sure either way), they would be > > relative to every web application and not relative to the server's > > root. IT would be very difficult to manage this in the way you describe. > > +1 > > >> If I use a valve I can short-circuit the process before it even > >> gets to the web application. In that way, no matter what the > >> developers put into the WAR I have multiple control from Tomcat. > >> Make sense? > > > > That does makes sense, but please help us understand the use-case. Why > > would you override the authorization decisions made by the > > application's developers? > > > > I'm not sure if you can do this at the "Server level", but you can use > > url-rewrite[1] to reject URLs based upon the logged-in user's roles. > > Search the user's manual for "user-in-role". > > The real difficulty here is that you are fighting how Java EE (and now > Jakarta EE) are architected / designed / intended to be used. > > The expectation is that security constraints are defined using roles in > web.xml and then users are mapped to roles in the container. > > If is often the case the application defined roles don't map to the > organisation roles in the authentication system. The fix for > https://bz.apache.org/bugzilla/show_bug.cgi?id=55477 should help with > that but that is still in discussion (it has been quiet for a while). > > Mark > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- Richard Monson-Haefel https://twitter.com/rmonson https://www.linkedin.com/in/monsonhaefel/
