On Fri, Feb 20, 2015 at 11:52:20AM +0100, Jan Pazdziora wrote:
On Wed, Feb 18, 2015 at 12:55:48PM +0100, Sumit Bose wrote:
> These convenience features are not available if 2FA is used with both
> factors combined in a single string because there is no general rule
> which would allow to split the long-term and the one-time part. Only the
> authentication backend knows how to handle it.
Isn't there a way in the protocol for the backend to return as
additional information number of characters that were used as the
first factor, signalling what the first factor in the concatenated
string was?
no, otherwise we wouldn't have to do all this stunt.
> The pre-authentication request
Does this proposal change anything for non-interactive use cases
like mod_authnz_pam, for single-factor or two-factor use cases? We
were thinking of having daemon hold the status of the PAM conversation
between HTTP requests but -- how will the whole setup work if the
client only provides the first factor but not the second one? Will
that count as failed authentication? Could we do the first factor, and
if the conversation did not finish (because it prompted for the second
factore), abort the conversation, store the password (encrypted),
redirect to alternative web page, ask for the second factor, and then
send both factors in new conversation?
Or is the expected workflow to run the pre-authentication, and if it
determines 2FA is to be used, just store the Login + Password as
captured by mod_intercept_form_submit from the logon POST, not submit
the first password at all, and redired to that extra page to ask for
the second factor?
If the backend supports 2FA pam_sss will run the pre-auth request to see
is 2FA is configured for the given user or not. Depending on the result
pam_sss will call the pam_conversation function which you provide with
pam_start with either '1' or '2' as the first argument. So the
application can see easily if 1 or 2 factors are expected. If the
application fill only the first factor, like e.g. ssh with password
authentication, pam_sss will treat the input as a combine token where
long term password and OTP are given in a single string to assure
backward compatibility. With this there is no need to change the
application side. Only if the application wants to support the special
separate prompting for the two factors if should check the first
argument of pam_conversation and act accordingly.
Does this answer your questions?
bye,
Sumit
--
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat