Re: Source IP filtering on some URLs before Container-managed authentication
Andre, On 20.11.2015 17:44, André Warnier (tomcat) wrote: Well, you can use a lot more conditions in urlrewrite filter, such as a client IP + URL patterns + lots more. And you can combine them using the type="next". Your original post said "My webapp have a set of resources, let's call that set R. Some of those resources need to be accessed only from certain source IP addresses, let's call that subset R'. And some subset of R' (let's call it R'') needs authentication." So if I get this correctly, for R'' you have 3 requirements : - a URL matching R'' (check with "request-url" or "request-uri") - a remote IP (check with "remote_addr") - an authenticated user (check with "remote_user" not blank) and if it does not match the last 2, return "not found" or "forbidden" or a login page (or anything else that strikes your fancy) Thanks for calrifying. I am using urlrewritefilter, for some basic stuff, but I will take a look if it can also be used for this scenario. -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Source IP filtering on some URLs before Container-managed authentication
On 20.11.2015 17:00, Ognjen Blagojevic wrote: Andre, Chris, On 20.11.2015 9:30, André Warnier (tomcat) wrote: On 19.11.2015 21:26, Christopher Schultz wrote: I think that may be the only way to do it. IIRC, someone did some work to allow Filters to be used in the valve chain, but I don't think there is any facility for specifying s for those. Or, you could switch from container-based AAA, to application-based AAA. You can create a servlet filter which "wraps" your application(s), and in it apply any rules you want. This is totally portable, not Tomcat-specific, and doesn't require any change to server.xml for instance (nor to your application). Thank you both for looking into this. Ok, so it is a choice, either - move RemoteAddrFilter to become a Realm in front of Authenticator Valve, or - move Authenticator valve to become a Filter behind RemoteAddrFilter. To avoid having to redo what others have already done, you may also want to have a look at : http://tuckey.org/urlrewrite/manual/3.0/#filterparams see : element --> remote-addr (for instance) (I'm not saying that urlrewrite fills /all/ your needs, but you could combine urlrewrite with some simple code of your own, to fill all your needs. (snip)). This part I don't get. What is the added value of using urlrewrite compared to RemoteAddrFilter? It is basically the same functionality? Well, you can use a lot more conditions in urlrewrite filter, such as a client IP + URL patterns + lots more. And you can combine them using the type="next". Your original post said "My webapp have a set of resources, let's call that set R. Some of those resources need to be accessed only from certain source IP addresses, let's call that subset R'. And some subset of R' (let's call it R'') needs authentication." So if I get this correctly, for R'' you have 3 requirements : - a URL matching R'' (check with "request-url" or "request-uri") - a remote IP (check with "remote_addr") - an authenticated user (check with "remote_user" not blank) and if it does not match the last 2, return "not found" or "forbidden" or a login page (or anything else that strikes your fancy) then, (with "next"="or") for R' you have 2 requirements : - a URL matching R' (check with "request-url" or "request-uri") - a remote IP (check with "remote_addr") and if it does not match the last, return "not found" or "forbidden" or a login page (or anything else that strikes your fancy) and for the rest, nothing, which is what urlrewrite will do by default : let the request through. Note that I haven't really tried the above. It just looks as if it might fill your needs. If you do not know urlrewrite yet, it is worth investigating anyway; it is a nice piece of work, useful in many circumstances. The above is just an expression of my general view of things. I interpret 12.2 and 12.3 of the servlet spec as saying that container-based authentication is meant to match general cases, and if you want more specific things, you should probably move to application-level authentication (which can be part of your application, and if based on servlet filters, should be portable to other containers)(which Valves are not). And if you are anyway going in that direction, re-using already-developed and tested stuff like urlrewrite (if possible), is probably less expensive overall, than starting from scratch. Note also that urlrewrite is open-source, under a BSD license. So you can also re-use parts of the code (or just get inspiration from it), if you want to turn your own more specific filter. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Source IP filtering on some URLs before Container-managed authentication
Andre, Chris, On 20.11.2015 9:30, André Warnier (tomcat) wrote: On 19.11.2015 21:26, Christopher Schultz wrote: I think that may be the only way to do it. IIRC, someone did some work to allow Filters to be used in the valve chain, but I don't think there is any facility for specifying s for those. Or, you could switch from container-based AAA, to application-based AAA. You can create a servlet filter which "wraps" your application(s), and in it apply any rules you want. This is totally portable, not Tomcat-specific, and doesn't require any change to server.xml for instance (nor to your application). Thank you both for looking into this. Ok, so it is a choice, either - move RemoteAddrFilter to become a Realm in front of Authenticator Valve, or - move Authenticator valve to become a Filter behind RemoteAddrFilter. To avoid having to redo what others have already done, you may also want to have a look at : http://tuckey.org/urlrewrite/manual/3.0/#filterparams see : element --> remote-addr (for instance) (I'm not saying that urlrewrite fills /all/ your needs, but you could combine urlrewrite with some simple code of your own, to fill all your needs. (snip)). This part I don't get. What is the added value of using urlrewrite compared to RemoteAddrFilter? It is basically the same functionality? -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Source IP filtering on some URLs before Container-managed authentication
On 19.11.2015 21:26, Christopher Schultz wrote: Ognjen, On 11/19/15 10:14 AM, Ognjen Blagojevic wrote: My webapp have a set of resources, let's call that set R. Some of those resources need to be accessed only from certain source IP addresses, let's call that subset R'. And some subset of R' (let's call it R'') needs authentication. I have a reqirement to check source IP address before authentication. Right now, R' is specified in web.xml RemoteAddrFilter s, and R'' is specified in web.xml s. The problem is, filters are executed after container-managed authentication, so login form is presented to the user before RemoteAddrFilter kicks in, and check source IP address. That is not what I need. Users outside trusted IP ranges should not be able to even know about the protected resources, let alone to guess passwords. RemoteAddrValve, on the other hand, is called before container-managed authentication, but it does not allow specifying s. What would be a good solution for the above requirement? Extend RemoteAddrValve with the ability to specify s? I think that may be the only way to do it. IIRC, someone did some work to allow Filters to be used in the valve chain, but I don't think there is any facility for specifying s for those. -chris Or, you could switch from container-based AAA, to application-based AAA. You can create a servlet filter which "wraps" your application(s), and in it apply any rules you want. This is totally portable, not Tomcat-specific, and doesn't require any change to server.xml for instance (nor to your application). Servlet Spec 3.0 has this to say : 13.3 Programmatic Security Programmatic security is used by security aware applications when declarative security alone is not sufficient to express the security model of the application. To avoid having to redo what others have already done, you may also want to have a look at : http://tuckey.org/urlrewrite/manual/3.0/#filterparams see : element --> remote-addr (for instance) (I'm not saying that urlrewrite fills /all/ your needs, but you could combine urlrewrite with some simple code of your own, to fill all your needs. Servlet filters are "stackable"). - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Source IP filtering on some URLs before Container-managed authentication
Ognjen, On 11/19/15 10:14 AM, Ognjen Blagojevic wrote: > My webapp have a set of resources, let's call that set R. Some of those > resources need to be accessed only from certain source IP addresses, > let's call that subset R'. And some subset of R' (let's call it R'') > needs authentication. > > I have a reqirement to check source IP address before authentication. > > Right now, R' is specified in web.xml RemoteAddrFilter s, > and R'' is specified in web.xml s. > > The problem is, filters are executed after container-managed > authentication, so login form is presented to the user before > RemoteAddrFilter kicks in, and check source IP address. That is not what > I need. Users outside trusted IP ranges should not be able to even know > about the protected resources, let alone to guess passwords. > > RemoteAddrValve, on the other hand, is called before container-managed > authentication, but it does not allow specifying s. > > What would be a good solution for the above requirement? Extend > RemoteAddrValve with the ability to specify s? I think that may be the only way to do it. IIRC, someone did some work to allow Filters to be used in the valve chain, but I don't think there is any facility for specifying s for those. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Source IP filtering on some URLs before Container-managed authentication
Hi, My webapp have a set of resources, let's call that set R. Some of those resources need to be accessed only from certain source IP addresses, let's call that subset R'. And some subset of R' (let's call it R'') needs authentication. I have a reqirement to check source IP address before authentication. Right now, R' is specified in web.xml RemoteAddrFilter s, and R'' is specified in web.xml s. The problem is, filters are executed after container-managed authentication, so login form is presented to the user before RemoteAddrFilter kicks in, and check source IP address. That is not what I need. Users outside trusted IP ranges should not be able to even know about the protected resources, let alone to guess passwords. RemoteAddrValve, on the other hand, is called before container-managed authentication, but it does not allow specifying s. What would be a good solution for the above requirement? Extend RemoteAddrValve with the ability to specify s? -Ognjen - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
