IdP version 2 no previous session login handler and principal change

[Cantor, Scott]

> For a particular deployment the previous session login handler
> is disabled.

IIRC that doesn't disable sessions, just the reuse of results for SSO.
 
> - another immediate SAML2 SSO flow authenticating with
>   'principal1' results in an assertion with attributes
>   resolved for 'principal2',which is not what I expected

That's what I would expect for all the reasons that have been enumerated over the years. V2 merges principals, that's just how it worked. It does not recognize identity switches, it assumes the same browser is the same person and that any difference in username is deliberate and a result of using different login methods with the same user. I'm not defending it, but that was the choice at the time.

It's the reason I came up with the c14n design in V3, to put a stop to that.
 
> It appears that the IdP switches principals from principal1 to
> principal2 as I would expect, but does not later switch back
> to principal1.

It's not switching, it's merging.

> I can easily get the behavior I expect by reducing the IdP
> session length to, say, 5 seconds, but I am wondering if the
> "stickyness" of principal2 is expected behavior?

Expected. The original Subject from the old session gets combined with the newer one, and what happens after that is pretty random I think. Not purely random, but very hard to predict. I think it probably ends up favoring the new data the first time and then once they're all merged, it probably sorts them into set order or something.

-- Scott