On 2 Sep 2013, at 09:05, Andy Swiffin <[log in to unmask]> wrote:
> Actually I think you had it right and you've now got it the wrong way round!!
I always get them confused too.
> checkAddress=true: You have to have the same IP address that you originally authenticated with for every SP session you then start
This is intended as an additional protection for the "bearer token" which is the SAML assertion. The idea is that if someone fools the user into presenting the assertion to them instead, they can present it to the SP and gain access.
This doesn't work if the IdP sees a different IP address for the user than the SP does, so for example it fails in the presence of NATs and some kinds of proxy. Once upon a very long time ago I wrote an extension to deal with the NAT case, but in the end the simplest solution seems to have been for people to disable this one.
The backup protection here is of course the TLS connections between the user agent, the IdP and the SP, and of course the integrity of the user's browser (rolls eyes). So the sky doesn't fall if this one is turned off, but you do lose some protection.
Long term, "holder of key", in which the user agent proves to the SP that it is the rightful bearer of the token, may be an answer to this one, but as far as I know it's really not implemented by anyone today.
> consistentAddress=true: Your IP address has to stay the same for the lifetime of a session with an SP but need not be the one you authenticated with (or the one you earlier or later present to another SP)
This is intended as an additional protection for the "bearer token" which is the user's SP session cookie. Again, the idea is that even if the cookie is stolen (and again the backup protection here is the TLS connection) the attacker won't be recognised as the owner of the session.
If this check fails, I'd expect the result to be another trip to the IdP. For a case like the "unplug and go WiFi" one, I don't think that's a problem and I would recommend not disabling the check just to retain sessions across that kind of change. If the result is actually an error page, then I can see how that would be annoying and perhaps we need to think about changing the behaviour.
-- Ian
|