[keycloak-dev] configuring social providers

Stian Thorgersen stian at redhat.com
Tue Jul 23 08:10:58 EDT 2013


-1 to my idea of a shared public realm, I think that was a stupid idea!

----- Original Message -----
> From: "Stian Thorgersen" <stian at redhat.com>
> To: "Bill Burke" <bburke at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Monday, 22 July, 2013 3:55:15 PM
> Subject: [keycloak-dev] configuring social providers
> 
> 
> * 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 at redhat.com>
> > To: keycloak-dev at 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 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
> 


More information about the keycloak-dev mailing list