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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________ keycloak-dev mailing
list keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev