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