Write custom valve?

[Doug Black <do...@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@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Write custom valve?

[Filip Hanik - Dev Lists <de...@hanik.com>]

Doug Black wrote:
> 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?
>   
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

Filip
> 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@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>   


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Write custom valve?

[Johnny Kewl <jo...@kewlstuff.co.za>]

----- Original Message ----- 
From: "Doug Black" <do...@westrockvisions.com>
To: <us...@tomcat.apache.org>
Sent: Wednesday, July 25, 2007 9:58 PM
Subject: Re: Write custom valve?


> 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

Hi Doug, I think Filip and I are talking about the same mechanism, the only
difference is that Filip is answering your direct question, and showing you
how to approach it from, as you asked, the valve perspective, I'm trying to
show you a different way because Valves are
Tomcat specific, and version specific.
My concern is not so much the coding logic, its more that you will find when
you move from 5.5.17, to 5.5.23, to 6.0.13, your valve has to be modified
every time.
Valves dig right into the TC engine, Filters are a standard.... I think
thats a more important consideration. With Valves, you have to study Tomcats
internals, and will get little help else where, with filters, you can buy a
book.

>
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Write custom valve?

[Doug Black <do...@westrockvisions.com>]

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: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Write custom valve?

[Johnny Kewl <jo...@kewlstuff.co.za>]

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" <do...@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@tomcat.apache.org
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org