Shibboleth Developers

["Scott Cantor" <>]

Peter Williams wrote on 2009-06-12:
> when the IDP processes a ForceAuthn=true request, given the user has an
> existing IDP session and SAML session, does the subsequent issuance of a
> SAML Assertion always start a new SAML session? Or does configuration
> control whether the same SAML sessionid is cited, along with an
> PreviousSession authcontext?

If you're talking about the SP's sessions, there is no case in which a new
assertion doesn't produce a new session and there's no ability to connect
one session to another even if it's the same person, same attributes, or
same IdP. I don't know how to design for that so I didn't try. It's a
limitation for applications that want to "uplevel" something within a
session, but it can usually be worked around by using application sessions.

> If I recall, the Shib2 SP is stateless (though has support for SLO).

The SP isn't remotely stateless, it's about as stateful as a SSO system
gets. It's criticized often for that fact.
 
> does the SP support sp-initated SLO? (at least in principle)?

It supports it fine, from all appearances.

> how long WOULD the SP retain SLO-related state?
> 
> In principle, is SLO state to be retained by an SP for the lifetime of the
> SAML session?

There is no "SLO state", there's just session state.
 
> if the SAML SP in question is dealing with SAML session of 24h (say), and
is
> receiving 60 transactions a second, that's alot of SLO state to retain.
> The lifetime of the SAML session and the whether a SAML session might be
> "reused" in that 24h by a given user are obviously factors in computing
SLO
> state management sizing.

Which is why people tend to use local timeouts to eject them. It's also
possible to let shibd grow enormously and just chew up RAM and it won't
affect the web servers, since the sessions that don't get used will never
come out of cache. Or you can plug a database in for storage and they'll
just sit on disk. Or memcache, etc.

Client side state scales better, and would be interesting to explore at some
point.

-- Scott