From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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(a)redhat.com&gt; >> To: keycloak-dev(a)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(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 >

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

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

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

----- Original Message ----- > 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? > You mean that by granting access to my list of friends when signing in via SocialDemo, I would be granting the same access to acme.com and all the apps using Keycloak? :) I'd say that's the case, yes.

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Monday, 22 July, 2013 2:44:50 PM Subject: Re: [keycloak-dev] configuring social providers On 7/22/2013 9:39 AM, Marko Strukelj wrote: > > > ----- Original Message ----- >> 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? >> > You mean that by granting access to my list of friends when signing in via > SocialDemo, I would be granting the same access to acme.com and all the > apps using Keycloak? :) > I'd say that's the case, yes. > You win. You're right I'm wrong You're the best, I'm the worst You're good looking, I'm not very attractive... -- 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

+1. It also hit me during this conversation that Bill is quite right around the idea he pushed for - just missed some constraints. Making it easier to use OOTB sounds very good. It just needs to be more configurable then that. On 07/22/2013 03:56 PM, 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 > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; To: >> keycloak-dev(a)lists.jboss.org Sent: Monday, 22 July, 2013 2:44:50 >> PM Subject: Re: [keycloak-dev] configuring social providers >> >> >> >> On 7/22/2013 9:39 AM, Marko Strukelj wrote: >>> >>> >>> ----- Original Message ----- >>>> 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? >>>> >>> You mean that by granting access to my list of friends when >>> signing in via SocialDemo, I would be granting the same access to >>> acme.com and all the apps using Keycloak? :) I'd say that's the >>> case, yes. >>> >> >> You win. >> >> You're right I'm wrong You're the best, I'm the worst You're good >> looking, I'm not very attractive... >> >> -- 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 > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Monday, 22 July, 2013 3:33:22 PM Subject: Re: [keycloak-dev] configuring social providers On 7/22/2013 10:15 AM, Marko Strukelj wrote: > I don't exactly remember where I saw this but it was with one of existing > identity broker providers ... When you set up application you specify what > your application needs i.e. > > - Access Email > - Access List of Friends > - Post to wall > - Access Documents > - Access Location > > You just click checkboxes, and broker requires social provider specific > appropriate access profiles. > > If all the interaction with social graph and social service specific APIs > would be proxied through Keycloak APIs then Keycloak can limit access > based on application profile, regardless if another application triggered > user to grant a greater access to Keycloak then one specific application > requires. > > Also the phishing alarm when seeing Keycloak mentioned in authorization > form can be alleviated by adding a Powered by Keycloak badge to SignIn > page of the app, or mentioning Keycloak some other way. > That's a good point. So what are the current downsides of a global account?: * Revoke page would only have keycloak.org listed * Social login page would state that Keycloak (and not the app) is interested in a specific scope. Which could be mitigated by having a "Powered by Keycloak" on the signin page of the app. -- 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

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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)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(a)redhat.com&gt; >>>> To: keycloak-dev(a)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(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 >>> >> > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev