<div dir="ltr">I'd say option 1 then. Folks can customize the login screen if they want something else.</div><div class="gmail_extra"><br><div class="gmail_quote">On 15 August 2016 at 15:35, Bruno Oliveira <span dir="ltr"><<a href="mailto:bruno@abstractj.org" target="_blank">bruno@abstractj.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2016-08-15, Stian Thorgersen wrote:<br>
> I've always hated having password+otp in a single field when login to<br>
> internal SSO. We can do it that way for the FreeIPA integration, but the<br>
> users wouldn't know what to do if a realm allows both regular KC users and<br>
> users from as FreeIPA instance. Nor does it work well for installations<br>
> where otp is not mandatory.<br>
<br>
</span>There are some alternatives for it:<br>
<br>
1. Document and leave it as is for the SSSD federation provider. People<br>
coming from FreeIPA world are familiar with this.<br>
<br>
2. Add a label inside the password field like FreeIPA console does[1]<br>
for usability purposes. From my understanding, it would require<br>
extending UsernamePassword form and provide a new login interface.<br>
<br>
3. Provide new OTP screen for SSSD provider with a single field, "OTP"<br>
and QRCode info omitted. Because, all the steps to configure two-factor<br>
happen on the FreeIPA side.<br>
<br>
My suggestion is to stick with 1 for now and iterate over it for improvements.<br>
<br>
<br>
[1] - <a href="http://imgur.com/eyk5Ewx" rel="noreferrer" target="_blank">http://imgur.com/eyk5Ewx</a><br>
<div><div class="h5"><br>
><br>
> On 25 July 2016 at 23:33, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>> wrote:<br>
><br>
> > Hi Bill,<br>
> ><br>
> > After giving these ideas a try, I started to think about the FreeIPA<br>
> > flow and how 2FA validation works. If we provide for the first factor<br>
> > username + password or username + (password and OTP - in the same field),<br>
> > credentials will be validated anyways. I was misguided by the second prompt<br>
> > from sudo, thinking that second factor was mandatory (sorry about that).<br>
> ><br>
> > The same happens for the FreeIPA web interface, we just provide username +<br>
> > password and OTP (if it was configured).<br>
> ><br>
> > That said, I believe we don't have to add any extra code, aside of what<br>
> > we already have for the SSSD Federation provider. I've already<br>
> > tested it with and without OTP. The only downside of this approach is<br>
> > the fact that we're not going to have an OTP screen and it has to be<br>
> > documented in some place.<br>
> ><br>
> > Does anyone have objections about leaving the flow as is?<br>
> ><br>
> > On 2016-07-20, Bill Burke wrote:<br>
> > > Just create a different form and new Authenticator. I don't think we<br>
> > want<br>
> > > all this logic with Freemarker, do we? The UI is decoupled from<br>
> > credential<br>
> > > validation on purpose so that you can move things around, i.e. a Username<br>
> > > screen, then the next screen is password/OTP input.<br>
> > ><br>
> > > Another thing you could do is collect credentials and store them in the<br>
> > > ClientSessionModel, then once you've collected the credentials, validate<br>
> > > them all in one go.<br>
> > ><br>
> > > On 7/20/16 10:06 AM, Bruno Oliveira wrote:<br>
> > > > On 2016-07-19, Stian Thorgersen wrote:<br>
> > > > > Adding Bill..<br>
> > > > ><br>
> > > > > It would probably still be better to use user federation for<br>
> > verifying<br>
> > > > > credentials, but we would need some logic on how to determine what<br>
> > > > > mechanism to use for primary authentication and secondary<br>
> > authentication.<br>
> > > > > Bill was talking about adding some conditional flows to the<br>
> > authentication<br>
> > > > > maybe that's what we need.<br>
> > > > ><br>
> > > > > For now I'd focus on OTP though and then move on to smartcard<br>
> > afterwards.<br>
> > > > I can give it a try and workaround, but I'm not sure if worth the<br>
> > > > effort, assuming that later will be necessary to revisit.<br>
> > > ><br>
> > > > If we hardcode/workaround it on Keycloak, user's coming from FreeIPA<br>
> > > > may have their login denied. Even if we ignore smartcards for now. Why?<br>
> > > ><br>
> > > > Depending on the auth types SSSD will show different login prompts. For<br>
> > > > example:<br>
> > > ><br>
> > > > * Password<br>
> > > > Login prompt - $ Password:<br>
> > > ><br>
> > > > * OTP<br>
> > > > Login prompt -> $ First factor:<br>
> > > > $ Second factor:<br>
> > > > Note: Please notice that they are not validated separately<br>
> > > ><br>
> > > > * Password + OTP -> $ First factor or password:<br>
> > > ><br>
> > > > That's the reason why I would like to make the our login screen<br>
> > > > dynamic.<br>
> > > ><br>
> > > > > On 19 July 2016 at 11:00, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>><br>
> > wrote:<br>
> > > > ><br>
> > > > > > The problem here is the fact that not necessarily the<br>
> > > > > > first factor will be a pasword or the second factor an OTP. It<br>
> > > > > > could be a smartcard for example. That's why I think is a better<br>
> > idea to<br>
> > > > > > make it dynamic, because we don't have control over it to tell<br>
> > > > > > if the second factor will be a smartcard or an OTP for example.<br>
> > > > > ><br>
> > > > > > Does it make sense?<br>
> > > > > ><br>
> > > > > > On 2016-07-19, Stian Thorgersen wrote:<br>
> > > > > > > Looks like it's better to keep as is and have user federation<br>
> > provider<br>
> > > > > > > validate otp credentials as well. The current OTP authenticator<br>
> > delegates<br>
> > > > > > > to user federation provider, so you'd end up with a separate OTP<br>
> > > > > > > authenticator to do it with PAM.<br>
> > > > > > ><br>
> > > > > > > On 19 July 2016 at 00:48, Bruno Oliveira <<a href="mailto:bruno@abstractj.org">bruno@abstractj.org</a>><br>
> > wrote:<br>
> > > > > > ><br>
> > > > > > > > Good morning,<br>
> > > > > > > ><br>
> > > > > > > ><br>
> > > > > > > > Today to authentication against PAM with just simple<br>
> > username/password<br>
> > > > > > I<br>
> > > > > > > > implemented UserFederationProvider and added the proper PAM<br>
> > login to<br>
> > > > > > > > validCredentials[1]. This covers the most basic scenario.<br>
> > > > > > > ><br>
> > > > > > > > Now I would like to cover a more complex scenario like OTP and<br>
> > change<br>
> > > > > > > > the flow a little bit like this:<br>
> > > > > > > ><br>
> > > > > > > > 1. User providers her username<br>
> > > > > > > > 2. The next screen asks to provide how many factor our user<br>
> > has(For<br>
> > > > > > > > example: OTP, password). We just don't know, PAM will tell<br>
> > what's next.<br>
> > > > > > > > 3. We authenticate against it<br>
> > > > > > > ><br>
> > > > > > > > To see in practice against FreeIPA server, I just recorded it<br>
> > > > > > > > for a practical example[2].<br>
> > > > > > > ><br>
> > > > > > > > What would be the best approach to implement this flow? I was<br>
> > > > > > considering<br>
> > > > > > > > to<br>
> > > > > > > > move my authentication logic out of SSSD federation provider<br>
> > and<br>
> > > > > > create a<br>
> > > > > > > > PAM<br>
> > > > > > > > authenticator.<br>
> > > > > > > ><br>
> > > > > > > > Does it make sense?<br>
> > > > > > > ><br>
> > > > > > > > [1] -<br>
> > > > > > > ><br>
> > > > > > <a href="http://www.keycloak.org/docs/javadocs/org/keycloak/models/" rel="noreferrer" target="_blank">http://www.keycloak.org/docs/<wbr>javadocs/org/keycloak/models/</a><br>
> > UserFederationProvider.html#<wbr>validCredentials-org.keycloak.<br>
> > models.RealmModel-org.<wbr>keycloak.models.<wbr>UserCredentialModel-<br>
> > > > > > > > [2] - <a href="https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a" rel="noreferrer" target="_blank">https://asciinema.org/a/<wbr>atwnfbu0kqfasjl65weyoiz7a</a><br>
> > > > > > > ><br>
> > > > > > > ><br>
> > > > > > > > --<br>
> > > > > > > ><br>
> > > > > > > > abstractj<br>
> > > > > > > > PGP: 0x84DC9914<br>
> > > > > > > > ______________________________<wbr>_________________<br>
> > > > > > > > keycloak-dev mailing list<br>
> > > > > > > > <a href="mailto:keycloak-dev@lists.jboss.org">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/<wbr>mailman/listinfo/keycloak-dev</a><br>
> > > > > > > ><br>
> > > > > > --<br>
> > > > > ><br>
> > > > > > abstractj<br>
> > > > > > PGP: 0x84DC9914<br>
> > > > > ><br>
> > > > --<br>
> > > ><br>
> > > > abstractj<br>
> > > > PGP: 0x84DC9914<br>
> > ><br>
> ><br>
> > --<br>
> ><br>
> > abstractj<br>
> > PGP: 0x84DC9914<br>
> ><br>
<br>
</div></div>--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
</blockquote></div><br></div>