Shibboleth Developers

["Scott Cantor" <>]

> So I propose a rule that says:
> 
> * Once a Session is created, all references to applicationId and its
> associated object must use the Session to get it.

The thing I think you're missing is that one of the "settings" bound to the
application is the name of the session cookie. If you're using Java sessions
for this stuff, then you're operating under a different model, but in my
case, I need to find the applicationId for the request to even ask for the
session cookie name that will lead me to the session data.

Secondly, there's a semi-security check involved. Once a session is created,
it's bound to a given applicationId. Part of the processing in the request
map is to independently establish the applicationId for a request and then
make sure it's the same as the one bound to the session. That makes it a
little harder for a session to be misapplied to requests that are part of a
different application.

It's not a true security measure (for the reasons Jim Fox identified), but
with sufficient trust in the server environment, it creates some isolation
between applications.

> This still leaves the question of recovery. Based on the observation that
> deleting an <Application> would cause all subsequent Sessions to that
> application to map to "default", I do not think it would be a mistake to
> continue processing by re-associating the existing Session to the new
> "default" Application object.

I think this is subjective. It was my opinion (and only that) that anything
like that constituted a good enough reason to just bail on the session and
assume nothing. It was a more conservative view. I probably also didn't want
to bother having to change the applicationId associated with the session.

I don't think it's unreasonable to say this could be a config option though.

-- Scott