Thanks, Chris. As I said it was hypothetical but I appreciate the help! On Tue, Mar 3, 2020 at 2:42 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----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 > > -- Richard Monson-Haefel https://twitter.com/rmonson https://www.linkedin.com/in/monsonhaefel/
