10:23 a.m.
Thanks Bill, that helped. Will give it a try.
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(a)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(a)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/UserFederationP...
> > > > > [2] - https://asciinema.org/a/atwnfbu0kqfasjl65weyoiz7a
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > > abstractj
> > > > > PGP: 0x84DC9914
> > > > > _______________________________________________
> > > > > keycloak-dev mailing list
> > > > > keycloak-dev(a)lists.jboss.org
> > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > > > >
> > > --
> > >
> > > abstractj
> > > PGP: 0x84DC9914
> > >
> --
>
> abstractj
> PGP: 0x84DC9914
--
abstractj
PGP: 0x84DC9914