Implications of forceAuthn/AuthnInstant

[Walden H. Leverich]

>>
>>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

I wasn't around for that thread last month as we're relatively new to Shibboleth, but I can tell you another place that ForceAuthn is invaluable, and that's electronic signatures. I don't mean "signed requests", but rather the business requirement that an electronic record be "signed" by the author/reviewer/submitter/etc. 

There are several regulations, 21CFR11 to name the one we care about, that require the signer execute their signature using the secret part (password) of their login _every time_ they sign a record. Therefore we need the ForceAuthn support to force the IdP to prompt the user for this information every time. Things like 21CFR11 fly directly in the face of the original benefit to a SSO solution, namely "I'll tell you who I am once, then leave me alone." :-)

-Walden

-- 
Walden H Leverich III
Tech Software & 
BEC - IRBManager
(516) 627-3800 x3051
WaldenL at TechSoftInc.com
http://www.TechSoftInc.com
http://www.IRBManager.com

Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)


-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Eric Goodman
Sent: Wednesday, October 2, 2013 4:25 PM
To: Shib Users
Subject: RE: Implications of forceAuthn/AuthnInstant




>>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
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net