[keycloak-dev] Two Factor Authentication via Email.

[Stian Thorgersen]

Another thing is that if we're introducing more two factor auth mechanisms
we need to be able to:

* Allow a realm to have one or more alternative two factor mechanisms. For
example a realm could either require a user to use a specific hardware
token or it could require user to simply have two factor enabled.
* Allow users to select which two factor mechanisms to use if a realm
supports more than one.
* Allow a user to have more than one two factor mechanisms registered with
their account and be able to select which one to use on login if they have
more than one.

Does the current authentication SPI support those?

On 12 January 2016 at 08:51, Stian Thorgersen <sthorger at redhat.com> wrote:

>
>
> On 11 January 2016 at 22:29, Bill Burke <bburke at redhat.com> wrote:
>
>>
>> On 1/11/2016 4:15 PM, Thomas Darimont wrote:
>> > I'm currently working on a PR that provides "Two factor authentication
>> > via email" https://issues.jboss.org/browse/KEYCLOAK-240.
>> >
>> > My current implementation comes with a custom EmailCodeAuthenticator
>> > that generates a short code String in the challenge(...) Method and
>> > sends an email to the email address that is configured for the current
>> > user.
>> >
>> > The user can then copy and paste the code into an input field, similar
>> > to OTP codes are handled. If the user entered the wrong code, a new
>> > email is sent to the user's email address.
>> >
>> > The email code is saved as a user level credential.
>> >
>> > I wonder whether this is the right approach or whether it would be
>> better
>> > to allow the user to regenerate the code on demand instead of
>> > regenerating it every time?
>> >
>>
>> Don't know what you mean by that.  Just store the OTP within the
>> ClientSessionModel.  Generate the OTP, store it within the ClientSession
>> model, send the OTP to the user, display the OTP input page.  IMO, you
>> also should not resend the email on failure. Instead, supply a button
>> that they can click to resend the email.
>>
>
> +1 Just leverage what we already have for OTPs to generate codes to send
> in email. In fact we could even use the same OTP secret already stored for
> OTP when sending emails and SMS.
>
>
>>
>> > For the former I'd have to provide a REST endpoint similar to what
>> > happens for verifying an email
>> > during registration - where should this be placed?
>> >
>> > For sending the actual email I'm currently using a
>> > EmailSenderProvider, however I think a EmailTemplateProvider might be
>> > more appropriate ;-)
>> > May I simply add a method to the EmailTemplateProvider interface?
>> >
>>
>> We should have a more generic method on EmailTemplateProvider.
>>
>
> +1 Something like sendEmail(String template,...)
>
>
>>
>> > Btw. I think this would be a good base for having an SMS based 2nd
>> > factor authenticator, as requested here:
>> > https://issues.jboss.org/browse/KEYCLOAK-241
>> >
>> > It would make sense to have the mobile phone number as a first-class
>> > user attribute and showing it on the profile page by default instead
>> > of just having it only in the data model.
>> >
>> > Another point that comes to my mind is that I could make sense to
>> > specify an email code policy in the same way OTP policies are
>> > supported. This could then be used to differentiate between email
>> > codes that are usually handled via copy&paste whereas codes
>> > that come via SMS are usually typed in by hand and should therefore
>> > be somewhat short ;-)
>> >
>>
>> All that makes sense.  Never did an SMS based module as the SDKs used
>> differ per country, are quite diverse, and most of the time(?) cost money.
>>
>
> Yup, there's no standard to send SMS, but we could introduce a
> SMSSenderProvider which it would delegate to. That way it's relatively
> simple to implement an SMS sender.
>
>
>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160112/f160dc5b/attachment-0001.html