[keycloak-dev] configuring social providers

[Bill Burke]

On 7/22/2013 9:56 AM, Stian Thorgersen wrote:
> Actually I like the idea of having flexibility on this, initially I thought you where just plain wrong ;)
>
> If it's possible to create one or more social provider configurations separately to an application, then when creating an application choose which social provider config to use, we get best of both IMO.
>
> This also means that someone setting up a Keycloak server could create a global social provider config, which is then used by all applications. If on top of that we can select who can access what realms, social provider configurations and applications you can make these public or shared with a set of users. Also if we have fine-grained authz we can define that the social provider config can be used and key viewed by all, but only admins can view the secret.
>
> This also means that when setting up the online Keycloak server there would be a (sample) social provider config available to get you started with initially. Once you want more control and/or let your users get more control you can define your own social provider config.
>
> So there would be 3 things that users can create:
>
> * Realms
> * Social config
> * Applications
>
> An application has one realm, and zero or 1 social configs.
>
> In Keycloak online we could have a default public realm and social config which users can use initially. Standard users would obviously have limited access to these, for example they would not be able to:
>
> * Manage users (view users, edit users, etc.)
> * View secrets for social providers
>


Hmm, I guess for the SaaS, if you use the global Keycloak account, then 
Keycloak will only ask for the minimalist of information from Google 
(email?).  Your application will not be able to ask for additional 
scopes.  For additional scopes, you'd need to configure your own 
account(s).  Is that what you're saying?

BTW, Why would we want to disable management of users in the default 
case?  All we'd need from google is something to identify the user 
(email) so that additional application permissions could be attached to 
that user via the keycloak admin ui later on.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com