Quantcast

IP Based Restrictions

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

IP Based Restrictions

Richard Wheeldon

Hi,

 

Having broken the back of the token based MFA, my next quest in bolting down my app is to add configurable IP-based restrictions. I’m thinking of a realm which reads a list of IPs or ranges (v4 or v6) from a DB then checks if the host matches.

 

Two questions:

  1. Is there any interest in my producing a generic / re-usable JdbcHostRestrictionRealm and kicking it back upstream? I can probably do this by cribbing from JdbcRealm.
  2. My app is sat behind a load balancer which changes the IP address. Since we control the load balancer we can trust the X-Forwarded-For header in a downstream app. Is there a preferable place to hook in the logic to read it from the request and set it on the token?

 

Richard

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IP Based Restrictions

Brian Demers
Take a look at this block of code in the AuthenticatingFilter:

Are you trying to restrict an IP/range for a individual users. Or a range for the whole application?   A realm would work for the user case. For the application case, you could probably just create a filter.

Either way, great stuff!




On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <[hidden email]> wrote:

Hi,

 

Having broken the back of the token based MFA, my next quest in bolting down my app is to add configurable IP-based restrictions. I’m thinking of a realm which reads a list of IPs or ranges (v4 or v6) from a DB then checks if the host matches.

 

Two questions:

  1. Is there any interest in my producing a generic / re-usable JdbcHostRestrictionRealm and kicking it back upstream? I can probably do this by cribbing from JdbcRealm.
  2. My app is sat behind a load balancer which changes the IP address. Since we control the load balancer we can trust the X-Forwarded-For header in a downstream app. Is there a preferable place to hook in the logic to read it from the request and set it on the token?

 

Richard


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: IP Based Restrictions

Richard Wheeldon

It’s the whole app for now.

 

So I could grab the IpAddressMatcher from Spring sec and repackage it (rather than introducing a dep between shiro and spring which would be a bit crazy)

https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/util/matcher/IpAddressMatcher.java

 

Then create:

 

package org.apache.shiro.web.filter.authz;

 

public interface IpSource {

    public List<String> getIpRanges();

}

 

package org.apache.shiro.web.filter.authz;

 

public class IpFilter extends AuthorizationFilter {

    public void setIps(List<String> ips) { ... }

    public void setIpSource(IpSource source) { ... }

    public getHost(ServletRequest request) {

        return request.getRemoteHost();

    }

    @Override

    protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) throws Exception {

        ...

        String host = getHost();

        for (IpAddressMatcher matcher : matchers) {

                    if (matcher.matches(host)) {

                return true;

            }

        }

        return false;

    }

}

 

package com.voxsmart.stuff;

 

public class XffIpFilter extends IpFilter {

    @Override

    public getHost()

        parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER))

    }

}

 

package com.voxsmart.stuff;

 

public class DatabaseIpSource {

 

    @Override

    public getIpRanges() {

        ... select range from ...

    }

}

 

And put in shiro.ini:

[main]

ipSource = com.voxsmart.stuff.DatabaseIpSource

ipFilter = com.voxsmart.stuff.XffIpFilter

ipFilter.ipSource = ipSource

 

[urls]

