On 13/08/13 12:19 PM, Bill Burke wrote:
On 8/13/2013 11:55 AM, Marek Posolda wrote:
> On 13.8.2013 17:38, Matt Wringe wrote:
>> On 13/08/13 11:18 AM, Marek Posolda wrote:
>>> On 13.8.2013 16:56, Matt Wringe wrote:
>>>> On 13/08/13 07:43 AM, Marek Posolda wrote:
>>>>> Hi,
>>>>>
>>>>> Here is Marek Posolda from GateIn/JPP software engineering :-)
>>>>>
>>>>> Picketlink IDM is quite flexible and I think that there are more
>>>>> possibilities how to map it. What I am thinking about could be:
>>>>>
>>>>> 1) Map the attributes related to all social providers directly as
part
>>>>> of User itself. UserAdapter object (and also user representation in
>>>>> Picketlink) has support for dynamic attributes via method
>>>>> setAttribute/getAttribute . So it should be possible to use
attributes
>>>>> with any name and just prefix them for given social network (For
>>>>> example: attribute "social.facebook.username" could be used
for saving
>>>>> of Facebook username, attribute "social.google.username"
for saving of
>>>>> google username or email)
>>>> You should also probably consider that people can have multiple
>>>> accounts for each type. I don't have just one google account, I have
>>>> 3 (and 2 of them don't end in .google.com).
>>> The question is if keycloak should support the scenario (Single user
>>> account mapped to more social accounts of same provider). I don't
>>> think it's common setup. Anyway, option 2 (Realm adapter) should
>>> easily handle this and is probably better.
>>>> Its also common for people to use the same email address for
>>>> multiple social accounts. It may be neat to automatically ask the
>>>> user to link accounts if we notice they have logged in using one
>>>> social network and we already have a user with the same email
>>>> address registered (and of course perform the required security
>>>> checks before doing the account merge).
>>> yeah. The thing is that properly supporting this is not so easy as
>>> you really need to perform additional security checks. In case that
>>> email address is not verified by social provider, we have a security
>>> hole.
>> See "and of course perform the required security checks before doing
>> the account merge" in my original message. It would just be a reminder
>> to the user that they may already have an account on keycloak and they
>> can merge the accounts if they want. They would of course have to
>> authorize it by also logging into the existing account.
> yep, exactly. I agree that it would be nice to have this, but it's more
> tricky to support this as defacto user needs to authenticate twice and
> there are more possible states to deal with.
>
> So the case where user is already logged in keycloak and just want to
> wire his account with existing social account is easier to support. So I
> would start with support of this IMO and add more complex case later:-)
>
Would be cool if you could document the use cases in which social
account merging is required. This will help with deciding on if this is
a high or low priority item.
I think the main use case is not so much for 'merging' but for allowing
the user to switch social login types. So if I decide I no longer want
to use social_network_x and I want to switch to social_network_y
instead, I should be able to do this (or to switch between account_x and
account_y on the same network). Basically login using one social login,
add another, and then delete/disable the first.
And yes, this could be done in different ways rather than doing a merge.
Merging would also allow us to login using more than one social account.
The social networks I am logged into at work may not the same as the
ones I am logged into at home. This may also hold true for the social
networks between a desktop and mobile device.
I think being able to merge accounts is much more important if you are
looking at doing more with social networks than just social login.