Problem with client ip address changing

[Viitanen Viljo]

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/NativeSPInterestingFe
>atures

Thanks for the advice, I'll use that for our own SP's at some point.
 
Viljo Viitanen