[keycloak-dev] PAM Conversations - Custom login form

[Bruno Oliveira]

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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >

--

abstractj
PGP: 0x84DC9914