Semantics of ForceAuthn with two-factor authentication

[Eric Goodman]

I'm really interested in the answers to this question. 

My thought is similar to yours; while I can see that conceptually there may be sense to only reauthing one factor in some cases, it makes the most scalable sense (at least lacking another indicator) to reauth all factors. 


I'll even throw in a followup:

In this same scenario, if one assumes that the first and second factors were authenticated at separate times, what's the appropriate "AuthnInstant" to put in the assertion -- the original or the more recent AuthN event's occurrence? 

In answer to my own question, I think it similarly makes more sense to from a scalability standpoint to return the oldest AuthnInstant. 


I think it's easier to argue against either stance if one assumes that the second factor is inherently the "more secure" factor, but I don't think we can really presume which factor is the one about which the SP is "more concerned".


--- Eric 

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Christopher Bongaarts
Sent: Monday, July 21, 2014 8:31 AM
To: Shib Users
Subject: Semantics of ForceAuthn with two-factor authentication

SAML 2.0 defines ForceAuthn thusly:

> If "true", the identity provider MUST authenticate the presenter 
> directly rather than rely on a previous security context.

Our Duo implementation currently uses a previous security context
(cookie) to determine how to proceed.  The logic looks like this
(simplified):

If the SP wants two-factor, then
   if the user is already authed with two-factor
     let them in (SSO)
   else if the user is already authed with their password (first factor)
     prompt them for the second factor
   else
     prompt them for the first factor
else
   prompt them for the first factor

Now, the question that has come up is:  if an  SP wants two-factor, and also requests ForceAuthn (the particular use case is enforcing an inactivity timeout at the app), should we force re-authentication of
*both* factors, or is there a case that only the second factor could be reauthenticated (assuming that the first factor auth is still valid from the IdP point of view)?

My most literal reading of the spec is that both must be reauthed (since accepting the previous first-factor auth would be relying on a previous security context).  Scalability to additional factors would also tend to favor this reading (if I ask for seven-factor auth, how do i decided if it's acceptable to re-use factors 1-4 but not 5 and 6?).

Any reasons besides "user convenience" to support a looser reading?

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%

--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net