<div dir="ltr">Another thing is that if we're introducing more two factor auth mechanisms we need to be able to:<div><br></div><div>* 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.</div><div>* Allow users to select which two factor mechanisms to use if a realm supports more than one.</div><div>* 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.</div><div><br></div><div>Does the current authentication SPI support those?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 12 January 2016 at 08:51, Stian Thorgersen <span dir="ltr"><<a href="mailto:sthorger@redhat.com" target="_blank">sthorger@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On 11 January 2016 at 22:29, Bill Burke <span dir="ltr"><<a href="mailto:bburke@redhat.com" target="_blank">bburke@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 1/11/2016 4:15 PM, Thomas Darimont wrote:<br>
> I'm currently working on a PR that provides "Two factor authentication<br>
> via email" <a href="https://issues.jboss.org/browse/KEYCLOAK-240" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-240</a>.<br>
><br>
> My current implementation comes with a custom EmailCodeAuthenticator<br>
> that generates a short code String in the challenge(...) Method and<br>
> sends an email to the email address that is configured for the current<br>
> user.<br>
><br>
> The user can then copy and paste the code into an input field, similar<br>
> to OTP codes are handled. If the user entered the wrong code, a new<br>
> email is sent to the user's email address.<br>
><br>
> The email code is saved as a user level credential.<br>
><br>
> I wonder whether this is the right approach or whether it would be better<br>
> to allow the user to regenerate the code on demand instead of<br>
> regenerating it every time?<br>
><br>
<br>
</span>Don't know what you mean by that. Just store the OTP within the<br>
ClientSessionModel. Generate the OTP, store it within the ClientSession<br>
model, send the OTP to the user, display the OTP input page. IMO, you<br>
also should not resend the email on failure. Instead, supply a button<br>
that they can click to resend the email.<br></blockquote><div><br></div></span><div>+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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> For the former I'd have to provide a REST endpoint similar to what<br>
> happens for verifying an email<br>
> during registration - where should this be placed?<br>
><br>
> For sending the actual email I'm currently using a<br>
> EmailSenderProvider, however I think a EmailTemplateProvider might be<br>
> more appropriate ;-)<br>
> May I simply add a method to the EmailTemplateProvider interface?<br>
><br>
<br>
</span>We should have a more generic method on EmailTemplateProvider.<br></blockquote><div><br></div></span><div>+1 Something like sendEmail(String template,...)</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><br>
> Btw. I think this would be a good base for having an SMS based 2nd<br>
> factor authenticator, as requested here:<br>
> <a href="https://issues.jboss.org/browse/KEYCLOAK-241" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/KEYCLOAK-241</a><br>
><br>
> It would make sense to have the mobile phone number as a first-class<br>
> user attribute and showing it on the profile page by default instead<br>
> of just having it only in the data model.<br>
><br>
> Another point that comes to my mind is that I could make sense to<br>
> specify an email code policy in the same way OTP policies are<br>
> supported. This could then be used to differentiate between email<br>
> codes that are usually handled via copy&paste whereas codes<br>
> that come via SMS are usually typed in by hand and should therefore<br>
> be somewhat short ;-)<br>
><br>
<br>
</span>All that makes sense. Never did an SMS based module as the SDKs used<br>
differ per country, are quite diverse, and most of the time(?) cost money.<br></blockquote><div><br></div></span><div>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.</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span><font color="#888888"><br>
<br>
--<br>
Bill Burke<br>
JBoss, a division of Red Hat<br>
<a href="http://bill.burkecentral.com" rel="noreferrer" target="_blank">http://bill.burkecentral.com</a><br>
<br>
_______________________________________________<br>
keycloak-dev mailing list<br>
<a href="mailto:keycloak-dev@lists.jboss.org" target="_blank">keycloak-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/keycloak-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a><br>
</font></span></blockquote></span></div><br></div></div>
</blockquote></div><br></div>