Shibboleth Developers

[Kristof Bajnok <>]

On Monday 16 August 2010 18.30.44 Scott Cantor wrote:
> > Address checking is not enabled by default, and I can understand why
> > (especially after I spent a couple of weeks with a bad 3G/GPRS/etc
> > connection this summer). All the same, our guides recommend it.
> 
> You're mixing up two settings. I'm talking about consistentAddress, not
> checkAddress. They're very different, and consistentAddress should
> generally not be disabled and rarely needs to be.

Oops, I was talking about consistentAddress too, just mixing the names. And 
yes, it's on default.

> > If I operated large LANs (as most universities do), I'd be concerned
> > about the session stealing problem above.
> 
> Does any system that issues cookie-backed sessions do what you're talking
> about? Java? ASP? PHP? 

IMHO proper SSO integration bounds the Java/PHP/whatever session to the 
Shibboleth session, so that if the shib session is removed/lost, the app-
level session is removed too. Thus an app session cookie without the linked 
shib session is useless. (The linking can be based on the user's id, not the 
shib session id.)

> If not, I really can't see starting with mine...

Because applications are based on its session. Normally an application do 
not have subsidiaries - the SP does.

> It's not more than ugly, it's virtually impossible. The spoof checking
> works mainly because it operates in reverse: I can be conservative about
> checking and assume that the clearing mechanism works as intended
> anyway. So it tries to skip the check in a wide range of scenarios,
> since any check in a subrequest would be a false positive.
> 
> What you're suggesting would clear the cookie and fail with *any*
> subrequests at all, and that would break a large percentage of the time.
> Often in very unusual and hard to predict cases.
> 
> What *might* work, and only on some versions of Apache, is to internally
> set up some state to inherit the session information across the
> subrequest boundary, but it's a fairly substantial and error prone
> change. 

OK, thanks for the explanation. It's clear that I've no clue about the way 
Apache subrequests work. I thought that the above could be achieved very 
similarly to the spoofing checking. I didn't know that you need the cookie 
to preserve state between subrequests.

Kristof