AuthenticationResult/FlowId for SPSession

[Cantor, Scott]

On 9/12/14, 2:13 PM, "Marvin Addison" <marvin.addison at gmail.com> wrote:

>I'm working on a CASSPSession that extends BaseSPSession since that
>seems like a natural basis. Unfortunately the authenticationFlowId
>field is proving problematic. In the CAS protocol, login and ticket
>validation are distinct (in time and location) requests. 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? As a comparison, a SAML
artifact is essentially a ticket, but we don't wait to add the
SAMLSPSession after the artifact is resolved by the SP, we just assume it
will be.

> But by that time, I've
>lost the AuthenticationContext carrying the AuthenticationResult I
>need that contains the authn flow ID.

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,
but I'm not sure I could actually come up with a valid reason for having
it at this point. It may just be simpler to pull it because it's taking up
space for no reason at this point.

> I have no idea how to tie back to that and I'm wondering how that works
>in the SAML case when you're coming in on an existing SSO session and
>don't login. Maybe if I
>understood that case better I could work out how to wire things up for
>my case.

The existing session case doesn't really change this, either way the
authentication subflow is responsible for populating the
AuthenticationResult in the context. That's where the flow ID comes from
when the SPSession is added. 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.

-- Scott