Shibboleth Developers

["Scott Cantor" <>]

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

Ok. I guess its moot if it's really so trivial to spoof them. I had the
impression modern networks were more resistant to that, but I don't really
know much of anything about it.

> 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.

That's certainly true when you stack them, but people also frequently
gateway them, so it really depends.

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

I guess I'm not sure what difference you're referring to...?

I would see my sessions as roughly the same kind of thing as an application
framework session used for security. That's extremely common in ASP, the
Java servlet session is what you use for container-managed security, etc.

With the SP, the system is designed to support every application having its
own session, or not, depending on how you deploy it. I don't see a
difference from how Java or ASP.NET bound theirs.

(I'm not saying your point isn't valid, I'm just suggesting it's a pretty
basic problem with web sessions.)

> 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.

Each subrequest is processed essentially from scratch from a module point of
view, and the SP performs most of its work all over again. You can preserve
authentication state, but the details are pretty hairy and are definitely
undocumented (which admittedly most of Apache is now).

-- Scott