Cookie destruction

[Cantor, Scott]

> I've discovered that deleting the cookies in the external authentication is not
> enough.

Deleting what cookies?

> To summarize:
> 
> 1) Go to SP and try to login with user Joan
> 2) You're redirected to idp (ExternAuthn)
> 3) Enter credentials and successfully authenticates
> 4) Enter SP
> 5) Logout SP
> 6) Open a new tab
> 7) Go to SP and try to login with user Lucy
> 8) You're redirected to idp (ExternAuthn)
> 9) Enter credentials and succesfully authenticates
> 10) Enter SP but you're inside as Joan no as Lucy

Ordinarily that results in an error because it won't let the user "change" within a session. I suspect that the ExternalAuth handler may have more leeway that puts the onus on that handler to deal with issues like this, I don't know. Otherwise it makes no sense. I suspect it's probably accumulating multiple Java principals within the session.

> I believe this happen because the session from the idp is still active and
> doesn't matter if you delete the cookies, you need to re-authenticate but
> you can enter with a different user.

There is no way to get at an IdP session in that flow without the cookie from that session being in place. So if you mean that cookie, no, that is not true.

> Is this the best way of invalidating the current session of the idp or there are
> other options?

I think you destroy it directly, destroySession(sessionobj), no need to get the ID, but otherwise yes. Or, delete the cookie. If you're saying you did, you're mistaken, or you're referring to a different cookie.

> Can I be sure that by doing this (the previous code) there's no interchange of
> information between users?

Since it's one client (you) logging in as both users, it's really one user. That's the current design because it allows multiple principals to be associated with a session. What you're seeing is the results of the need to pick one principal at random in subsequent steps.

-- Scott