<div dir="ltr">I've always hated having password+otp in a single field when login to internal SSO. We can do it that way for the FreeIPA integration, but the users wouldn't know what to do if a realm allows both regular KC users and users from as FreeIPA instance. Nor does it work well for installations where otp is not mandatory.</div><div class="gmail_extra"><br><div class="gmail_quote">On 25 July 2016 at 23:33, 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">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>
<span class=""><br>
On 2016-07-20, Bill Burke wrote:<br>
</span><div><div class="h5">> Just create a different form and new Authenticator. I don't think we want<br>
> all this logic with Freemarker, do we? The UI is decoupled from 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 verifying<br>
> > > credentials, but we would need some logic on how to determine what<br>
> > > mechanism to use for primary authentication and secondary authentication.<br>
> > > Bill was talking about adding some conditional flows to the authentication<br>
> > > maybe that's what we need.<br>
> > ><br>
> > > For now I'd focus on OTP though and then move on to smartcard 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>> 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 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 provider<br>
> > > > > validate otp credentials as well. The current OTP authenticator 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>> wrote:<br>
> > > > ><br>
> > > > > > Good morning,<br>
> > > > > ><br>
> > > > > ><br>
> > > > > > Today to authentication against PAM with just simple username/password<br>
> > > > I<br>
> > > > > > implemented UserFederationProvider and added the proper PAM 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 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 has(For<br>
> > > > > > example: OTP, password). We just don't know, PAM will tell 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 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/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel-" rel="noreferrer" target="_blank">http://www.keycloak.org/docs/<wbr>javadocs/org/keycloak/models/<wbr>UserFederationProvider.html#<wbr>validCredentials-org.keycloak.<wbr>models.RealmModel-org.<wbr>keycloak.models.<wbr>UserCredentialModel-</a><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>
</div></div>--<br>
<br>
abstractj<br>
PGP: 0x84DC9914<br>
</blockquote></div><br></div>