You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Richard Monson-Haefel <mo...@gmail.com> on 2020/03/03 12:27:15 UTC
Role/Path Based Access Valve?
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.
--
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/
Re: Role/Path Based Access Valve?
Posted by Richard Monson-Haefel <mo...@gmail.com>.
Thanks, Chris. As I said it was hypothetical but I appreciate the help!
On Tue, Mar 3, 2020 at 2:42 PM Christopher Schultz <
chris@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 <
> > chris@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-unsubscribe@tomcat.apache.org
> >>>>> For additional commands, e-mail:
> >>>>> users-help@tomcat.apache.org
> >>>>>
> >>>>>
> >>>>
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> >>
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/
Re: Role/Path Based Access Valve?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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 <
> chris@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-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail:
>>>>> users-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>>
>>
>>
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Role/Path Based Access Valve?
Posted by Richard Monson-Haefel <mo...@gmail.com>.
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 <
chris@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-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/
Re: Role/Path Based Access Valve?
Posted by Richard Monson-Haefel <mo...@gmail.com>.
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/
Re: Role/Path Based Access Valve?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Role/Path Based Access Valve?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Role/Path Based Access Valve?
Posted by Richard Monson-Haefel <mo...@gmail.com>.
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.
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?
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?
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
Richard Monson-Haefel
https://twitter.com/rmonson
https://www.linkedin.com/in/monsonhaefel/
Re: Role/Path Based Access Valve?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org