Filip Hanik - Dev Lists <devlists <at> hanik.com> writes:
> take the source code of the RemoteAddrValve and start there.
> Basically, in the valve is request.getPrincipal returns null, then
> redirect them to a URL that is protected by your web.xml and requires a
> login.
>
> remember to not trigger the valve on the "protected" urls
Johnny Kewl <john <at> kewlstuff.co.za> writes:
>
> Doug, I have never tried this, so as usual, I guessing here.
>
> I dont think you are going to come right with the standard valves, nor do I
> think you should try make a custom valve.
> Rather look at filters, they not much more difficult to make than a normal
> servlet, and you will find tons of stuff on the web, maybe the very thing
> you looking for.
> If you use netbeans, there is a standard project wizard that will get you
> going with a filter.
>
> The concept is interesting, and I'm thinking that you cant really protect
> the web pages with standard security, because if you do, I think that will
> kick in even before the filter gets a chance to look at it. Maybe other guys
> can think of another way, but I think that the pages will have to be
> protected by the filter, not by standard Web.xml configuration.
>
> So... luv this guessing stuff ;).... I think you effectively have to make
> one web page as your realm log on page, only this page you protect with the
> standard realm web.xml stuff. The rest are unprotected. Then your filter
> logic is something like this....
>
> If the IP or Host name is allowed.... let it through
> If its not allowed.... check the username because if the user is
> authenticated, there will be one.... if username let it through.... else if
> user name is null, redirect to logon page.
>
> Filters are a really nice things to learn, and I dont think its too
> difficult.... but I just wanted to warn you, that the filter will not be
> able to intercept realm security, rather it has to take over that function.
> So if the access is simple.... like if they can get into that login page,
> then they can go anywhere.... its easy, but if you have a site where some
> people can go some places and not others, then you going to find yourself
> rebuilding tomcats realm security roles... a lot of work... or doing
> something like setting a session variable that a pages has to check.... ie
> A,B and C users are allowed in here... ie if you need to filter pages on
> roles, the fun really starts.
>
> So think about it, because I think the devil is in the details, and in the
> end it may be easier to just make everyone log on.
>
> From a philosophical point of view... I dont think one should use ip filters
> to allow access... its not good security. So if you have a lazy boss that
> doesn't want to type in a password, and his IP must go thru, tell him he's a
> security risk, on the other hand if its a customer that wants that, with a
> big wallet... its probably ok;)
> I think everyone should log on, and that getting too far away from the
> standard security could get very tricky.... I think those valves are more
> intended to simply ban people that have become a pain in the behind, never
> to let the privileged through.
>
> Have fun....
>
> From: "Doug Black" <doug <at> westrockvisions.com>
>
> > How can I best pass ips allowed by a valve to pass through to my
> > application
> > while forcing ips that are denied to log in through a realm? The only
> > possible
> > behavior I can detect of either RemoteAddrValve or RemoteHostValve is to
> > force
> > requests through the IP or host filter and also through the user realm for
> > the
> > context. Do I have to write a custom valve java class? How hard is this
> > for an
> > intermediate Java writer? Any tips on how to do this?
> >
> > I apologize that I submitted essentially the same question a couple days
> > ago,
> > but I got no responses so I thought I'd try with a less verbose phrasing.
> >
> > Thanks, Doug
> >
> >
> > ---------------------------------------------------------------------
> > To start a new topic, e-mail: users <at> tomcat.apache.org
> > To unsubscribe, e-mail: users-unsubscribe <at> tomcat.apache.org
> > For additional commands, e-mail: users-help <at> tomcat.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users <at> tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe <at> tomcat.apache.org
> For additional commands, e-mail: users-help <at> tomcat.apache.org
>
>
Thanks Fillip and Johnny. First two follow up questions and then some
description of my plans and responses to some of Johnny's philosophical points.
If I understand both Fillip and Johnny correctly, 1) with the custom valve
approach I'm going to need three contexts but 2) with the jsp filter approach I
will need only one context but I can not use any Tomcat basic security checking
on that context (with the caveat that I can have checking of known violators,
spoofers, etc. at the context level if I don't already have it at the host
engine or still higher levels). Is this dichotomy right?
With the filter approach my logic would be as Johnny laid out:
> If the IP or Host name is allowed.... let it through
> If its not allowed.... check the username because if the user is
> authenticated, there will be one.... if username let it through.... else if
> user name is null, redirect to logon page.
But with the valve approach I would need a logic as below:
User urls to -> context A -> Check IPs with Valve ->
If request.Principal is null ->
redirect -> Context B -> check user authentication
If login Ok ->
redirect -> Context C (application context)
Else redirect -> Context C (application context)
Second question, if my valve logic is right, how do I insure that Context C can
only be reached by redirects from one of the other two contexts?
END of questions. Rest of reply is background info:
I will evaluate both approaches, writing a custom valve and using a filter. On
the valve side, starting with the source code for RemoteAddrValve is what I was
thinking, but its important for me to get this confirmed by someone else and its
really important to now know that the crux is with request.getPrincipal. On the
surface, using a custom valve sounds easy but I do fear the complications in
requirements for multiple contexts, as I think I see, and potential gotchas in
messing with basic security, as I think Johnny was guessing. On the filter side,
indeed there is much information on writing jsp filters on the web, including
the first hit in Google search for jsp filters, which was a whole chapter from a
Sun publication on the topic. To my chagrin, I knew nothing about filters so
Johnny's input has been vital. Probably the Tomcat books, etc. say nothing about
them because its a java jsp subject not a Tomcat subject. This looks like it is
the more kosher way to do this, but then I haven't yet found that almost already
complete filter to do what I want, which I might have starting with
RemoteAddrValve. I do use NetBeans so I will probably start with that standard
wizard that Johnny suggests.
On the philosophical question Johnny raises, Do I really need to do this?, the
answer is yes. My situtation is closer to the deep pocketed customer demand then
to the lazy boss demand. This is a database app that is sold by subscriptions to
institutional, primarily academic, customers. Everybody coming in from an IP
range controlled by a subscribing institution must be allowed in. This could
theoretically be hundreds of thousands of anonymous users. As well there are
some private customers, guest passes, and management logins that could be coming
in from any IP. An example of such a situation is Safari. I am surprised this is
not a more common need and thus surprised that there isn't a built-in way to
handle this in Tomcat (or Apache Webserver?). I guess it comes down to question
of where the division between security and server administration should be with
application development. I can see the argument that sorting out customers from
non-customers shouldn't be an administration/security task but I guess I was
lured by Tomcat literature that touts the virtue of lifting the general ip and
user filtering task from the application developer.
For now, the good news is I don't have provide different access to different
parts of the application, though that might be coming down the road.
Thanks, Doug
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
