1:07 a.m.
On 04/04/2019 23:59, Dmitry Telegin wrote:
Hi Marek,
On Thu, 2019-04-04 at 09:14 +0200, Marek Posolda wrote:
> Hi Dmitry,
>
> On 04/04/2019 00:45, Dmitry Telegin wrote:
>> Hi Marek,
>>
>> You absolutely right, UsernamePasswordForm does the trick. However, the login
screen rendered by UsernamePasswordForm is different from that of IdpUsernamePasswordForm
in the following aspects:
>> - IdpUsernamePasswordForm doesn't display the block with IdP/social buttons
> You're right. Small addition: The IdpUsernamePasswordForm displays
> social buttons, but just of those identity providers, which are already
> linked to specified user. In other words, if you want to link your
> account to broker-A and your account is already linked to broker-B, then
> broker-B is displayed on the form. This way, you have possibility to
> re-authenticate not just with your password, but alternatively by login
> to already linked broker-B, which is already linked to your account and
> hence "trusted" to be used for prove your identity.
>
> It seems that with your proposal in case that username is unknown, we
> won't display any brokers on the screen and hence it will be mandatory
> to do re-authentication by username+password?
Yes, that's correct.
>> - IdpUsernamePasswordForm renders the message relevant to
IdP-linking-by-reauthentication, which is this:
>>
>> federatedIdentityConfirmReauthenticateMessage=Authenticate as {0} to link your
account with {1}
>>
>> So, my requirement is to implement the appearance of IdpUsernamePasswordForm +
behavior of UsernamePasswordForm. I think this could be done either by augmenting the
former, or by merging the two authenticators into a unified one, that would exhibit
different behavior depending on the context (normal login vs. reauthentication for IdP
linking).
> I suggest to update IdpUsernamePasswordForm authenticator. In case that
> EXISTING_USER_INFO is not there, we can do the behaviour like:
>
> - User will need to provide both username+password. Hence username field
> will need to be enabled
> - Social buttons won't be displayed on the login screen
> - Message will be bit different. For example just: Authenticate to link
> your account with {1}
>
> For the case when EXISTING_USER_INFO is available, I would like to keep
> the same behaviour as currently is.
>
> WDYT?
This is exactly how I was planning to do it myself :) so if you greenlight this, I'll
proceed with JIRA/PR.
+1
Marek
Just FYI, I'm also planning to publish a "standalone" version of the
authenticator to be used with Keycloak <= 5.0.0.
Dmitry
> Marek
>
>> Please let me know which way seems better for you, with the idea in mind of
having this contributed to upstream.
>>
>> Thanks!
>> Dmitry
>>
>> On Tue, 2019-04-02 at 15:21 +0200, Marek Posolda wrote:
>>> On 28/03/2019 17:06, Dmitry Telegin wrote:
>>>> Hi,
>>>>
>>>> I'm currently working to implement the following requirements:
>>>> - users are managed externally via LDAP, self-registrations disabled;
>>>> - there is an external IdP;
>>>> - generally, there is no way to automatically match IdP identity with
Keycloak's one, so IdP linking will always be performed by the user manually;
>>>> - in order to do that, the user should click the IdP icon in the login
screen, authenticate with the IdP, get back to Keycloak and "claim" his/her
Keycloak account by entering correct username and password.
>>>>
>>>> Currently, the closest thing in Keycloak is
o.k.authentication.authenticators.broker.IdpUsernamePasswordForm (aka
"idp-username-password-form", aka "Username Password Form for identity
provider reauthentication").
>>>> However, it 1) prefills username field and makes it non-editable, 2)
depends on the preceding IdpCreateUserIfUniqueAuthenticator execution to provide existing
user model (EXISTING_USER_INFO auth note).
>>>>
>>>> My proposal is to improve IdpUsernamePasswordForm by allowing its
execution even without the preceding IdpCreateUserIfUniqueAuthenticator. In the absence of
EXISTING_USER_INFO, IdpUsernamePasswordForm should allow the user to manually enter
username.
>>> I wonder if you can't already achieve something like this with the OOTB
>>> authenticator implementations, but just correctly configure them? For
>>> example in the "First Broker Login" flow used for your identity
>>> provider, you can just directly use the default browser-based
>>> authenticator ( UsernamePasswordForm ) instead of the
>>> IdpUsernamePasswordForm. That way, the username+password form will be
>>> always shown for "First Broker Login" and once user authenticates,
his
>>> account will be linked with IdP account.
>>>
>>> Marek
>>>
>>>> Please let me know if you think it's worth having this in Keycloak.
Regards,
>>>> Dmitry
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>