SAML V2.0 SessionIndex - the what and why

After working with and reading about SAML V2.0 for some time, I came to think that i finally got it - and that was sort of correct but at a very high level. The devil (and development time) is in the detail, and even though a lot of time and work has been put into the SAML V2.0 specifications, they are not perfect (along with my reading skills). At the moment I almost do not dare to test myself because it's been an unpleasant experience the last couple of times - ex. have a look at SAML V2.0 Confirmation Method Identifiers - ahem, is this crystal clear?. Still i ran into one more of my blind spots. I wanted to better understand the difference between Assertion and Session, just to stumble upon SessionIndex that I had not paid any notice before. So what is this index for sessions about?

The SAML V2.0 Glossary doesn't mention it and the closest thing to a definition is in [SAMLCore] [PDF] section "2.7.2 Element <AuthnStatement>":

SessionIndex [Optional]

Specifies the index of a particular

Further down there's more on SessionIndex (my strong):

In general, any string value MAY be used as a SessionIndex value. However, when privacy is a consideration, care must be taken to ensure that the SessionIndex value does not invalidate other privacy mechanisms. Accordingly, the value SHOULD NOT be usable to correlate activity by a principal across different session participants. Two solutions that achieve this goal are provided below and are RECOMMENDED:

• Use small positive integers (or reoccurring constants in a list) for the SessionIndex. The SAML authority SHOULD choose the range of values such that the cardinality of any one integer will be sufficiently high to prevent a particular principals actions from being correlated across multiple session participants. The SAML authority SHOULD choose values for SessionIndex randomly from within this range (except when required to ensure unique values for subsequent statements given to the same session participant but as part of a distinct session).
• Use the enclosing assertion's ID value in the SessionIndex.

I'm not sure about what's meant with correlate activity, but I guess that is to avoid the SP visits are numbered chronological. I would have like some more description of what it really is and why it's there, my best shot is to enable the possibility for multiple sessions from the same Principal (rarely used) or Agent (rarely implemented) - but I would have preferred the term identifier over index (in computer science, either an integer which identifies an array element, or a data structure which enables fast lookup) though these terms are closely related. Let's see what's what written about it elsewhere in the specs. In "3.3.2.2 Element <AuthnQuery>":

SessionIndex [Optional]

If present, specifies a filter for possible responses. Such a query asks the question What assertions containing authentication statements do you have for this subject within the context of the supplied session information?

Getting back a little to my original goal, the assertions are most often transient (finite lifespan) but saved within the context of a session. It's optional so the dependency must be relatively week:

• If the SessionIndex attribute is present in the query, at least one <AuthnStatement> element in the set of returned assertions MUST contain a SessionIndex attribute that matches the SessionIndex attribute in the query. It is OPTIONAL for the complete set of all such matching assertions to be returned in the response.

In "3.7.1 Element <LogoutRequest>":>/p>

<SessionIndex> [Optional]

The identifier that indexes this session at the message recipient.

Next it's mentioned in "3.7.3.1 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.

and:

• The SessionIndex attribute of one of the assertion's authentication statements matches one of the <SessionIndex> elements specified in the logout request, or the logout request contains no <SessionIndex> elements.

and:

Note: This rule is intended to prevent a situation in which a session participant receives a logout request targeted at a single, or multiple, assertion(s) (as identified by the <SessionIndex> element(s)) before it receives the actual – and possibly still valid - assertion(s) targeted by the logout request. It should honor the logout request until the logout request itself may be discarded (the NotOnOrAfter value on the request has been exceeded) or the assertion targeted by the logout request has been received and has been handled appropriately.

"3.7.3.2 Session Authority Rules"

When constructing a logout request message, the session authority MUST set the value of the NotOnOrAfter attribute of the message to a time value, indicating an expiration time for the message, after which the logout request may be discarded by the recipient. This value SHOULD be set to a time value equal to or greater than the value of any NotOnOrAfter attribute specified in the assertion most recently issued as part of the targeted session (as indicated by the SessionIndex attribute on the logout request).

In [SAMLProfiles] [PDF] it is mentioned in one of the bullet points in "4.1.4.2 <Response> Usage" :

At least one assertion containing an <AuthnStatement> MUST contain a element with at least one <SubjectConfirmation> element containing a Method of urn:oasis:names:tc:SAML:2.0:cm:bearer. If the identity provider supports the Single Logout profile, defined in Section 4.4, any such authentication statements MUST include a SessionIndex attribute to enable per-session logout requests by the service provider.

and again in "4.4.3.1 <LogoutRequest> Issued by Session Participant to Identity Provider":

If the logout profile is initiated by a session participant, it examines the authentication assertion(s) it received pertaining to the session(s) being terminated, and collects the SessionIndex value(s) it received from the identity provider. If multiple identity providers are involved, then the profile MUST be repeated independently for each one.

To initiate the profile, the session participant issues a <LogoutRequest> message to the identity provider's single logout service request endpoint containing one or more applicable <SessionIndex> elements. At least one element MUST be included. Meta data (as in [SAMLMeta]) MAY be used to determine the location of this endpoint and the bindings supported by the identity provider.

and in "4.4.3.2 Identity Provider Determines Session Participants"

If the logout profile is initiated by an identity provider, or upon receiving a valid <LogoutRequest> message, the identity provider processes the request as defined in [SAMLCore]. It MUST examine the identifier and elements and determine the set of sessions to be terminated. The identity provider then follows steps 3 and 4 for each entity participating in the session(s) being terminated, other than the original requesting session participant (if any), as described in Section 3.7.3.2 of [SAMLCore].

and in "4.4.4.1 <LogoutRequest> Usage":

The principal MUST be identified in the request using an identifier that strongly matches the identifier in the authentication assertion the requester issued or received regarding the session being terminated, per the matching rules defined in Section 3.3.4 of [SAMLCore].

If the requester is a session participant, it MUST include at least one <SessionIndex> element in the request. If the requester is a session authority (or acting on its behalf), then it MAY omit any such elements to indicate the termination of all of the principals applicable sessions.

Conclusion

Having gone through all the descriptions it quite simply a means to enable multiple sessions for a user (probably with different applications), which is quite a reasonable requirement.