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.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com