Shibboleth Developers

[Peter Williams <>]

That did not help (me) at all.

My sp (ping indentity v6) has an architecture somewhat similar to shib sp 
(when it cooperates with apps via the notify mechainism). The idp is shib, 
doing its pretty average thing authenticating users and minting assertions 
and query responses.

The sp maintains an array of sessions identifiers, providing to the app a 
sessionid from a private (sp side)  table that (somehow) it maps onto saml2 
sessionid (or other saml2 signals). I don't really know what it does, except 
it manages an sp side table and provides an private index to the app with 
which to later invoke a particular run of spinit slo. The slo run logs the 
principal  out of certain sp app sessions on for the browsers on the desktop 
( but not all' by inspection ).

Meantime I have users who, being members of the web, do ctrl-n duplication of 
browsers, and who can and do  at an time otherwise create new browser 
instances/popups pointing at the idpsite and/or the sp site. Sometimes the 
resultant cookie jars with webapp sessionid style cookies are shared across 
browser instances , sometimes not (depending on browser vendor, memory load 
or other factors). Ssl sessionid ae similalry managed. Being the web, I have 
to in my server garden/farm provide for the attendent concurrency of  this 
core element of the universal browser experience (love it or hate it,it is 
what it is).

Did the shib concept, on either idp or sp, design for this mess?

Is there any way to characterise when my session index in my sp table will 
change based on design/profiling/implementation decision made by the (shib) 
idp?

Eg will the saml2 sessionid will change whenever the local idp cookie session 
changes... Or whatever?

Perhaps my questions are just not sensible, cos im simply not understanding 
something elementary about saml2 that addresses all this. Would not be the 
first time.

-----Original Message-----
From: Scott Cantor 
<>
Sent: Saturday, May 09, 2009 11:51 AM
To: 

 
<>
Subject: RE: [Shib-Dev] sessionid, previous session, assertions - web 
gardens, web farms, concurrent sessionstate locking....


Peter Williams wrote on 2009-05-09:
> 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?

How about the code?

Session session =
getUserSession(requestContext.getInboundMessageTransport());
if (session != null) {
    statement.setSessionIndex(session.getSessionID());
}

Seems clear to me (allowing that one understands the implementation of the
session manager used, which in this case is cookie-based.

-- Scott