You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Caldarale, Charles R" <Ch...@unisys.com> on 2012/12/01 00:04:04 UTC
RE: Context Path for a subdirectory
> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
> Subject: RE: Context Path for a subdirectory
> what were my options to restrict access to just a subdirectory of a
> web app in Tomcat 6.0.35?
Using just spec-provided mechanisms, such access can be limited to specific users by including the appropriate security constraint elements in the webapp's WEB-INF/web.xml. The wrinkle you want is to limit by IP address, which is not a capability the servlet spec covers.
> I'll admit, contexts are confusing to me.
The main thing to remember is that each webapp (context) is expected to be physically separate from all other webapps. (This has nothing to do with the URLs used to access the webapps, just the location of the webapps in the server's file system, database, memory, paper tape, or whatever medium they're stored on.)
> What is the right way to do this in Tomcat 6.0.35?
Probably the easiest is just to pick up the filter from Tomcat 7 and use it in 6. The SecurityFilter from sourceforge might be able to do it, but I'm not sure (Chris should know).
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 11/30/12 7:07 PM, Leo Donahue - RDSA IT wrote:
>> -----Original Message----- From: Leo Donahue - RDSA IT
>> [mailto:LeoDonahue@mail.maricopa.gov] Sent: Friday, November 30,
>> 2012 5:02 PM To: Tomcat Users List Subject: RE: Context Path for
>> a subdirectory
>>
>>
>> The way the Server 1 is configured, there are accounts that the
>> rest/admin web app will take which let you do things like
>> shutdown the services and other stuff, if you were able to brute
>> force the rest/admin username/password.
>>
>
> That would only do you any good if you knew the internal server
> name. But I have to protect from internal threats as well, right?
Now, you're thinking properly ;)
Just remember that you asked to be able to restrict by IP address.
Well, an internal threat might be able to come from that IP address,
so you might want credentials that can be relatively quickly revoked.
I suppose you could change the IP whitelist, but then maybe you'll
have to figure out what the new blessed IP will be...
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5eTQACgkQ9CaO5/Lv0PB6PwCdHxGgWyhTjvxfq/sUuelnXI2I
2CUAn2XccinoszoRrw6H52zgZj73WyB3
=XjhS
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>Sent: Friday, November 30, 2012 5:02 PM
>To: Tomcat Users List
>Subject: RE: Context Path for a subdirectory
>
>
>The way the Server 1 is configured, there are accounts that the rest/admin
>web app will take which let you do things like shutdown the services and
>other stuff, if you were able to brute force the rest/admin
>username/password.
>
That would only do you any good if you knew the internal server name. But I have to protect from internal threats as well, right?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Leo,
On 11/30/12 7:02 PM, Leo Donahue - RDSA IT wrote:
> Any changes that I make to the rest web app are done on Server 1,
> in which I then need to generate a new rest.war file to be deployed
> on Server 4. Anything custom that I configure for the rest webapp,
> like the filter in web.xml, I have to remember to unpack the war
> file, make edits and re-pack it, or leave it exploded.
I highly recommend that you script this. Apache ant is great for this
stuff. It's got tasks for unwarring WAR files, re-warring WAR files,
performing XSLT transformations, string-replacements, merging
directories together into archives (like WARs), etc.
It's quite easy to do this kind of stuff.
For instance, we have a Cocoon-based webapp that unpacks a pre-built
Cocoon WAR file, compiles some custom Cocoon-based components against
it, re-wires the XML-based configurations using XSLT, then re-builds
the WAR file so it's ready for deployment. Nothing to "remember"
except pushing the button.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5eLEACgkQ9CaO5/Lv0PDIhgCgp3iiao79N9fQPgE9IAqLEFvt
1RQAnA8Al9G1NJcEXBkajijEtoIxI1cX
=GQwZ
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: André Warnier [mailto:aw@ice-sa.com]
>Sent: Friday, November 30, 2012 4:45 PM
>To: Tomcat Users List
>Subject: Re: Context Path for a subdirectory
>
>Maybe a bit of lateral thinking here.
>What does the admin webapp really do ? For what it is doing, does it need to
>even "live"
>in the same website/host as the main application ?
>If it's actions are confined to managing some files on disk, or some data in a
>back-end database, maybe it can do that without being really integrated into
>your main application ?
>You could then set up a separate Host, running under SSL or whatever, to run
>this admin part. It's URL would never be visible under your main site. And
>you'd have all the flexibility to set up any security constraints you want,
>without interfering with the main user site.
>
Fair question.
The "rest" web app was configured using a product called ArcGIS Server. There are at least 4 servers involved in the end product you see.
Server 1 - The ArcGIS Server - This is where you publish map documents as web services, and where you can export the "web services handler" (rest.war) to a production web server. Which I've done.
Server 2 - The ArcSDE Server - This is where the GIS data physically resides in a SQL Server.
Server 3 - The GIS Storage server - This is where Server 1 writes out the map images you see. I have a context on Server 4 that maps to a share on Server 3 as a virtual output directory.
Server 4 - The production Tomcat server - This is where I deploy the rest web app that is created from Server 1
Any changes that I make to the rest web app are done on Server 1, in which I then need to generate a new rest.war file to be deployed on Server 4. Anything custom that I configure for the rest webapp, like the filter in web.xml, I have to remember to unpack the war file, make edits and re-pack it, or leave it exploded. Changes can be things like adding new output directories, map cache directories, adding features like the ability to generate KMZ files for Google Earth, and there is even an option to configure deploying the rest.war file with a security store.
The rest/admin web app has one thing that I need, which is a clear cache feature. Any new web services that you deploy, or changes you make to existing services such as changing the color of a feature or what not, have to have the cache cleared.
The way the Server 1 is configured, there are accounts that the rest/admin web app will take which let you do things like shutdown the services and other stuff, if you were able to brute force the rest/admin username/password.
Leo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Context Path for a subdirectory
Posted by André Warnier <aw...@ice-sa.com>.
Leo Donahue - RDSA IT wrote:
>> -----Original Message-----
>> From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
>> Sent: Friday, November 30, 2012 4:04 PM
>> To: Tomcat Users List
>> Subject: RE: Context Path for a subdirectory
>>
>>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>>> Subject: RE: Context Path for a subdirectory
>>> what were my options to restrict access to just a subdirectory of a
>>> web app in Tomcat 6.0.35?
>> Using just spec-provided mechanisms, such access can be limited to specific
>> users by including the appropriate security constraint elements in the
>> webapp's WEB-INF/web.xml. The wrinkle you want is to limit by IP address,
>> which is not a capability the servlet spec covers.
>>
>>> I'll admit, contexts are confusing to me.
>> The main thing to remember is that each webapp (context) is expected to be
>> physically separate from all other webapps. (This has nothing to do with the
>> URLs used to access the webapps, just the location of the webapps in the
>> server's file system, database, memory, paper tape, or whatever medium
>> they're stored on.)
>>
>>> What is the right way to do this in Tomcat 6.0.35?
>> Probably the easiest is just to pick up the filter from Tomcat 7 and use it in 6.
>> The SecurityFilter from sourceforge might be able to do it, but I'm not sure
>> (Chris should know).
>>
>> - Chuck
>>
>
> I considered the security constraint, but wouldn't that have required me to set up SSL (for a secure user/password submittal) and get someone to pay for a public certificate - which would probably not happen. Sure, I could generate a cert myself. But I would still have to convince our office of enterprise tech that leaving an admin related webapp visible to the public is ok (authentication enabled or not). The last admin related webapp on our site had to be restricted by a valve, but that was for the whole context.
>
> The software company that we use also provides these kinds of web services to the whole world. They don't even bother restricting their /rest/admin directory, which really surprises me. Maybe I'm being paranoid by trying to one up them.
>
...
Maybe a bit of lateral thinking here.
What does the admin webapp really do ? For what it is doing, does it need to even "live"
in the same website/host as the main application ?
If it's actions are confined to managing some files on disk, or some data in a back-end
database, maybe it can do that without being really integrated into your main application ?
You could then set up a separate Host, running under SSL or whatever, to run this admin
part. It's URL would never be visible under your main site. And you'd have all the
flexibility to set up any security constraints you want, without interfering with the main
user site.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
> Subject: RE: Context Path for a subdirectory
> I considered the security constraint, but wouldn't that have required me
> to set up SSL (for a secure user/password submittal) and get someone to
> pay for a public certificate - which would probably not happen.
No, SSL is not required (that's called transport guarantee in the spec). However, not using it means that the credentials could be sniffed by anyone with access to the wire.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Context Path for a subdirectory
Posted by Leo Donahue - RDSA IT <Le...@mail.maricopa.gov>.
>-----Original Message-----
>From: Caldarale, Charles R [mailto:Chuck.Caldarale@unisys.com]
>Sent: Friday, November 30, 2012 4:04 PM
>To: Tomcat Users List
>Subject: RE: Context Path for a subdirectory
>
>> From: Leo Donahue - RDSA IT [mailto:LeoDonahue@mail.maricopa.gov]
>> Subject: RE: Context Path for a subdirectory
>
>> what were my options to restrict access to just a subdirectory of a
>> web app in Tomcat 6.0.35?
>
>Using just spec-provided mechanisms, such access can be limited to specific
>users by including the appropriate security constraint elements in the
>webapp's WEB-INF/web.xml. The wrinkle you want is to limit by IP address,
>which is not a capability the servlet spec covers.
>
>> I'll admit, contexts are confusing to me.
>
>The main thing to remember is that each webapp (context) is expected to be
>physically separate from all other webapps. (This has nothing to do with the
>URLs used to access the webapps, just the location of the webapps in the
>server's file system, database, memory, paper tape, or whatever medium
>they're stored on.)
>
>> What is the right way to do this in Tomcat 6.0.35?
>
>Probably the easiest is just to pick up the filter from Tomcat 7 and use it in 6.
>The SecurityFilter from sourceforge might be able to do it, but I'm not sure
>(Chris should know).
>
> - Chuck
>
I considered the security constraint, but wouldn't that have required me to set up SSL (for a secure user/password submittal) and get someone to pay for a public certificate - which would probably not happen. Sure, I could generate a cert myself. But I would still have to convince our office of enterprise tech that leaving an admin related webapp visible to the public is ok (authentication enabled or not). The last admin related webapp on our site had to be restricted by a valve, but that was for the whole context.
The software company that we use also provides these kinds of web services to the whole world. They don't even bother restricting their /rest/admin directory, which really surprises me. Maybe I'm being paranoid by trying to one up them.
http://services.arcgisonline.com/ArcGIS/rest/services
http://services.arcgisonline.com/ArcGIS/rest/admin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Context Path for a subdirectory
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 11/30/12 6:04 PM, Caldarale, Charles R wrote:
> The SecurityFilter from sourceforge might be able to do it, but I'm
> not sure (Chris should know).
Nope, sf doesn't have IP filtering built into it.
In my private copy, it's got the ability to restrict a session to a
specific IP, but I never bothered committing that to the repo because
it seemed so trivial.
Plus, another release of sf in its current form is seriously unlikely.
I think what I might end up doing is changing the project to "security
filters" and just package a few very useful tools that can be used
together. Either that or change the project page to redirect to Spring
Security.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iEYEARECAAYFAlC5d40ACgkQ9CaO5/Lv0PBtkQCfYwUhJudfAIBm6eIX9Dv+kb8l
yvkAn22BSFNvrHBxF9/AuQJaQ4K83/bN
=NqPw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org