AuthenticationResult/FlowId for SPSession

[Marvin Addison]

>> The SP session must be added to the IdP session during ticket validation
>>_after_ the ticket is successfully validated.
>
> Is that an absolute, or just a particular choice?

It's an implementation choice based on my experience. We issue tickets
all the time that fail to validate for one reason or another,
typically due to ticket expiration (tickets are valid on the order of
a few seconds). It we created the SP session when the ticket is
created, it could result in creation of substantial number of SP
sessions that never actually existed. That balloons the IdP session
for no reason and is misleading besides. Now we could of course tweak
the default ticket validity period to reduce likelihood of the
expiration case, but that feels like the wrong approach. The best time
to create an SP session is after the ticket has been successfully
validated.

> Honestly, the flow ID there was sort of a tacked on thing, I put it there
> when I created the SPSession interface thinking it might be useful later

At first glance I thought it was there to support multi-factor use
cases, but on further consideration it seems like it's only useful for
auditing or reporting.

> The existing session case means the result
> that's added to the context is a pre-existing one that came out of the
> IdPSession instead of a newly created one during the flow, but the
> SPSession step doesn't know/care how it got there.

That's the approach I took for the moment:

session.getAuthenticationResults().iterator().next().getAuthenticationFlowId()

That solution makes me uncomfortable because I'm just pulling the
first one of an unordered collection. In the face of multiple
authentications on a single session this approach could produce
misleading results.

M