• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Ron McLeod
  • paul wheaton
  • Jeanne Boyarsky
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
  • Himai Minh
Bartenders:

Conditionally protecting app by IP range

 
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have one web application that I want to conditionally protect from people, depending on their IP address.

If people come from a certain IP range (our intranet subnet) then I want them to be able to access the web application without the need to provide access credentials.

If people come from outside that IP range (working from home over the Internet) then I want them to log into the application with BASIC authentication (this will be against MySQL).

I am having trouble finding the bits and pieces in Tomcat to make this conditional protection work. If I put a remote address valve on the webapp, and the user is in the allowed range then it will work and allow them in. But if they are not in the range, then I can't figure out how to forward them onto BASIC authentication for the same web app in order to give them a second chance to prove themselves. It will simply deny them access instead of forwarding them onto a second chance with the BASIC authentication.

Has anyone any ideas for making this scenario work?

Cheers, Jared.
 
Author
Posts: 531
Mac OS X Netbeans IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
best option for you is to use a filter
you can check IP address in filter and chec its range or check it with subnet mask , now you can decide whether to allow visitor to proceed with his/her request or redirect it to your login page.

i suggest you checj

1-servlet filters
2-container managed security


hth
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I don't think you will be able to use either container-managed security or the RemoteAccess valve. The former will require authentication for all users, regardless of where they come from, while the latter can only allow or block requests based on their IP, but not redirect some.

How about checking the IP yourself, and if it's within the allowed range, forward to an unprotected URL (which of course must deny requests not forwarded from the IP-checking code), and if it's not within the allowed range, forward to a protected URL (which does the same thing as the unprotected URL, but only after authentication).
 
Ranch Hand
Posts: 405
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In my opinion, determing a level of security based on IP range is the not the direction you should proceed.

I believe you should force everyone to authenticate themselves whether they access your web site locally(intranet) or internet.

For example, what if a person(s), who happens to have an IP address that falls within your intranet IP range, try to access your website thru the internet.

This person will be allowed to access your website, just as a local user.
 
Jared Cope
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ulf Dittmer:
I don't think you will be able to use either container-managed security or the RemoteAccess valve. The former will require authentication for all users, regardless of where they come from, while the latter can only allow or block requests based on their IP, but not redirect some.



This is exactly what I wanted to hear from someone else. This is my assessment of the situation too.



How about checking the IP yourself, and if it's within the allowed range, forward to an unprotected URL (which of course must deny requests not forwarded from the IP-checking code), and if it's not within the allowed range, forward to a protected URL (which does the same thing as the unprotected URL, but only after authentication).



I think this is what I have to do. But it sounds like some custom programming. Please let me know if there is some ready made classes and stuff that I can just 'turn on' for this.

To make matters worse, we do not have the source code for the web application anymore. So changes to the code at that level are not an option for us. A re-write of the application is scheduled for March 2006, but we wanted to try and get this working somehow before then.

Thanks for your suggestions,

Cheers, Jared.
 
Jared Cope
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Craig Jackson:

I believe you should force everyone to authenticate themselves whether they access your web site locally(intranet) or internet.



I think it is a reasonable request from someone who turns up to work not to have to prove who they are before they can access the application. Working from home over the Internet is another story though.


For example, what if a person(s), who happens to have an IP address that falls within your intranet IP range, try to access your website thru the internet.



Of course that is a risk. But I am pretty sure that no one else can be on our intranet subnet. If this is not the case, then the rest of our business is in trouble, and getting Tomcat to work with all of this is the least of our worries. Being able to trust the Intranet address range is my main assumption in all of this, and I have no reason to doubt it.

Thanks for the advice though.

Cheers, Jared.
 
Jared Cope
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok,

I think my solution is going to come in the form of the apache-to-tomcat connector (http://tomcat.apache.org/tomcat-4.1-doc/jk2/index.html). I am going to use apache to field incoming requests and then pass them onto tomcat if the right conditions are satisfied, then apache will serve the page back to the user.

This way I can use the powerful apache access configuration directive such as:



I was hoping that Tomcat would have an analogous way to do the above, but so far it hasn't been obvious.

Cheers, Jared.
 
Jared Cope
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

For benefit of future readers, still no luck with this one. The apache-tomcat connector serves the tomcat generated content fine, but the access restriction directive is just never applied to the web application directory.

Once apache determines that tomcat must fulfill the request, it invokes tomcat without checking the rules first as I wanted to above. A little bit frustrating.

Cheers, Jared.
 
Ranch Hand
Posts: 245
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Instead of Directory (which is file system based) try Location (which is URL based). Apache doesn't ultimately know how the URL -> file system mapping is carried out once it sends to Tomcat.
 
Jared Cope
Ranch Hand
Posts: 243
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Scott Dunbar:
Instead of Directory (which is file system based) try Location (which is URL based).



Scott, you are a dead-set legend.

My apache config file now looks like:


All works as I originally wanted it to.

Thanks again,

Jared.
 
reply
    Bookmark Topic Watch Topic
  • New Topic