Problem with client ip address changing

[Rod Widdowson]

Have you tried suppressing the check in web.xml?  

I'm not sure what the support level is, but I know at least one production IdP in the UK using it.  You obviously need to convince
yourself that you are not opening any security holes by doing this &c &c (security tests are there for a reason and making the
problem go away doesn't mean that you are secure)...

<!-- [SNIP] -->
<filter>
  <filter-name>IdPSessionFilter</filter-name>
  <filter-class>edu.internet2.middleware.shibboleth.idp.session.IdPSessionFilter</filter-class>
  <!-- START OF ADD -->
  <init-param>
    <param-name>ensureConsistentClientAddress</param-name>
    <param-value>false</param-value>
  </init-param>
  <!-- END OF ADD -->
</filter>
<!-- [SNIP] -->

I'm also slightly worried by this comment:

> I can't get the error show in the log
> when change my ip address manually.

If you can reproduce this I'd love to see a JIRA case entered.

Rod

> -----Original Message-----
> From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Viitanen Viljo
> Sent: 14 November 2012 15:05
> To: Shib Users
> Subject: RE: Problem with client ip address changing
> 
> Scott Cantor wrote:
> 
> >You'll need to open a bug and attach the full log on DEBUG including
> >the audit entry. I have an idea what it might be, but I want to see the whole log.
> 
> Unfortunately I'm unable to reproduce the problem on my own - I can't get the error show in the log
> when change my ip address manually. (so, I really DO wonder what's going on here. Obviously the ip
> address check isn't very effective even though it is there!). Also I can't just turn on the debug log
> in production and just wish someone with the problem shows up.
> 
> >> I¹d rather the idp to issue an error to the user, and not let the
> >> user proceed to SP.
> >
> >That may be, but it isn't normally possible. You don't know what
> >attributes the SP may be requiring, no matter what they say or their
> >metadata says, and you have no way to block the issuance of a response based on that.
> 
> I'm not sure what you mean here. We do know which attributes we need in the Finnish Haka federation,
> and also the one-to-one relationships we have outside the federation.
> 
> I think in the modern world requiring client ip address not to change is broken behavior. Some
> statistics: during September this year we got 1241 of these errors in the process log. October 1403.
> This month until yesterday (13th), 1520 . So it's not just some isolated cases here. We're a mid-sized
> university in Finland with ~15000 students, I wonder how bad the problem is with bigger installations.
> 
> If we accept that requiring the ip address not to change is ok (I don't), then the SP's have no idea
> on why the idp did not issue any attributes, and obviously they can't be helpful to the user. The idp
> however does know the user's ip address changed and it could warn the user about why it's not letting
> the user login.
> 
> However I figured out a solution I'll probably try - I'll put the IDP behind a reverse proxy so all
> the IDP ever sees is the proxy ip address. Our future environment will be like that anyway so it'll be
> good practice for that. Currently we're using idp built-in ldap username+password.
> 
> 
> Peter Schober suggested:
> 
> >Promoting updating these SP to Shib 2.5 might be a way forward, to
> >protect against this at the SP side. Cf. "Attribute checking" (first item):
> >https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPInterestin
> >gFe
> >atures
> 
> Thanks for the advice, I'll use that for our own SP's at some point.
> 
> Viljo Viitanen
> 
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net