Modify forceAuthn Authentication Engine Behavior

[Cantor, Scott]

On 12/16/11 6:59 PM, "John Mitchell" <jpmitchell at alaska.edu> wrote:
>
>    A new login handler/AuthnContext was one of my initial thoughts but
>it would seem if I wrote a login handler that the login handler would
>still have to destroy the existing session. Is that right? Would that
>action of destroying the session be crossing any API boundaries? Seems
>like it would to me.

If you replace the login functionality with a handler that doesn't rely on
the IdP session for anything, that session can be short lived without
losing SSO for other SPs that don't need the special handling.

Otherwise, yes, I think it's possible to destroy the session from within a
handler.

>    Also it struck me last night that if it was possible to have a
>AuthnContext solution that would skip the previous session login handler
>that I might get something like I want.

If the SP asks for a specific context, the IdP will insist that the
requested method is active for the session, and that method can have a
very short lifetime. PreviousSession is only used if the SP's requirements
can be satisfied by an active method.

> Is that true, or would I end up
>with the same behavior as forceAuthn where the IdP expects the same
>principal?

The principal has to be the same, otherwise a lot of things become
ambiguous and non-deterministic.

> Seems like I could also end up with alot of orphan sessions
>lying around in the IdP as well.

All sessions are in some sense orphaned, the IdP doesn't generally get any
indication that one will be used again or not.

-- Scott