Shibboleth Developers

[Peter Williams <>]

is there a mental model one should have to understand the intent of the SHIB 
IDP, in respect of when SAML2 sessionid values in the assertion change, if 
sessionid changes are affected (or not ) by use of previousSession 
AuthContext, if sessionid is tied to local cookies on the IDP, if sessionid 
is a function of browser instances (cnrl-N, etc) or SSL Sessionids, or if 
sessionid vary each assertion (or each assertion group) in a response?

etc.

-------------

here is some (rather terse) background to why I'm asking:-

We are running into issues when users cntrl-N or otherwise to duplicate their 
browser, or have multiple browser instances open on the IDP (and SP) at 
different points in the sites' state machines ...and are trying to understand 
what happens when all that concurrency comes down to something on the wire - 
that the SP will handle. Assume the SP is NOT based on the Shib SP code base. 
Assume that SLO is the forcing function, and is forcing us to up the 
engineering to come into "better compliance" with the underlying SAML2 model. 
Assume we have a tested/complying SAML2 IDP with both foreground and 
SOAP-based SLO.

Like it or hate it, our production SP with a few hundred thousand operational 
users allows a user to have multiple webapp sessions (some handling http/ssl 
connections in a shared SSL session, some in othr mutually-independent SSL 
sessions) on one webapp (with various app pools and various worker processes 
per app pool forming a web garden); The webapp is internally divided by 
tenant, for which a particular user has some n of m membership rights - which 
drives a common access control mechanism enforced by the SP. (Though its 
probably not relevant, this webapp operates in a classical web farm, where 
all IIS servers can share webapp session info, using ASP.NET's own exclusive 
locking regime controlling concurrent access to ASP.NET's sessionstate by any 
member of the pool of IIS servers).

Furthermore, one user on one windows desktop using IE may have multiple 
login/principals on those sessions, including being multiple  principals on 
one tenant of the webapp. Given this is the web, some of the browser 
instances may be cntrl-N generated (i.e. SSL conenctions are derived from a 
common SSL sessionid, and all tabs share a common cookie jar), be created 
using IE8 -noupdatae feature (whose SSL Conenctions for its tabs are derived 
from a common but independent SSL sessionid VS other brower process trees on 
the same desktop, and have disjoint cookie jars). And, then into that mix, we 
now throw in SAML2 sessionid, trying to ensure SLO works on the SP. The goal 
of course is to ensure that  the SP session manager is cooperating with the 
SAML SP protocol entity, and is properly tracking distinct SAML sessions to 
ensure that the _right_ SLO set of indexed SAML2 sessions at the other SP in 
the COT (which are also typically multi-tenant, multi-login) are destroyed. 
Since there are concurrent principals, on current tenants of the webapp, and 
concurrent browser view on some or all of these sessions, we have to ensure 
the right set of sessions are destroyed, and not necessarily all.