Shibboleth session vs Application session

[Eric Goodman]

>Unless you mean the IdP, but that's much more complicated, now you're 
>talking about SSO and those implications. That doesn't comport with any 
>kind of control at the SP end. If you need that kind of control, you have 
>to use ForceAuthn, and open that can of worms (cue Eric), or it doesn't 
>matter what you do at the SP end.

I keep missing these cues.

Just to clarify what Scott is saying here: Presuming you've timed out the SP session (which the rest of this thread addresses), you only have 2 choices to ensure the user is prompted to relogin:

1) Configure the IdP not to support SSO at all (i.e., disable the PreviousSession hander). 
2) Use the ForceAuthn option in the SP call to the IdP.

Either of these approaches in theory makes the user re-enter their password. But if you absolutely require being sure the user is being prompted to authenticate, this is insufficient. 

Mostly this means that you have to verify IdP relies on some external authentication method which cannot be cached or renewed without the user's involvement. Examples where an IdP could reauthenticate the user without the user seeing a prompt include: SPNEGO authentication, NTLM-over-HTTP authentication and CAS authentication. (A user using a password safe like LastPass or 1password would do this too, but that's completely beyond your control).

So the mechanism you seem to be asking for that forces the user to re-authenticate is there in SAML, but since the IdP doesn't actually perform the authentication it's up to you to verify that the IdP is "doing the right thing". 

--- Eric