[keycloak-dev] Associate social account with IDM user

[Marek Posolda]

I've sent PR https://github.com/keycloak/keycloak/pull/30 to address 
https://issues.jboss.org/browse/KEYCLOAK-25 and 
https://issues.jboss.org/browse/KEYCLOAK-27 . What I did is:

- Added another relationship type represented by SocialLinkModel 
(SocialLinkRelationship for Picketlink IDM integration) which represents 
binding between user and one social provider/username. User can have N 
social links, which means that single user can have many wired social 
accounts  (also many wired social accounts of same social provider)

- Added boolean realm option "automaticRegistrationAfterSocialLogin" 
where administrator can specify whether each user is automatically 
registered after successful social login (this means that all attributes 
of user are automatically prefilled from social network and his 
password/TOTP is initially not set) or whether user is redirected to 
registration screen with pre-filled attributes where he can change or 
fill missing data including credentials. Added flows for support of both 
options.

- Now username is generated from
-- Facebook username in case of Facebook
-- Google email in case of Google
-- ScreenName in case of Twitter
but users can change generated username in case that 
"automaticRegistrationAfterSocialLogin" is false

Another step would be to add support for linking/unlinking of social 
accounts (https://issues.jboss.org/browse/KEYCLOAK-26) which would mean 
that user can have more social accounts linked.

Cheers,
Marek


On 14.8.2013 15:37, Marek Posolda wrote:
> 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
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev