On 08/11/2014 10:04 PM, Alexander Bokovoy wrote:
On Mon, 11 Aug 2014, Michael Lasevich wrote:
On Mon, Aug 11, 2014 at 12:30 PM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

On Mon, 11 Aug 2014, Michael Lasevich wrote:

So, it is NOT intended to use for border-style 2FA authentication (i.e.
VPN) - which seems may be a common use case for 2FA?

You can always supplement authentication check with some host-specific
information at the VPN concentrator. We don't have ready to use solution
here but it is definitely possible to use such scheme against FreeIPA
2FA.


Sorry, I am not following.  What do you mean by "host-specific
information"? If system has no way to detect how many factors were involved
in authentication, how would I be able to guarantee that only 2FA is
allowed via this box?

I suppose this can work: I can write code that will:

1 - detects if there are OTP numbers at the end of the password
2 - authenticates using full 2FA
3 - authenticates using just password without 2FA

And then authenticate only if all 3 conditions are satisfied. Seems a bit
hacky, but that is the only way I can think that may work.
2 and 3 are the same from IPA point of view, just an LDAP bind. Ideally SSSD could handle this as part of a PAM stack by providing PAM
feedback that could be used by other modules. There was no request for
this functionality before.

However, I was mostly thinking that you may have an authentication
sequence where past successful auth you would check tokens associated
with the user to see if there is a recent update within the same time
period on one of tokens. This would work right now, though it is a bit a
hack -- a better one than the 2-accounts-per-user.


Here is more info:
1) Right now there is no way to scope the 2FA to different hosts. It is all or nothing. 2) There are plans to be able to differentiate which services would require 2FA and which would allow just a single factor. We might not have filed specific RFEs in IPA because most of the work needs to happen in Kerberos.
There are two approaches:
a) Allow users authenticate using 2FA or single factor at their discretion but centrally control which services can be accessed with ticket that is acquired with single factor. That would prevent users from accessing the services that require 2FA. b) For smarter services (which do not exist yet and would have be implemented) they would be able to look into the ticket themselves and see the information how ticket was acquired and then make a decision based on that.

The place where the information of how the authentication was performed is called CAMMAC - http://k5wiki.kerberos.org/wiki/Projects/Authentication_indicator

HTH

--
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project

Reply via email to