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 _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
