[keycloak-dev] Associate social account with IDM user

[Marek Posolda]

On 14.8.2013 10:15, Stian Thorgersen wrote:
> Another important thing is that someone who has logged in with a social account should be able to set a password in the future to login directly using Keycloak. IMO that is probably more important than being able to link multiple social accounts.
yes, I've added some note around it 
https://github.com/keycloak/keycloak/wiki/Registration-Authentication-with-social-providers-and-linking-of-social-accounts 
at flow 1. The question is if password/OTP should be mandatory or not. 
If it's not mandatory, user won't be able to login if social provider is 
offline for some reason as he don't have other credentials... In case 
that it's mandatory, we may need to redirect to registration form 
directly after social account is linked. Maybe it could be good to 
control the behaviour with configuration option.

After registration user should be able to change/reset his password 
similarly like any other normal (non-social) user.

Marek
>
> ----- Original Message -----
>> From: "Matt Wringe" <mwringe at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>
>> Cc: keycloak-dev at lists.jboss.org
>> Sent: Tuesday, 13 August, 2013 7:27:19 PM
>> Subject: Re: [keycloak-dev] Associate social account with IDM user
>>
>> 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.
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev