1:26 a.m.
On 03/11/15 15:36, Bill Burke wrote:
I hope the argument here is just what the default should be.
IMO, the default should be that a new account per social provider is
created and email duplicates are allowed. User would manually merge
accounts via the account service panel if they want.
-1 for allow email duplicates.
If you login through Facebook and there
is already user with email mposolda(a)gmail.com how you would create new
account? Save the email into some different attribute "email_no2" ?
Isn't it just ugly workaround to bypass our unique constraint for
emails? Then if user wants to login in username/password form and he
fills mposolda(a)gmail.com in login form, which account it should use? The
first one or the second one?
TBH allowing email duplications would be confusing for users. They will
mess the accounts without knowing which of their account are they
currently using.
In classic registration form, we don't allow email duplications and we
just display error message "Email already exists". User needs to use
different email or restore his first account ( via "Forget password" or
contacting admin etc). Not sure why this behaviour should be different
for registration via identity provider.
These features are equally important IMO:
* Broker providers should be able to be automatically trusted with a
switch and automatically merge accounts.
* brokers should have a flow attached to them so that they can require
account merging and such.
Merging 2 existing users in account management would be
nice to have.
Question is if we really needs it as it is a bit complex thing and
nobody really quested it so far AFAIK?
Anyway some idea how it could work:
* User is logged in account management as "user2" in "Federated
identities" tab. He clicks to "Link my account with Twitter"
* He login to twitter, but there is already existing Keycloak user
"user1" linked to this Twitter account
* Account management will display message "There is already existing
user user1 linked to Twitter. Do you want to merge accounts?"
* User clicks "yes" . There might be some additional verification
configured in the flow (for example email confirmation). But not sure if
it's critical as user is already able to login as "user1" via Twitter,
so he is already proved to be owner of both accounts.
* Now the merging itself can work like:
-- user1 will have flag MERGED on his account with the attribute
"parent_user" pointing to user2 .
-- user2 will be added to all roles and groups, which user1 had. So
defacto user2 will have union of roles+groups of both users.
-- All attributes of user1 will be merged to user2 . If there is
attribute "foo" available on both user and there are conflicting user,
the original value of user2 will be kept.
-- User2 will be added to all federated identities of user1. Again, if
there is conflict (For example if both users have different Facebook
identity), the original user2 federated identity has preference.
-- Account "user1" will become decomissioned and it's not possible
anymore to login into it. When user later authenticates as user1 with
his user1 password, he will be authenticated as user2 instead.
WDYT? Should I go this way?
Marek