[keycloak-dev] PAM Conversations - Custom login form

Tue Aug 16 03:12:48 EDT 2016

I'd say option 1 then. Folks can customize the login screen if they want
something else.

On 15 August 2016 at 15:35, Bruno Oliveira <bruno at abstractj.org> wrote:

> On 2016-08-15, Stian Thorgersen wrote:
> > 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.
>
> There are some alternatives for it:
>
> 1. Document and leave it as is for the SSSD federation provider. People
> coming from FreeIPA world are familiar with this.
>
> 2. Add a label inside the password field like FreeIPA console does[1]
> for usability purposes. From my understanding, it would require
> extending UsernamePassword form and provide a new login interface.
>
> 3. Provide new OTP screen for SSSD provider with a single field, "OTP"
> and QRCode info omitted. Because, all the steps to configure two-factor
> happen on the FreeIPA side.
>
> My suggestion is to stick with 1 for now and iterate over it for
> improvements.
>
>
> [1] - http://imgur.com/eyk5Ewx
>
> >
> > On 25 July 2016 at 23:33, Bruno Oliveira <bruno at 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 at 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 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
> > > > > > >
> > > > > --
> > > > >
> > > > > abstractj
> > > > > PGP: 0x84DC9914
> > > >
> > >
> > > --
> > >
> > > abstractj
> > > PGP: 0x84DC9914
> > >
>
> --
>
> abstractj
> PGP: 0x84DC9914
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20160816/3738da22/attachment-0001.html 