[keycloak-dev] configuring social providers

Mon Jul 22 09:23:32 EDT 2013

I'm confused, I'll try to step through the process of a user that logs in via Google through Keycloak, to check that we have the same understanding:

1. A user visits www.acme.com and clicks on login (see attachment p01.jpg)
2. The user clicks on the Google icon as the user can't be asked to register with yet another site
3. The user is redirected to Google to allow Acme to access basic details about his account (see attachment p02.jpg)
4. The user is redirected back to the Keycloak callback, which retrieves the user profile from Google, creates an internal user in Keycloak, and eventually redirects the user back to www.acme.com/logged-in

Next time the user visits www.acme.com (and is not still logged-in) the user can click the login with Google icon again and is redirected to www.acme.com/logged-in without having to grant permission to the application, or login to Google (as long as the user is already logged in with Google).

Finally, the user can now choose to disable access for the application to his Google account (see attachment p03.jpg). If the application is revoked, the user expects to next time he tries to login with Google to have to re-authorize access for Acme to his Google account.

The key things to note is that a user grants access to his Google account, which he does to Acme (the application), not to the Keycloak server. Initially I would say it's best to have a config per application, then later introduce a mechanism to share these between multiple applications when that makes sense. However, for an online version of Keycloak (public SaaS) it would never make sense to have a global configuration.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Monday, 22 July, 2013 1:12:13 PM
> Subject: Re: [keycloak-dev] configuring social providers
> 
> 
> 
> On 7/22/2013 7:48 AM, Bolesław Dawidowicz wrote:
> > The whole concept of the broker for social stuff is built around two
> > points:
> >
> > a) Application developer doesn't care about configuration of G+,
> > twitter, FB, linkedIn and etc. at the app code level. He just does it
> > single time in the management console for his app(s). Then he just
> > interacts with broke/keycloak APIs. If there is new social provider
> > added and configured via management console - it just appears in the app
> > login screen. From application code perspective this is pretty much
> > transparent. Important point is that those social services cannot be
> > preconfigured as you cannot share key secret publicly
> >
> 
> Nothing you have said has convinced me you CAN'T use a global keycloak
> google account.  Login will be a double OAuth invocation.  Redirects
> will be Application->Keycloak->Google->Keycloak->Application.
> 
> This is a usability issue.  If we go the IdentityBroker route, a
> keycloak user would have to register and create a social account for
> each social provider they want to enable.  If a new social becomes
> popular, they won't automatically get this new provider, they will again
> have to register for an account and configure keycloak.
> 
> I'd like to see just one checkbox "Enable Social Login".  When the admin
> checks this, they get everything we can integrate with or will be able
> to integrate with.  Simple easy....
> 
> > b) Application User doesn't need to be aware about about existence of
> > keycloak/broker. From the user perspective he is interacting only with
> > the app and social providers (g+, twitter, etc.).
> >
> 
> Incorrect.  For the OAuth case, Keycloak will be specifying messages
> like "Application XXX is requesting permission to access your
> inventory."  Google only does OAuth for Google apps, AFAICT.
> 
> For single-sign-on, users will be redirected to Keycloak.  If there is a
> keycloak session cookie set, then no social login is required, but the
> 2nd application the user visits still needs to obtain a token.
> 
> > On 07/22/2013 01:35 PM, Bill Burke wrote:
> >> This is all stuff keycloak takes care of.  Once a user is logged into
> >> keycloak, they are remembered (until cookie timeout or a logout) and
> >> there's no need to go back to Google.  The same thing goes with "Foo is
> >> requesting permission..."  This is all something Keycloak will take care
> >> of and must take care of anyways as Google only manages its own
> >> applications.
> >>
> >> So, again, I don't see why you couldn't use a global keycloak account.
> >>
> >> On 7/22/2013 4:44 AM, Stian Thorgersen wrote:
> >>> A key/secret in Google (and same for Facebook, Twitter, etc.) maps onto
> >>> the configuration for a single application. First time a user logs in to
> >>> an application through Google (with or without Keycloak) they expect to
> >>> see a message "Foo is requesting permission to ...". Second time they
> >>> log in to the same application they are just redirected back to the
> >>> application and automatically logged in (if they are already logged in
> >>> to Google that is). If they try to log in to a different application
> >>> they expect the message "Bar is requesting permission to ...". Also in
> >>> their Google account they can list all the applications that have access
> >>> to their account, including what information they can access. They can
> >>> also revoke access to individual applications.
> >>>
> >>> This requires a separate configuration for each application for each
> >>> enabled social provider. Hence why in IdentityBroker there's a list of
> >>> social providers, including the key/secret, for each individual
> >>> application. The plan was that further down the line it would be
> >>> possible to share social provider configurations between a group of
> >>> related applications. Maybe "a group of related applications" maps onto
> >>> a realm, in which case we could have this configured on a realm instead
> >>> of on individual applications.
> >>>
> >>> In the end it boils down to on what level should users be able to
> >>> accept/revoke access to their social accounts, and what details are
> >>> shown on their social account about the application. In my opinion this
> >>> is definitively not a server wide setting. Also it's not possible to
> >>> automatically configure this as it has to be linked to some ones social
> >>> account (to use login with Google+ you have to have a Google+ account).
> >>>
> >>> ----- Original Message -----
> >>>> From: "Bill Burke" <bburke at redhat.com>
> >>>> To: keycloak-dev at lists.jboss.org
> >>>> Sent: Saturday, 20 July, 2013 2:45:17 AM
> >>>> Subject: [keycloak-dev] configuring social providers
> >>>>
> >>>> In looking at your demo, is there any reason you need to define the
> >>>> metadata for the social provider?  Can't you either
> >>>>
> >>>> a) Preconfigure Keycloak server with Twitter, Google+ account?
> >>>> b) Automatically configure the social provider without user input.
> >>>>
> >>>> Since Keycloak is already a broker, why does a user need to input any of
> >>>> that metadata?
> >>>>
> >>>> --
> >>>> Bill Burke
> >>>> JBoss, a division of Red Hat
> >>>> http://bill.burkecentral.com
> >>>> _______________________________________________
> >>>> 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
> >
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p01.jpg
Type: image/jpeg
Size: 17232 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20130722/91717c40/attachment-0003.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p02.jpg
Type: image/jpeg
Size: 21809 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20130722/91717c40/attachment-0004.jpg 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: p03.jpg
Type: image/jpeg
Size: 50725 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/keycloak-dev/attachments/20130722/91717c40/attachment-0005.jpg 