SessionIndex from original AuthnResponse is needed for logout but not exposed

[quantatheist]

Hi, first of all, thank you for this high-level package!

I tried to migrate my existing low-level SAML code and noticed what looks like a small mismatch in the cookbook.
The logout request documentation shows that sendLogoutRequest() accepts a sessionIndex parameter, which should be taken from the “original AuthnResponse” (see https://litesaml.github.io/cookbook/docs/single-logout/logout-request/#send-a-logout-request).

However, when handling an authentication response with ServiceProviderWrapper::handleAuthnResponse(), the returned high-level AuthnResponse does not seem to expose the SessionIndex from the AuthnStatement (see https://litesaml.github.io/cookbook/docs/authentication/authn-response#reading-attributes).
So, when using the high-level API, I currently need to grab the SessionIndex the “old” low-level way by reading the assertion manually.

I suggest exposing the SessionIndex on the high-level AuthnResponse, for example as $authnResponse->sessionIndex.The value should already be available after LightSAML has parsed or decrypted the assertion, because AuthnStatement::deserialize() reads the SessionIndex attribute via attributesFromXml(), which ultimately calls setSessionIndex() through AbstractSamlModel::singleAttributeFromXml().

I hope this makes sense. I am still getting familiar with the high-level API, so I might be missing something. If there is already a recommended way to obtain the SessionIndex, I would be happy to learn about it. I can provide more details or test a possible change if that would be helpful.

Have a nice week!

[william-suppo]

Hi @quantatheist, a fix has been proposed in #3.

[william-suppo]

For context, on why SessionIndex lives on the AuthnStatement (inside the assertion) rather than on the Response itself, and whether there can be more than one:

Why the AuthnStatement carries it: SessionIndex identifies the session that this specific authentication event created between the principal and the IdP. It's not an identifier of the SAML response, but of an IdP-side session — that's exactly why it's echoed back in a LogoutRequest later: it tells the IdP "terminate the session you created during this particular authentication." Since an AuthnStatement represents an authentication event, it's the natural place to carry it.

Can there be more than one? Yes, at two levels per the SAML schema:

1. Multiple AuthnStatements within a single assertion — rare, but possible with step-up auth (e.g. the user re-authenticates with MFA during the same session, creating a second authentication event with its own SessionIndex).
2. Multiple Assertions within a single Response — also schema-legal (e.g. IdP proxying/chaining, or combined authentication contexts), though most SP integrations only ever see one.

In this library's implementation (ServiceProviderWrapper::handleAuthnResponse()), we take the first non-null SessionIndex found, the same pattern already used for nameId. That's a reasonable simplification for the common case (single IdP, single authentication event per SSO flow), but it does mean additional assertions/statements are silently ignored if present. Worth keeping in mind if an IdP-proxy or step-up-auth use case comes up later.