As the information is pulled from the social network on login and stored in the IDM user,
this is IMO about accessing information about the user profile in general. For this I
think 4 scopes would be sufficient:
* Basic (name, username)
* Email
* Full (address, dob and everything else)
* Social (list of what social networks are associated with the user + the corresponding
social network userId)
There may also be a need for a 5th scope which is to allow retrieving internal Keycloak
information about the user if such anything like that exists (or will in the future)?
As I said before in the future I believe we'll need to allow developers to use their
own social keys/secrets, and also in that case they would like to request additional
scopes. They would also need to have a mechanism for retrieving the access token. This is
to allow a developer to either directly use the SDK for the social network, Agrovara, or
an MBaaS to retrieve additional information (for example tweats, friends, circles, etc.).
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 30 July, 2013 5:32:12 PM
Subject: Re: [keycloak-dev] social roles
My thought was that by default, the global Keycloak social accounts
would be used (i.e. Keycloak's global Google login). APplications would
obtain user identity information from a common Keycloak REST interface.
This REST interface would gather user identity information from
registration *ALSO* from the social provider. The REALM would be
configured to pull information from the social provider (and thus get an
OAuth grant request from Google et. al.). When a social login happens,
keycloak would only ask for the social privleges that was configured for
the realm. Resources and Oauth clients would be configured with a scope
allowing them to ask for permission to obtain this user data.
* APplication redirects to Keycloak
* Keycloak figures out scope based on client_id. Scope being email,
contacts, etc.
* Keycloak redirects to Google passing the scope and itself as the
client requester.
* Google redirects back to Keycloak
* Keycloak displays its own OAuth grant page if appropriate.
On 7/30/2013 11:40 AM, Stian Thorgersen wrote:
> I'm a bit confused...
>
> Keycloak retrieves the user profile information from whatever social
> provider is used at login-time, which is then saved to IDM. An application
> that can retrieve user profiles from IDM, can obtain any details obtained
> from a social provider. I guess that information could be split into:
>
> * Basic - name, username
> * Email
> * Full - address, dob, etc.
>
> Whether or not this information came from the registration form or Facebook
> shouldn't make any difference in how an application obtains the
> information. That reminds me that an application needs to be able to
> configure what fields the registration form contains (including which are
> optional).
>
> Gathering more information from a social provider (such as tweats,
> contacts, etc.) is out of the scope of Keycloak. If an application wants
> this they would need to use their own key/secret for the provider. They
> would also need to have a way to configure what scopes Keycloak requests +
> be able to retrieve the access token (this probably doesn't need to be
> saved in Keycloak, just returned when the user logs in).
>
> Having an additional Social SaaS that integrates with Keycloak would
> certainly be nice in the long run. In this case there would be loads more
> that can be retrieved. This is a relatively tricky thing to do as social
> sites differ quite a lot in their concepts. For example Twitter has tweats
> and followers, while Google has posts and circles. Creating a uniform api
> for multiple social sites is not trivial, certainly not when you want to
> post/upload information as well as retrieve it.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 30 July, 2013 1:55:09 PM
>> Subject: [keycloak-dev] social roles
>>
>> Each realm will probably need a set of roles that pertain to social
>> permissions i.e. : email-request, contacts, etc. We need to compile a
>> list of them...
>>
>> We'll then assign scope mappings to registered applications and oauth
>> clients if social is enabled for the realm.
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>>
http://bill.burkecentral.com
>> _______________________________________________
>> keycloak-dev mailing list
>> keycloak-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com