Shibboleth Developers

[Peter Williams <>]

Some specific Shib2 SP questions. They concern topics in shib...that are 
somewhat advanced for my limited shib/saml abilities.



Does the Shib SP using the notify process communicate with the shib app 
multiple times, if there are multiple sessions for a principal to be 
invalidated, upon receipt of a LogoutRequest?



Or, should folks code the notify handler in the app to expect but one 
callback - one that identifies multiple app-sessions for invalidation?



Assume a non-Shib IDP is controlling SAML sessions and is conforming in its 
handling of sessionindexes. It may or may not align with how Shib IDP 
actually behaves, but is at least LibertyInteroperable certified.



The IDP operates in a theater in which one principal can have multiple 
application sessions (url-based) - on several SP applications. Furthermore, 
one user desktop has multiple IDP sessions (using IE8, to separate 
client-side cookie jars and enforce full session SSL rekeying), each one 
bound to a different principal/nameid.



The Shib SP application has not yet been coded; requirements are being 
formulated. Hence the queries...



is there any (advanced) model code for a Shib app showcasing notify and its 
relationship to Shib SP's SLO?

-----------

Dont read, unless more context for the queries helps.

Session Participant Rules



When a session participant receives a <LogoutRequest> message, the session 
participant MUST

authenticate the message. If the sender is the authority that provided an 
assertion containing an

authentication statement linked to the principal's current session, the 
session participant MUST invalidate

the principal's session(s) referred to by the <saml:BaseID>, <saml:NameID>, or

<saml:EncryptedID> element, and any <SessionIndex> elements supplied in the 
message. If no

<SessionIndex> elements are supplied, then all sessions associated with the 
principal MUST be

invalidated.



The context is : Ping IDP talking to Shib SP and Ping SPs, in an open 
networking environment -  leveraging the SLO capabilities support provided by 
the vendors' software.

Shib IDP is not yet involved (since it is not SLO capable, todate).

Users typically have 3 or 4 active app-sessions, from a choice of about 12 
SPs and their various apps, after authenticating to the IDP using an RSA 
time-synced tokencode. 99% of the reason for adopting SAML websso...was to 
avoid having to provide RSA tokencodes to 4 or 5 (of a dozen) websites folks 
use each day, to get their job done. Websites freely choose their own SAML2 
vendor. In general, only occasionally, when a more senstiive transaction is 
encountered, does a SAML SP require a re-authentication of the user 
(requiring a time-synced token code to be supplied to the IDP). Otherwise, 
the authentication authority is in charge of user authentication policy: IDP 
& SAML session lifetimes etc.  Privileged administrators can invoke SLO per 
principal (from the idp). Users can invoke SLO from those SPs supporting SLO.

The network plans to now include a Shib-based SP. The Shib SP will be 
operated by a commercial partner, not Rapattoni. The commercial 
relationship/topology is peer/peer, not hub/spoke (the IDP has no policy 
control over the SP, and no federation concept exists).  The Rapattoni IDP is 
the authentication authority, and allows multiple principals on the same user 
desktop to have IDP sessions. That is, you can be principal#1 with a SAML 
session#A on 5 SPs in COT#X, and be principal #2 with a SAML session#B on 3 
SPs in COT#Y. There may even be a delegation relationship between principal 
#1 and #2 (though this is hidden from SAML). SPs may participate in both 
COTs, #X and #Y. COTs may designate anCOT-specific  SP affiliation entity.

SP Partner#2 is Ping vendor
SP Partner#3 is Shib vendor

principal #1 and principal#2 share an IDP session, on Ping IDP. principals #1 
and #2 have different (cleartext) nameids.

For SAML session#A

1. when the SLO is sp-iniitated by Shib SP (partner #3), a logout request 
will be sent to a Ping SP - for principal#1 partner#2, say.

2. when the SLO is sp-initiated by Ping SP (partner #2), a logout request 
will be sent a Shib SP - for principal#1 partner#3, say.

And:

3. principal #2 has a SAML session#B, which means in general that the SHib SP 
app (partner#3) has multiple app sessions AND the Ping SP app (partner#2) 
also has multiple app sessions

Commercial partner has been advised to get a Shib expert consultant...!  
Meantime, I'm it (despite being only minimally competent in Shib2).