[keycloak-dev] PAM Conversations - Custom login form

[Bill Burke]

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