Problem with client ip address changing

Rod Widdowson rdw at
Wed Nov 14 10:28:35 EST 2012

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] -->
  <!-- START OF ADD -->
  <!-- END OF ADD -->
<!-- [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.


> -----Original Message-----
> From: users-bounces at [mailto:users-bounces at] 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):
> >
> >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

More information about the users mailing list