Thank you for your reply, Chris. I think I know where you are coming from when you say:
"Why would you override the authorization decisions made by the application developers? To be transparent: I'm a developer not an operations person nor do I work for a large company so my use-case is hypothetical rather than actual." But that assumes that you are running a dev-ops shop where the developers also control all the operations and are responsible for cybersecurity. This scenario works fine in small companies where dev-ops is the SOP, but in larger organizations, it's not really feasible. It's been my experience that IT departments separate security responsibilities from development responsibilities. They cooperate, but the security folks are the ultimate gatekeepers for encryption, authentication, and authorization. This is done for the same reason that larger organizations - with big IT departments - separate the role of managing the database from developers who use it. If I'm ACME Bank and I have a slew of contractors working on an application that will manage the client's finances I do not want the contractors to decide what security privileges users should have - that's the role of operations or management or if hosting the client. On Tue, Mar 3, 2020 at 7:51 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > 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. > > > So If I say on the tomcat web.xml that only Bill and Ted have > > access to path A, but an individual WAR's web.xml says that > > Everyone has access to Path A, then the WAR web.xml wins, right? > > Yes. (Bogus!) > > > 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". > > - -chris > > [1] https://tuckey.org/urlrewrite/ > > On Tue, Mar 3, 2020 at 7:04 AM Mark Thomas <ma...@apache.org> > > wrote: > > > >> On 03/03/2020 12:27, Richard Monson-Haefel wrote: > >>> I've tried to find this but keep running into the three remote > >>> address valves (address, IP, and CIDR) what I'm looking for is > >>> an access valve > >> that > >>> uses roles from a realm that checks roles to either path or > >>> web > >> application > >>> identifiers - not remote address. This is classic > >>> authorization - role-based authorization. > >> > >> Servlet specification, version 4, section 13.2 & 13.8 in > >> particular. > >> > >> Mark > >> > >> --------------------------------------------------------------------- > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > >> > > > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5eYMEACgkQHPApP6U8 > pFgR0RAApNme6FTo3wJ6GuJekpo4jMDFdavXtRR4f0yBJiHMve2iSzN9FELaJMp6 > 4rPgD0gNPA6BR/Sd4RSxJ2NcQ2zYiaboprJs3ub04LbruHcgrvPrcR8i/ZT7zm3R > TWvRQ47n2RkaVjvmdsZqGROQ6hSa6CHLgXSeWeDyBtjOnWNZIaXBdlpiyZlT8CAg > AT6PI6sehpx15KHEoSVxpS0zbHeLrkyIQqzKmyufZS4PMkROCQQr8Qr/SAmrpb67 > zF6Ulwq5wxhy5Zrp/wh2rUuBBm5TJEENR1RbeSuYFKP2Fb8pViUeNrtE1PKsAlBf > cYIL20+7H8Ib0aQgY9uCweIsKAHnOmmiZ2GHqKxarGjJ04iSz8P6IxyBMM1dAJJ9 > bbYOQ7hNFIerYtqlz2loEHmHcPJvEYCXVnHziWBDvPi39ajoc93TbmTcD7KHY8gC > NBAnFhloeCGN97gF1fplXB/YOEW2u3p2jLdjHKXJk3tAu94sMAhR1wjALAogo8Va > CVhO5BrJCJhSIENXmvvwzyeS0J4jns2LELTsgTY9wKj83IXb4lHuPWS1QUJ+Dq/D > bmhD6Apoo209Xg70X61Sz1LMyzNvSFXHyT84ZsQ19TKUFDRZFpWYuqqn+fsjZUUm > xP//Kx302VSAJORgMO6hhDqWuLxtVt5c711LIOMFPJ2veu4quS4= > =tOQV > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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/
