[keycloak-dev] configuring social providers

[Bolesław Dawidowicz]

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...

>
>
>
> ----- 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
>