9:55 a.m.
* Developers may want to remove Keycloak branding (I assume this would require a paid
account or a private Keycloak server)
* Developers may want to access social providers directly (for example to read Tweats)
* Some developers (like myself) will want to spend a little time configuring social
providers to provide a best as possible option for users
* Some users (like myself) will not grant permission to a broker (Keycloak), but would be
happy to provide access to a select few applications
I can probably come up with more, but in summary:
* Configuring social providers is relatively difficult so early adapters will not want to
do it
* Advanced users will want to configure the social providers themselves for more controll
(and better, at least IMO, user experience)
* There will be several use cases where it makes sense to share social config between a
group of applications, but not globally
With regards to realms I have the same opinion. Some users may not want to manage a realm
they just want to let users register with the site and login. In which case they'd be
happy to use a public Keycloak realm.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
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