/* = ipSource,...

 

Does this seem reasonable?

 

From: Brian Demers [mailto:[hidden email]]
Sent: Tuesday, January 10, 2017 5:14 PM
To: [hidden email]
Subject: Re: IP Based Restrictions

 

Take a look at this block of code in the AuthenticatingFilter:

 

Are you trying to restrict an IP/range for a individual users. Or a range for the whole application?   A realm would work for the user case. For the application case, you could probably just create a filter.

 

Either way, great stuff!

 

 

 

 

On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <[hidden email]> wrote:

Hi,

 

Having broken the back of the token based MFA, my next quest in bolting down my app is to add configurable IP-based restrictions. I’m thinking of a realm which reads a list of IPs or ranges (v4 or v6) from a DB then checks if the host matches.

 

Two questions:

  1. Is there any interest in my producing a generic / re-usable JdbcHostRestrictionRealm and kicking it back upstream? I can probably do this by cribbing from JdbcRealm.
  2. My app is sat behind a load balancer which changes the IP address. Since we control the load balancer we can trust the X-Forwarded-For header in a downstream app. Is there a preferable place to hook in the logic to read it from the request and set it on the token?

 

Richard

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IP Based Restrictions

Brian Demers
I like it, we could even create a default IpSource so the INI file could work out of the box, something like:

[main]
ipFilter.ipSource = x.x.x.x, x.x.x.x/24


On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon <[hidden email]> wrote:

It’s the whole app for now.

 

So I could grab the IpAddressMatcher from Spring sec and repackage it (rather than introducing a dep between shiro and spring which would be a bit crazy)

https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/util/matcher/IpAddressMatcher.java

 

Then create:

 

package org.apache.shiro.web.filter.authz;

 

public interface IpSource {

    public List<String> getIpRanges();

}

 

package org.apache.shiro.web.filter.authz;

 

public class IpFilter extends AuthorizationFilter {

    public void setIps(List<String> ips) { ... }

    public void setIpSource(IpSource source) { ... }

    public getHost(ServletRequest request) {

        return request.getRemoteHost();

    }

    @Override

    protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) throws Exception {

        ...

        String host = getHost();

        for (IpAddressMatcher matcher : matchers) {

                    if (matcher.matches(host)) {

                return true;

            }

        }

        return false;

    }

}

 

package com.voxsmart.stuff;

 

public class XffIpFilter extends IpFilter {

    @Override

    public getHost()

        parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER))

    }

}

 

package com.voxsmart.stuff;

 

public class DatabaseIpSource {

 

    @Override

    public getIpRanges() {

        ... select range from ...

    }

}

 

And put in shiro.ini:

[main]

ipSource = com.voxsmart.stuff.DatabaseIpSource

ipFilter = com.voxsmart.stuff.XffIpFilter

ipFilter.ipSource = ipSource

 

[urls]

/* = ipSource,...

 

Does this seem reasonable?

 

From: Brian Demers [mailto:[hidden email]]
Sent: Tuesday, January 10, 2017 5:14 PM
To: [hidden email]
Subject: Re: IP Based Restrictions

 

Take a look at this block of code in the AuthenticatingFilter:

 

Are you trying to restrict an IP/range for a individual users. Or a range for the whole application?   A realm would work for the user case. For the application case, you could probably just create a filter.

 

Either way, great stuff!

 

 

 

 

On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <[hidden email]> wrote:

Hi,

 

Having broken the back of the token based MFA, my next quest in bolting down my app is to add configurable IP-based restrictions. I’m thinking of a realm which reads a list of IPs or ranges (v4 or v6) from a DB then checks if the host matches.

 

Two questions:

  1. Is there any interest in my producing a generic / re-usable JdbcHostRestrictionRealm and kicking it back upstream? I can probably do this by cribbing from JdbcRealm.
  2. My app is sat behind a load balancer which changes the IP address. Since we control the load balancer we can trust the X-Forwarded-For header in a downstream app. Is there a preferable place to hook in the logic to read it from the request and set it on the token?

 

Richard

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: IP Based Restrictions

Richard Wheeldon

Done. See http://rswheeldon.com/shiro-ip-filter.tgz

 

If someone would like to take a look / fix the default ini / help me get it into trunk itd be appreciated,

 

Regards,

 

Richard

 

From: Brian Demers [mailto:[hidden email]]
Sent: Thursday, January 12, 2017 4:16 PM
To: [hidden email]
Subject: Re: IP Based Restrictions

 

I like it, we could even create a default IpSource so the INI file could work out of the box, something like:

 

[main]

ipFilter.ipSource = x.x.x.x, x.x.x.x/24

 

 

On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon <[hidden email]> wrote:

It’s the whole app for now.

 

So I could grab the IpAddressMatcher from Spring sec and repackage it (rather than introducing a dep between shiro and spring which would be a bit crazy)

https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/util/matcher/IpAddressMatcher.java

 

Then create:

 

package org.apache.shiro.web.filter.authz;

 

public interface IpSource {

    public List<String> getIpRanges();

}

 

package org.apache.shiro.web.filter.authz;

 

public class IpFilter extends AuthorizationFilter {

    public void setIps(List<String> ips) { ... }

    public void setIpSource(IpSource source) { ... }

    public getHost(ServletRequest request) {

        return request.getRemoteHost();

    }

    @Override

    protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) throws Exception {

        ...

        String host = getHost();

        for (IpAddressMatcher matcher : matchers) {

                    if (matcher.matches(host)) {

                return true;

            }

        }

        return false;

    }

}

 

package com.voxsmart.stuff;

 

public class XffIpFilter extends IpFilter {

    @Override

    public getHost()

        parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER))

    }

}

 

package com.voxsmart.stuff;

 

public class DatabaseIpSource {

 

    @Override

    public getIpRanges() {

        ... select range from ...

    }

}

 

And put in shiro.ini:

[main]

ipSource = com.voxsmart.stuff.DatabaseIpSource

ipFilter = com.voxsmart.stuff.XffIpFilter

ipFilter.ipSource = ipSource

 

[urls]

/* = ipSource,...

 

Does this seem reasonable?

 

From: Brian Demers [mailto:[hidden email]]
Sent: Tuesday, January 10, 2017 5:14 PM
To: [hidden email]
Subject: Re: IP Based Restrictions

 

Take a look at this block of code in the AuthenticatingFilter:

 

Are you trying to restrict an IP/range for a individual users. Or a range for the whole application?   A realm would work for the user case. For the application case, you could probably just create a filter.

 

Either way, great stuff!

 

 

 

 

On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <[hidden email]> wrote:

Hi,

 

Having broken the back of the token based MFA, my next quest in bolting down my app is to add configurable IP-based restrictions. I’m thinking of a realm which reads a list of IPs or ranges (v4 or v6) from a DB then checks if the host matches.

 

Two questions:

  1. Is there any interest in my producing a generic / re-usable JdbcHostRestrictionRealm and kicking it back upstream? I can probably do this by cribbing from JdbcRealm.
  2. My app is sat behind a load balancer which changes the IP address. Since we control the load balancer we can trust the X-Forwarded-For header in a downstream app. Is there a preferable place to hook in the logic to read it from the request and set it on the token?

 

Richard

 

 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IP Based Restrictions

Brian Demers
Can you put this in a pull request for github.com/apache/shiro ?

On Tue, Jan 31, 2017 at 1:35 PM, Richard Wheeldon <[hidden email]> wrote:

Done. See http://rswheeldon.com/shiro-ip-filter.tgz

 

If someone would like to take a look / fix the default ini / help me get it into trunk itd be appreciated,

 

Regards,

 

Richard

 

From: Brian Demers [mailto:[hidden email]]
Sent: Thursday, January 12, 2017 4:16 PM


To: [hidden email]
Subject: Re: IP Based Restrictions

 

I like it, we could even create a default IpSource so the INI file could work out of the box, something like:

 

[main]

ipFilter.ipSource = x.x.x.x, x.x.x.x/24

 

 

On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon <[hidden email]> wrote:

It’s the whole app for now.

 

So I could grab the IpAddressMatcher from Spring sec and repackage it (rather than introducing a dep between shiro and spring which would be a bit crazy)

https://github.com/spring-projects/spring-security/blob/master/web/src/main/java/org/springframework/security/web/util/matcher/IpAddressMatcher.java

 

Then create:

 

package org.apache.shiro.web.filter.authz;

 

public interface IpSource {

    public List<String> getIpRanges();

}

 

package org.apache.shiro.web.filter.authz;

 

public class IpFilter extends AuthorizationFilter {

    public void setIps(List<String> ips) { ... }

    public void setIpSource(IpSource source) { ... }

    public getHost(ServletRequest request) {

        return request.getRemoteHost();

    }

    @Override

    protected boolean isAccessAllowed(ServletRequest request, ServletResponse response, Object mappedValue) throws Exception {

        ...

        String host = getHost();

        for (IpAddressMatcher matcher : matchers) {

                    if (matcher.matches(host)) {

                return true;

            }

        }

        return false;

    }

}

 

package com.voxsmart.stuff;

 

public class XffIpFilter extends IpFilter {

    @Override

    public getHost()

        parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER))

    }

}

 

package com.voxsmart.stuff;

 

public class DatabaseIpSource {

 

    @Override

    public getIpRanges() {

        ... select range from ...

    }

}

 

And put in shiro.ini:

[main]

ipSource = com.voxsmart.stuff.DatabaseIpSource

ipFilter = com.voxsmart.stuff.XffIpFilter

ipFilter.ipSource = ipSource

 

[urls]

/* = ipSource,...

 

Does this seem reasonable?

 

From: Brian Demers [mailto:[hidden email]]
Sent: Tuesday, January 10, 2017 5:14 PM
To: [hidden email]
Subject: Re: IP Based Restrictions

 

Take a look at this block of code in the AuthenticatingFilter:

 

Are you trying to restrict an IP/range for a individual users. Or a range for the whole application?   A realm would work for the user case. For the application case, you could probably just create a filter.

 

Either way, great stuff!

 

 

 

 

On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <[hidden email]> wrote:

Hi,

 

Having broken the back of the token based MFA, my next quest in bolting down my app is to add configurable IP-based restrictions. I’m thinking of a realm which reads a list of IPs or ranges (v4 or v6) from a DB then checks if the host matches.

 

Two questions:

  1. Is there any interest in my producing a generic / re-usable JdbcHostRestrictionRealm and kicking it back upstream? I can probably do this by cribbing from JdbcRealm.
  2. My app is sat behind a load balancer which changes the IP address. Since we control the load balancer we can trust the X-Forwarded-For header in a downstream app. Is there a preferable place to hook in the logic to read it from the request and set it on the token?

 

Richard

 

 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: IP Based Restrictions

Richard Wheeldon
Sure. How? Is there a cheat sheet around?

-----Original Message-----
From: Brian Demers [mailto:[hidden email]]
Sent: Tuesday, January 31, 2017 8:49 PM
To: [hidden email]
Cc: [hidden email]
Subject: Re: IP Based Restrictions

Can you put this in a pull request for github.com/apache/shiro ?

On Tue, Jan 31, 2017 at 1:35 PM, Richard Wheeldon < [hidden email]> wrote:

> Done. See http://rswheeldon.com/shiro-ip-filter.tgz
>
>
>
> If someone would like to take a look / fix the default ini / help me
> get it into trunk it’d be appreciated,
>
>
>
> Regards,
>
>
>
> Richard
>
>
>
> *From:* Brian Demers [mailto:[hidden email]]
> *Sent:* Thursday, January 12, 2017 4:16 PM
>
> *To:* [hidden email]
> *Subject:* Re: IP Based Restrictions
>
>
>
> I like it, we could even create a default IpSource so the INI file
> could work out of the box, something like:
>
>
>
> [main]
>
> ipFilter.ipSource = x.x.x.x, x.x.x.x/24
>
>
>
>
>
> On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon <
> [hidden email]> wrote:
>
> It’s the whole app for now.
>
>
>
> So I could grab the IpAddressMatcher from Spring sec and repackage it
> (rather than introducing a dep between shiro and spring which would be
> a bit crazy)
>
> https://github.com/spring-projects/spring-security/blob/
> master/web/src/main/java/org/springframework/security/web/
> util/matcher/IpAddressMatcher.java
>
>
>
> Then create:
>
>
>
> package org.apache.shiro.web.filter.authz;
>
>
>
> public interface IpSource {
>
>     public List<String> getIpRanges();
>
> }
>
>
>
> package org.apache.shiro.web.filter.authz;
>
>
>
> public class IpFilter extends AuthorizationFilter {
>
>     public void setIps(List<String> ips) { ... }
>
>     public void setIpSource(IpSource source) { ... }
>
>     public getHost(ServletRequest request) {
>
>         return request.getRemoteHost();
>
>     }
>
>     @Override
>
>     protected boolean isAccessAllowed(ServletRequest request,
> ServletResponse response, Object mappedValue) throws Exception {
>
>         ...
>
>         String host = getHost();
>
>         for (IpAddressMatcher matcher : matchers) {
>
>                     if (matcher.matches(host)) {
>
>                 return true;
>
>             }
>
>         }
>
>         return false;
>
>     }
>
> }
>
>
>
> package com.voxsmart.stuff;
>
>
>
> public class XffIpFilter extends IpFilter {
>
>     @Override
>
>     public getHost()
>
>         parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER))
>
>     }
>
> }
>
>
>
> package com.voxsmart.stuff;
>
>
>
> public class DatabaseIpSource {
>
>
>
>     @Override
>
>     public getIpRanges() {
>
>         ... select range from ...
>
>     }
>
> }
>
>
>
> And put in shiro.ini:
>
> [main]
>
> ipSource = com.voxsmart.stuff.DatabaseIpSource
>
> ipFilter = com.voxsmart.stuff.XffIpFilter
>
> ipFilter.ipSource = ipSource
>
>
>
> [urls]
>
> /* = ipSource,...
>
>
>
> Does this seem reasonable?
>
>
>
> *From:* Brian Demers [mailto:[hidden email]]
> *Sent:* Tuesday, January 10, 2017 5:14 PM
> *To:* [hidden email]
> *Subject:* Re: IP Based Restrictions
>
>
>
> Take a look at this block of code in the AuthenticatingFilter:
>
> https://github.com/apache/shiro/blob/ef5450b9f4be74ee93040111539482
> 3b9e1fc3e6/web/src/main/java/org/apache/shiro/web/filter/
> authc/AuthenticatingFilter.java#L62-L72
>
>
>
> Are you trying to restrict an IP/range for a individual users. Or a range
> for the whole application?   A realm would work for the user case. For the
> application case, you could probably just create a filter.
>
>
>
> Either way, great stuff!
>
>
>
>
>
>
>
>
>
> On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <
> [hidden email]> wrote:
>
> Hi,
>
>
>
> Having broken the back of the token based MFA, my next quest in
> bolting down my app is to add configurable IP-based restrictions. I’m
> thinking of a realm which reads a list of IPs or ranges (v4 or v6)
> from a DB then checks if the host matches.
>
>
>
> Two questions:
>
>    1. Is there any interest in my producing a generic / re-usable
>    JdbcHostRestrictionRealm and kicking it back upstream? I can probably do
>    this by cribbing from JdbcRealm.
>    2. My app is sat behind a load balancer which changes the IP address.
>    Since we control the load balancer we can trust the X-Forwarded-For header
>    in a downstream app. Is there a preferable place to hook in the logic to
>    read it from the request and set it on the token?
>
>
>
> Richard
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IP Based Restrictions

Alexander Openkowski
This one looks good to me:
https://gist.github.com/Chaser324/ce0505fbed06b947d962

On 02/01/2017 11:18 AM, Richard Wheeldon wrote:

> Sure. How? Is there a cheat sheet around?
>
> -----Original Message-----
> From: Brian Demers [mailto:[hidden email]]
> Sent: Tuesday, January 31, 2017 8:49 PM
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: IP Based Restrictions
>
> Can you put this in a pull request for github.com/apache/shiro ?
>
> On Tue, Jan 31, 2017 at 1:35 PM, Richard Wheeldon < [hidden email]> wrote:
>
>> Done. See http://rswheeldon.com/shiro-ip-filter.tgz
>>
>>
>>
>> If someone would like to take a look / fix the default ini / help me
>> get it into trunk it’d be appreciated,
>>
>>
>>
>> Regards,
>>
>>
>>
>> Richard
>>
>>
>>
>> *From:* Brian Demers [mailto:[hidden email]]
>> *Sent:* Thursday, January 12, 2017 4:16 PM
>>
>> *To:* [hidden email]
>> *Subject:* Re: IP Based Restrictions
>>
>>
>>
>> I like it, we could even create a default IpSource so the INI file
>> could work out of the box, something like:
>>
>>
>>
>> [main]
>>
>> ipFilter.ipSource = x.x.x.x, x.x.x.x/24
>>
>>
>>
>>
>>
>> On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon <
>> [hidden email]> wrote:
>>
>> It’s the whole app for now.
>>
>>
>>
>> So I could grab the IpAddressMatcher from Spring sec and repackage it
>> (rather than introducing a dep between shiro and spring which would be
>> a bit crazy)
>>
>> https://github.com/spring-projects/spring-security/blob/
>> master/web/src/main/java/org/springframework/security/web/
>> util/matcher/IpAddressMatcher.java
>>
>>
>>
>> Then create:
>>
>>
>>
>> package org.apache.shiro.web.filter.authz;
>>
>>
>>
>> public interface IpSource {
>>
>>     public List<String> getIpRanges();
>>
>> }
>>
>>
>>
>> package org.apache.shiro.web.filter.authz;
>>
>>
>>
>> public class IpFilter extends AuthorizationFilter {
>>
>>     public void setIps(List<String> ips) { ... }
>>
>>     public void setIpSource(IpSource source) { ... }
>>
>>     public getHost(ServletRequest request) {
>>
>>         return request.getRemoteHost();
>>
>>     }
>>
>>     @Override
>>
>>     protected boolean isAccessAllowed(ServletRequest request,
>> ServletResponse response, Object mappedValue) throws Exception {
>>
>>         ...
>>
>>         String host = getHost();
>>
>>         for (IpAddressMatcher matcher : matchers) {
>>
>>                     if (matcher.matches(host)) {
>>
>>                 return true;
>>
>>             }
>>
>>         }
>>
>>         return false;
>>
>>     }
>>
>> }
>>
>>
>>
>> package com.voxsmart.stuff;
>>
>>
>>
>> public class XffIpFilter extends IpFilter {
>>
>>     @Override
>>
>>     public getHost()
>>
>>         parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER))
>>
>>     }
>>
>> }
>>
>>
>>
>> package com.voxsmart.stuff;
>>
>>
>>
>> public class DatabaseIpSource {
>>
>>
>>
>>     @Override
>>
>>     public getIpRanges() {
>>
>>         ... select range from ...
>>
>>     }
>>
>> }
>>
>>
>>
>> And put in shiro.ini:
>>
>> [main]
>>
>> ipSource = com.voxsmart.stuff.DatabaseIpSource
>>
>> ipFilter = com.voxsmart.stuff.XffIpFilter
>>
>> ipFilter.ipSource = ipSource
>>
>>
>>
>> [urls]
>>
>> /* = ipSource,...
>>
>>
>>
>> Does this seem reasonable?
>>
>>
>>
>> *From:* Brian Demers [mailto:[hidden email]]
>> *Sent:* Tuesday, January 10, 2017 5:14 PM
>> *To:* [hidden email]
>> *Subject:* Re: IP Based Restrictions
>>
>>
>>
>> Take a look at this block of code in the AuthenticatingFilter:
>>
>> https://github.com/apache/shiro/blob/ef5450b9f4be74ee93040111539482
>> 3b9e1fc3e6/web/src/main/java/org/apache/shiro/web/filter/
>> authc/AuthenticatingFilter.java#L62-L72
>>
>>
>>
>> Are you trying to restrict an IP/range for a individual users. Or a range
>> for the whole application?   A realm would work for the user case. For the
>> application case, you could probably just create a filter.
>>
>>
>>
>> Either way, great stuff!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <
>> [hidden email]> wrote:
>>
>> Hi,
>>
>>
>>
>> Having broken the back of the token based MFA, my next quest in
>> bolting down my app is to add configurable IP-based restrictions. I’m
>> thinking of a realm which reads a list of IPs or ranges (v4 or v6)
>> from a DB then checks if the host matches.
>>
>>
>>
>> Two questions:
>>
>>    1. Is there any interest in my producing a generic / re-usable
>>    JdbcHostRestrictionRealm and kicking it back upstream? I can probably do
>>    this by cribbing from JdbcRealm.
>>    2. My app is sat behind a load balancer which changes the IP address.
>>    Since we control the load balancer we can trust the X-Forwarded-For header
>>    in a downstream app. Is there a preferable place to hook in the logic to
>>    read it from the request and set it on the token?
>>
>>
>>
>> Richard
>>
>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: IP Based Restrictions

Richard Wheeldon
Cool. Thanks. Done. https://github.com/apache/shiro/pull/57

Richard

-----Original Message-----
From: Alexander Openkowski [mailto:[hidden email]]
Sent: Wednesday, February 1, 2017 10:52 AM
To: [hidden email]
Subject: Re: IP Based Restrictions

This one looks good to me:
https://gist.github.com/Chaser324/ce0505fbed06b947d962

On 02/01/2017 11:18 AM, Richard Wheeldon wrote:

> Sure. How? Is there a cheat sheet around?
>
> -----Original Message-----
> From: Brian Demers [mailto:[hidden email]]
> Sent: Tuesday, January 31, 2017 8:49 PM
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: IP Based Restrictions
>
> Can you put this in a pull request for github.com/apache/shiro ?
>
> On Tue, Jan 31, 2017 at 1:35 PM, Richard Wheeldon < [hidden email]> wrote:
>
>> Done. See http://rswheeldon.com/shiro-ip-filter.tgz
>>
>>
>>
>> If someone would like to take a look / fix the default ini / help me
>> get it into trunk it’d be appreciated,
>>
>>
>>
>> Regards,
>>
>>
>>
>> Richard
>>
>>
>>
>> *From:* Brian Demers [mailto:[hidden email]]
>> *Sent:* Thursday, January 12, 2017 4:16 PM
>>
>> *To:* [hidden email]
>> *Subject:* Re: IP Based Restrictions
>>
>>
>>
>> I like it, we could even create a default IpSource so the INI file
>> could work out of the box, something like:
>>
>>
>>
>> [main]
>>
>> ipFilter.ipSource = x.x.x.x, x.x.x.x/24
>>
>>
>>
>>
>>
>> On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon <
>> [hidden email]> wrote:
>>
>> It’s the whole app for now.
>>
>>
>>
>> So I could grab the IpAddressMatcher from Spring sec and repackage it
>> (rather than introducing a dep between shiro and spring which would
>> be a bit crazy)
>>
>> https://github.com/spring-projects/spring-security/blob/
>> master/web/src/main/java/org/springframework/security/web/
>> util/matcher/IpAddressMatcher.java
>>
>>
>>
>> Then create:
>>
>>
>>
>> package org.apache.shiro.web.filter.authz;
>>
>>
>>
>> public interface IpSource {
>>
>>     public List<String> getIpRanges();
>>
>> }
>>
>>
>>
>> package org.apache.shiro.web.filter.authz;
>>
>>
>>
>> public class IpFilter extends AuthorizationFilter {
>>
>>     public void setIps(List<String> ips) { ... }
>>
>>     public void setIpSource(IpSource source) { ... }
>>
>>     public getHost(ServletRequest request) {
>>
>>         return request.getRemoteHost();
>>
>>     }
>>
>>     @Override
>>
>>     protected boolean isAccessAllowed(ServletRequest request,
>> ServletResponse response, Object mappedValue) throws Exception {
>>
>>         ...
>>
>>         String host = getHost();
>>
>>         for (IpAddressMatcher matcher : matchers) {
>>
>>                     if (matcher.matches(host)) {
>>
>>                 return true;
>>
>>             }
>>
>>         }
>>
>>         return false;
>>
>>     }
>>
>> }
>>
>>
>>
>> package com.voxsmart.stuff;
>>
>>
>>
>> public class XffIpFilter extends IpFilter {
>>
>>     @Override
>>
>>     public getHost()
>>
>>         parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER))
>>
>>     }
>>
>> }
>>
>>
>>
>> package com.voxsmart.stuff;
>>
>>
>>
>> public class DatabaseIpSource {
>>
>>
>>
>>     @Override
>>
>>     public getIpRanges() {
>>
>>         ... select range from ...
>>
>>     }
>>
>> }
>>
>>
>>
>> And put in shiro.ini:
>>
>> [main]
>>
>> ipSource = com.voxsmart.stuff.DatabaseIpSource
>>
>> ipFilter = com.voxsmart.stuff.XffIpFilter
>>
>> ipFilter.ipSource = ipSource
>>
>>
>>
>> [urls]
>>
>> /* = ipSource,...
>>
>>
>>
>> Does this seem reasonable?
>>
>>
>>
>> *From:* Brian Demers [mailto:[hidden email]]
>> *Sent:* Tuesday, January 10, 2017 5:14 PM
>> *To:* [hidden email]
>> *Subject:* Re: IP Based Restrictions
>>
>>
>>
>> Take a look at this block of code in the AuthenticatingFilter:
>>
>> https://github.com/apache/shiro/blob/ef5450b9f4be74ee93040111539482
>> 3b9e1fc3e6/web/src/main/java/org/apache/shiro/web/filter/
>> authc/AuthenticatingFilter.java#L62-L72
>>
>>
>>
>> Are you trying to restrict an IP/range for a individual users. Or a range
>> for the whole application?   A realm would work for the user case. For the
>> application case, you could probably just create a filter.
>>
>>
>>
>> Either way, great stuff!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <
>> [hidden email]> wrote:
>>
>> Hi,
>>
>>
>>
>> Having broken the back of the token based MFA, my next quest in
>> bolting down my app is to add configurable IP-based restrictions. I’m
>> thinking of a realm which reads a list of IPs or ranges (v4 or v6)
>> from a DB then checks if the host matches.
>>
>>
>>
>> Two questions:
>>
>>    1. Is there any interest in my producing a generic / re-usable
>>    JdbcHostRestrictionRealm and kicking it back upstream? I can probably do
>>    this by cribbing from JdbcRealm.
>>    2. My app is sat behind a load balancer which changes the IP address.
>>    Since we control the load balancer we can trust the X-Forwarded-For header
>>    in a downstream app. Is there a preferable place to hook in the logic to
>>    read it from the request and set it on the token?
>>
>>
>>
>> Richard
>>
>>
>>
>>
>>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: IP Based Restrictions

Brian Demers
Thanks Alexander!
We also have a CONTRIBUTING.md in the root of the repo.

Richard, thanks! we can move the rest of the discussion over there.


On Wed, Feb 1, 2017 at 6:45 AM, Richard Wheeldon <[hidden email]> wrote:
Cool. Thanks. Done. https://github.com/apache/shiro/pull/57

Richard

-----Original Message-----
From: Alexander Openkowski [mailto:[hidden email]]
Sent: Wednesday, February 1, 2017 10:52 AM
To: [hidden email]
Subject: Re: IP Based Restrictions

This one looks good to me:
https://gist.github.com/Chaser324/ce0505fbed06b947d962

On 02/01/2017 11:18 AM, Richard Wheeldon wrote:
> Sure. How? Is there a cheat sheet around?
>
> -----Original Message-----
> From: Brian Demers [mailto:[hidden email]]
> Sent: Tuesday, January 31, 2017 8:49 PM
> To: [hidden email]
> Cc: [hidden email]
> Subject: Re: IP Based Restrictions
>
> Can you put this in a pull request for github.com/apache/shiro ?
>
> On Tue, Jan 31, 2017 at 1:35 PM, Richard Wheeldon < [hidden email]> wrote:
>
>> Done. See http://rswheeldon.com/shiro-ip-filter.tgz
>>
>>
>>
>> If someone would like to take a look / fix the default ini / help me
>> get it into trunk it’d be appreciated,
>>
>>
>>
>> Regards,
>>
>>
>>
>> Richard
>>
>>
>>
>> *From:* Brian Demers [mailto:[hidden email]]
>> *Sent:* Thursday, January 12, 2017 4:16 PM
>>
>> *To:* [hidden email]
>> *Subject:* Re: IP Based Restrictions
>>
>>
>>
>> I like it, we could even create a default IpSource so the INI file
>> could work out of the box, something like:
>>
>>
>>
>> [main]
>>
>> ipFilter.ipSource = x.x.x.x, x.x.x.x/24
>>
>>
>>
>>
>>
>> On Thu, Jan 12, 2017 at 5:25 AM, Richard Wheeldon <
>> [hidden email]> wrote:
>>
>> It’s the whole app for now.
>>
>>
>>
>> So I could grab the IpAddressMatcher from Spring sec and repackage it
>> (rather than introducing a dep between shiro and spring which would
>> be a bit crazy)
>>
>> https://github.com/spring-projects/spring-security/blob/
>> master/web/src/main/java/org/springframework/security/web/
>> util/matcher/IpAddressMatcher.java
>>
>>
>>
>> Then create:
>>
>>
>>
>> package org.apache.shiro.web.filter.authz;
>>
>>
>>
>> public interface IpSource {
>>
>>     public List<String> getIpRanges();
>>
>> }
>>
>>
>>
>> package org.apache.shiro.web.filter.authz;
>>
>>
>>
>> public class IpFilter extends AuthorizationFilter {
>>
>>     public void setIps(List<String> ips) { ... }
>>
>>     public void setIpSource(IpSource source) { ... }
>>
>>     public getHost(ServletRequest request) {
>>
>>         return request.getRemoteHost();
>>
>>     }
>>
>>     @Override
>>
>>     protected boolean isAccessAllowed(ServletRequest request,
>> ServletResponse response, Object mappedValue) throws Exception {
>>
>>         ...
>>
>>         String host = getHost();
>>
>>         for (IpAddressMatcher matcher : matchers) {
>>
>>                     if (matcher.matches(host)) {
>>
>>                 return true;
>>
>>             }
>>
>>         }
>>
>>         return false;
>>
>>     }
>>
>> }
>>
>>
>>
>> package com.voxsmart.stuff;
>>
>>
>>
>> public class XffIpFilter extends IpFilter {
>>
>>     @Override
>>
>>     public getHost()
>>
>>         parseIpAddressFromXffHeader(request.getHeader(XFF_HEADER))
>>
>>     }
>>
>> }
>>
>>
>>
>> package com.voxsmart.stuff;
>>
>>
>>
>> public class DatabaseIpSource {
>>
>>
>>
>>     @Override
>>
>>     public getIpRanges() {
>>
>>         ... select range from ...
>>
>>     }
>>
>> }
>>
>>
>>
>> And put in shiro.ini:
>>
>> [main]
>>
>> ipSource = com.voxsmart.stuff.DatabaseIpSource
>>
>> ipFilter = com.voxsmart.stuff.XffIpFilter
>>
>> ipFilter.ipSource = ipSource
>>
>>
>>
>> [urls]
>>
>> /* = ipSource,...
>>
>>
>>
>> Does this seem reasonable?
>>
>>
>>
>> *From:* Brian Demers [mailto:[hidden email]]
>> *Sent:* Tuesday, January 10, 2017 5:14 PM
>> *To:* [hidden email]
>> *Subject:* Re: IP Based Restrictions
>>
>>
>>
>> Take a look at this block of code in the AuthenticatingFilter:
>>
>> https://github.com/apache/shiro/blob/ef5450b9f4be74ee93040111539482
>> 3b9e1fc3e6/web/src/main/java/org/apache/shiro/web/filter/
>> authc/AuthenticatingFilter.java#L62-L72
>>
>>
>>
>> Are you trying to restrict an IP/range for a individual users. Or a range
>> for the whole application?   A realm would work for the user case. For the
>> application case, you could probably just create a filter.
>>
>>
>>
>> Either way, great stuff!
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Jan 10, 2017 at 11:39 AM, Richard Wheeldon <
>> [hidden email]> wrote:
>>
>> Hi,
>>
>>
>>
>> Having broken the back of the token based MFA, my next quest in
>> bolting down my app is to add configurable IP-based restrictions. I’m
>> thinking of a realm which reads a list of IPs or ranges (v4 or v6)
>> from a DB then checks if the host matches.
>>
>>
>>
>> Two questions:
>>
>>    1. Is there any interest in my producing a generic / re-usable
>>    JdbcHostRestrictionRealm and kicking it back upstream? I can probably do
>>    this by cribbing from JdbcRealm.
>>    2. My app is sat behind a load balancer which changes the IP address.
>>    Since we control the load balancer we can trust the X-Forwarded-For header
>>    in a downstream app. Is there a preferable place to hook in the logic to
>>    read it from the request and set it on the token?
>>
>>
>>
>> Richard
>>
>>
>>
>>
>>


Loading...