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.
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.
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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com