[keycloak-dev] configuring social providers

Mon Jul 22 09:26:34 EDT 2013

On 07/22/2013 03:24 PM, Bolesław Dawidowicz wrote:
> On 07/22/2013 03:13 PM, Marko Strukelj wrote:
>> When using Google+ SignIn or Facebook SignIn or Twitter SignIn I
>> always get redirected to an authorization form where now there would
>> say something like:
>>
>> Application _Keycloak_ wants access to your email, and a list of
>> friends.
>>
>> Instead of saying:
>>
>> Application _SocialDemo_ wants access to your email ...
>>
>>
>> Me as a user I don't know anything about Keycloak. I came to the web
>> site of SocialDemo. When I see that Keycloak wants access to my
>> email, phishing alarms go off in my head ...
>
> Exactly...

Also IIRC you define the level of access to user information per 
application - and requirements may vary. Would it be possible with 
global account?

>
>>
>>
>>
>> ----- Original Message -----
>>>
>>>
>>> On 7/22/2013 8:28 AM, Bolesław Dawidowicz wrote:
>>>> On 07/22/2013 02:12 PM, Bill Burke wrote:
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Yes but then you just do it once for the whole set of your
>>>> applications. 3 clicks in the management UI, filling in 3 text
>>>> forms. Then your N applications that are configured with
>>>> KC/Broker automagically obtain support for this new social
>>>> provider
>>>
>>> Again, this is a huge usability issue.  A lot of time consuming
>>> configuration to enable social media login.
>
>
> I know but I don't think we can really avoid this part. For the reasons
> that Marko stated.
>
>>>
>>>>>
>>>>> 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....
>>>>
>>>> Doesn't you need to register KeyCloak with Google first and
>>>> obtain secret that cannot be share therefore cannot be configured
>>>> in KC OOTB?
>>>
>>> What is OOTB? Out of the box?
>>>
>>> I'm not understanding you.  Maybe we're misunderstanding each
>>> other? The Keycloak SaaS would be set up and installed by us, Red
>>> Hat.  So we would register Keycloak with Google/Twitter/etc and
>>> pre-configure Keycloak SaaS when we launch it.
>>>
>>> The OOTB, downloadable appliance would require the admin to set up
>>> the global social accounts and configure the appliance before
>>> starting it up.
>>>
>>> But what I don't want is that each Realm created on a Keycloak
>>> server to have to setup these social accounts.
>>>
>>>> Our point is that you cannot have global Google/Twitter/etc.
>>>> KeyCloak developer account provided and configured by default -
>>>> it would violate certain set of terms and conditions defined by
>>>> those providers.
>>>>
>>>
>>> You need to be more specific: These providers have terms and
>>> conditions that prevent third parties from becoming a *true*
>>> broker?  And they will disable Keycloak's account?
>>>
>>> For example, Googles terms and services says nothing that prevents
>>> us from having a global Keycloak account:
>>>
>>> http://www.google.com/intl/en/policies/terms
>
> No, you are right. I was only refering to the fact that you cannot share
> key secret. Together with assuming that you really cannot rely on the
> global account this way.
>
>>>
>>>
>>>>>
>>>>>> 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.
>>>>
>>>> I think we are a bit lost in the conversation and are talking
>>>> about a bit different things and flows. Did you try to follow the
>>>> Getting Started for the POC that Stian shared?
>>>>
>>>
>>> I thought you stated that users won't be aware of keycloak and will
>>> just see the keycloak login screen and google login screen.  This
>>> is incorrect. Each keycloak realm will have its own notions of
>>> Oauth scope and "acting on behalf of" beyond what Google et. al.
>>> can provide.
>
> I understand it may be one of scenarios. But don't you want to support a
> scenario where you can use KC as such transparent broker?
>
>>>
>>>
>>> -- 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
>