[keycloak-dev] Improve first login with identity provider

Vlastimil Elias velias at redhat.com
Wed Jul 15 04:37:34 EDT 2015



On 14.7.2015 15:52, Bill Burke wrote:
> I'm not convinced this is a slam dunk.  I think what you are suggesting
> is a pain in the ass for users.  Why would users ever care if accounts
> are linked?  I don't ever see social sites prompting me to merge or link
> accounts.  I have never linked social provider accounts on any website.
>    Users should never be prompted beyond the initial login for anything
> if at all possible.
>
> In most cases, I think the default behavior should be to just have
> separate UserModels and store the email in an attribute.  IMO, the vast
> majority of applications will work in this manner.  Linking will be
> rare.  IMO, I think jboss.org should work in this way too.  WTF do users
> care if their accounts are linked or not for JBoss.org?

Because you lost all your historical data if you start to use new 
account created over social login without linking.
And you are also forced to enter another email address to this new 
account if email uniqueness is required. Many peoples do not want to use 
another email address.

I agree that this is typically not a problem for new sites which starts 
with empty user base, but once you start to use KC with social linking 
for older site with existing user base the problem is more urgent. And 
also as your site will be older and users start to return to it after 
longer time when they forgot they used it previously.

> They probably
> don't.  And will probably be annoyed when they are required to do so.
>
> IMO, only email should be used to detect existing accounts.  Google
> "Bill Burke" and you will get 56 million results.  No, I'm not that
> popular, but my name is!  Also the username bburke, bill.burke, or
> wburke is usually taken whenever I create an account on a social site.
>
> There's really two scenarios here.
>
> 1) User login
> 2) User wants to link accounts in Account Service page.
>
> For User login, there should be a global config page for IDP federation
> with a "duplicate account policy" with these options:
>
> * "None" - store email in an attribute
> * "Prompt" - prompt user if they want to merge and require them to login
> with the other accounts
> * "Require" - require the user to merge their accounts
> * "Trust" - trust the providers and automatically merge.
>
> Each IDP could have a switch "Trusted".  With options of "always",
> "email-verified", "not-trusted".
>
> For merging, IMO, UserModels should never be deleted.  A user may have
> made forum posts or done other actions under that userid.  Instead that
> UserModel should be disabled and linked to the master UserModel.
>
> On 7/14/2015 3:49 AM, Stian Thorgersen wrote:
>> We should improve the first login with identity provider flow as it's less than elegant at the moment. Some of the suggestion below is how it already works and some not!
>>
>> The mechanism to detect existing accounts should include:
>>
>> * Username
>> * Email
>> * Firstname and lastname
>>
>> This needs to work both initially on the callback from the identity provider, but also after the user has updated the profile. If an existing account is detected the user should be given the option to do one of the following:
>>
>> * Cancel
>> * Merge - this will require the user to authenticate as the existing user. Once authenticated the attributes, roles and identity-provider links from the new user are copied to the existing user (not overriding existing attributes/roles/links)
>> * Continue - only if existing account is found by firstname and lastname
>>
>> For this to work it's probably easier to initially always create the account. To get around the case where email is duplicated we can set that as an temporary attribute rather than the email.
>>
>> We also need to make sure we can define what attributes are required for a user in a realm, including validation of each attribute. If any of these attributes are missing the user will have to update the profile.
>>
>> Finally, we should add a expires on a user account. If a user initiates the login with an identity provider, but never completes the above actions (for example closes the browser on the existing account screen, or the update profile screen) the account should automatically be removed after a given time.
>>
>> With regards to required actions it should be possible to configure one or more required actions for first login for a specific identity provider.
>>
>> It would be nice to nail down this flow once and for all! If we can all agree on the flow, we can allocate someone to implement it for 1.5.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>

-- 
Vlastimil Elias
Principal Software Engineer
jboss.org Development Team



More information about the keycloak-dev mailing list