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.

On 25 July 2016 at 23:33, Bruno Oliveira <bruno@abstractj.org> wrote:
Hi Bill,

After giving these ideas a try, I started to think about the FreeIPA
flow and how 2FA validation works. If we provide for the first factor
username + password or username + (password and OTP - in the same field),
credentials will be validated anyways. I was misguided by the second prompt
from sudo, thinking that second factor was mandatory (sorry about that).

The same happens for the FreeIPA web interface, we just provide username +
password and OTP (if it was configured).

That said, I believe we don't have to add any extra code, aside of what
we already have for the SSSD Federation provider. I've already
tested it with and without OTP. The only downside of this approach is
the fact that we're not going to have an OTP screen and it has to be
documented in some place.

Does anyone have objections about leaving the flow as is?

On 2016-07-20, Bill Burke wrote:
> Just create a different form and new Authenticator.  I don't think we want
> all this logic with Freemarker, do we?  The UI is decoupled from credential
> validation on purpose so that you can move things around, i.e. a Username
> screen, then the next screen is password/OTP input.
>
> Another thing you could do is collect credentials and store them in the
> ClientSessionModel, then once you've collected the credentials, validate
> them all in one go.
>
> On 7/20/16 10:06 AM, Bruno Oliveira wrote:
> > On 2016-07-19, Stian Thorgersen wrote:
> > > Adding Bill..
> > >
> > > It would probably still be better to use user federation for verifying
> > > credentials, but we would need some logic on how to determine what
> > > mechanism to use for primary authentication and secondary authentication.
> > > Bill was talking about adding some conditional flows to the authentication
> > > maybe that's what we need.
> > >
> > > For now I'd focus on OTP though and then move on to smartcard afterwards.
> > I can give it a try and workaround, but I'm not sure if worth the
> > effort, assuming that later will be necessary to revisit.
> >
> > If we hardcode/workaround it on Keycloak, user's coming from FreeIPA
> > may have their login denied. Even if we ignore smartcards for now. Why?
> >
> > Depending on the auth types SSSD will show different login prompts. For
> > example:
> >
> > * Password
> >    Login prompt - $ Password:
> >
> > * OTP
> >    Login prompt -> $ First factor:
> >                    $ Second factor:
> >    Note: Please notice that they are not validated separately
> >
> > * Password + OTP -> $ First factor or password:
> >
> > That's the reason why I would like to make the our login screen
> > dynamic.
> >
> > > On 19 July 2016 at 11:00, Bruno Oliveira <bruno@abstractj.org> wrote:
> > >
> > > > The problem here is the fact that not necessarily the
> > > > first factor will be a pasword or the second factor an OTP. It
> > > > could be a smartcard for example. That's why I think is a better idea to
> > > > make it dynamic, because we don't have control over it to tell
> > > > if the second factor will be a smartcard or an OTP for example.
> > > >
> > > > Does it make sense?
> > > >
> > > > On 2016-07-19, Stian Thorgersen wrote:
> > > > > Looks like it's better to keep as is and have user federation provider
> > > > > validate otp credentials as well. The current OTP authenticator delegates
> > > > > to user federation provider, so you'd end up with a separate OTP
> > > > > authenticator to do it with PAM.
> > > > >
> > > > > On 19 July 2016 at 00:48, Bruno Oliveira <bruno@abstractj.org> wrote:
> > > > >
> > > > > > Good morning,
> > > > > >
> > > > > >
> > > > > > Today to authentication against PAM with just simple username/password
> > > > I
> > > > > > implemented UserFederationProvider and added the proper PAM login to
> > > > > > validCredentials[1]. This covers the most basic scenario.
> > > > > >
> > > > > > Now I would like to cover a more complex scenario like OTP and change
> > > > > > the flow a little bit like this:
> > > > > >
> > > > > > 1. User providers her username
> > > > > > 2. The next screen asks to provide how many factor our user has(For
> > > > > > example: OTP, password). We just don't know, PAM will tell what's next.
> > > > > > 3. We authenticate against it
> > > > > >
> > > > > > To see in practice against FreeIPA server, I just recorded it
> > > > > > for a practical example[2].
> > > > > >
> > > > > > What would be the best approach to implement this flow? I was
> > > > considering
> > > > > > to
> > > > > > move my authentication logic out of SSSD federation provider and
> > > > create a
> > > > > > PAM
> > > > > > authenticator.
> > > > > >
> > > > > > Does it make sense?
> > > > > >
> > > > > > [1] -
> > > > > >
> > > > http://www.keycloak.org/docs/javadocs/org/keycloak/models/UserFederationProvider.html#validCredentials-org.keycloak.models.RealmModel-org.keycloak.models.UserCredentialModel-
> > > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a
> > > > > >
> > > > > >
> > > > > > --
> > > > > >
> > > > > > abstractj
> > > > > > PGP: 0x84DC9914
> > > > > > _______________________________________________
> > > > > > keycloak-dev mailing list
> > > > > > keycloak-dev@lists.jboss.org
> > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > > >
> > > > --
> > > >
> > > > abstractj
> > > > PGP: 0x84DC9914
> > > >
> > --
> >
> > abstractj
> > PGP: 0x84DC9914
>

--

abstractj
PGP: 0x84DC9914