[keycloak-dev] Improve first login with identity provider

[Bill Burke]

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?  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
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com