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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com