-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Richard,
On 3/3/20 09:14, Richard Monson-Haefel wrote: > 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. So like slide 1 of this presentation? https://tomcat.apache.org/presentations.html#latest-locking-down-tomcat If the people responsible for security can't tell the developers to fix something in the application, then there are much bigger problems than the isolation of sec and dev. > 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. This is what requirements-gathering exercises are all about. If you are a small devops shop, then it's all one thing. If you are a huge corporation, requirements-gathering is the world's most excruciating stage, because you can't do anything until ALL the requirements are laid out in insane detail. Security requirements go into this process. So I understand that sometimes, band-aids need to be put into place. But what you are asking for is a tourniquet. The band-aid is to hand-edit the web.xml file and fix the roles. Anything else should be so painful that you are forced to, ya know, TALK to your development tea m. - -chris > On Tue, Mar 3, 2020 at 7:51 AM Christopher Schultz < > ch...@christopherschultz.net> 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. > >>>> 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 >>>>> >>>>> >>>> >> >> --------------------------------------------------------------------- >> >> >> 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/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5ewUAACgkQHPApP6U8 pFhxNBAAudYkOGfmUlTHGJRbYL0okz3GBYIE3jlfk4ZNImkWkQSwGf9Fvvtiw09C nUjM2sL+bTiVraEpBVaYIepSJyJWoQOpNsv3P34TwhHgKGyjFrAQrABqaR2boJKA p2WoUuOzjriPLOKyH8vbDFWipnPUuDIn7upf/EYB4wLmNJJcn//oMECQ9wxyd6mv SUDR5FHH8mFZMmvVDbSHswWzW1IzrISyc4xy4txNLjlFnja1hlLHvU3GB1+XRo40 lgPOiPeT4vXnwNVHNjhNZ3sQcoIBfYdJQjfN7z9Gyy6klEDvqNGRMfdZJ9MgvL+l Jq7d6jiZvTZ4hbFXcSD9BEZZY0EAH5vZIcPnxyATBfVe2s8J/ayx1QMLLA+6wmud k9sGtGm7buKoMT+uzSxIhSzwk41Kk7NFw+4gUhRGxH96ZIBRdpiMi2pJJWLOylFg 5fo3BmyM0EMONk8jZWvsZKTFhdyff3BSBh+qep9r0YxHKaccMwsogor5s+LVPmOj LYfh7JhXXnKclF3F+QaHX9vr1Xd2wCJ7+cUNUJ1DC+EmJjw4WYLZx/CSJ7eOdA4X z/dLPyokNG4VMAAfXTVG6gi1jH2hoygaObRm3QlgZWq5i4Cbe8dmUyn8+oetEwL0 S0gTcLhdi9B2CXdDnyKDPSSS+ymrB6oilN2u1qRC6QUnqlfNlas= =uAu3 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
