On Fri, Aug 30, 2013 at 08:37:31PM +0100, Sara Hopkins wrote:
> https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessions
>
> I don't think that checkAddress=true is too restrictive, but one
> does have to work around these things somehow. I reckon it's better
> to get the proxy or NAT thing configured properly so that it Does
> the Right Thing[tm] with IP addresses, but in practice this might be
> Very Hard or Impossible and so you do have to consider setting
> checkAddress to false.
>
> But I really don't think consistentAddress should be set to false.
> If something changes its IP address during the course of a session
> then I reckon it's just Broken and it needs to be fixed, and setting
> consistentAddress to false is a pretty serious compromise to
> security. Makes one dependent on cookies.
Having just re-read the documentation, I must admit to having
misuderstood the original question... Andy was asking about
"checkAddress" which appears to just enforce the IP address consistency
on inital SAML Assertion processing time (rather than for the life of
the SP session) – I don't really have a problem with that being enabled.
However, on the same page it mentions "consistentAddress" which enforces
the same IP for the entire life of the session which also defaults to
TRUE and appears to be what we're discussing … stop reading now if we're
talking at cross-purposes :-)
----
If you're on, for example, a 3G iPad connected via Wifi to a service
working away happilly and the roam away from Wifi onto 3G then your IP
address will change. Is that broken?
Even less contrived, you're on your laptop plugged into the LAN on
campus and unplug to move to a cafe to continue working and drop onto
eduroam – at Kent, at least, the device's IP will change. Broken?
People, and therefore devices, move around all the time. IP networks (to
a large extent) don't and users expect things to "just work".
Relying on cookies isn't such a bad thing if they're implemented
correctly (HTTPS protected; non-stupid session generation blah blah)
It's a risk-benefit thing. The thing you're protecting might be
sensitive enough that you want to ensure a higher level of security so
this extra layer might be justifiedr; it's probably worth educating
users about this when you use it though.
--
Matthew Slowe
Server Infrastructure Team e: [log in to unmask]
IS, University of Kent t: +44 (0)1227 824265
Canterbury, UK w: www.kent.ac.uk
|