Implications of forceAuthn/AuthnInstant

[Eric Goodman]

>>If the IdP doesn't issue a forced reset (a la CAS "renew=true" from 
>>Michael's response) on EVERY external authentication, then what is the 
>>appropriate value to put in AuthnInstant for any authentication event 
>>that doesn't assert this?

>The appropriate value is the time the session was first established, 
>unless you assert PreviousSession as the AuthnContext.

Understood, I think. I meant that it seems like the actual value you want isn't necessarily the time the Shib session was established, but the time the CAS (or whatever) session was established, which I was again guessing may be un-knowable in many deployments.



>I would note though that using ForceAuthn has generally 
>been associated with using signed requests (and by extension 
>not allowing unsigned requests).

Yes, that makes sense. The "Signing authN requests: yea or nay?" thread from last month was still in my head, though I hadn't captured the direct link (even though Nate called it out explicitly).


>And you're right that my example is similar in that it means 
>the IdP will essentially "lie" without knowing it's lying. 
>However the difference is that you shouldn't be using a 
>PasswordProtectedTransport AuthnContext class in such a case. 

Point taken. 

>>(In fact, if you read the draft update of the AD Silver compliance document 
>>that just went out to the assurance list this AM, you'll see that we're 
>>explicitly recommending you not support SPNEGO/GSSAPI for reasons that 
>>could be argued on somewhat similar grounds).

>I'll look at it, that seems like a surprising outcome.

The comparison of "similar grounds" is kind of a stretch, but the underlying logic is that there are IAP requirements that are different when interacting with the IdP vs. the IdP's verifier, the former requirements tend to be the more burdensome, and not supporting SPNEGO/GSSAPI reduces the number of technologies that fall into the former category. So they are similar arguments in terms of both being motivated somewhat by there being fewer use cases to analyze if you don't support them.



Thanks yet again!

--- Eric