Keycloak project description
by Gabriel Cardoso
Hi Bill,
Last week I had a meeting with Catherine Robson (JBoss usability) and Matt Carrano (Red Hat User Experience Design Team) about what I am doing. I tried to describe Keycloak for them, but I was not successful, since I find the concept of the project complicated to explain for a non technical person.
Do you think you could write down a description of the project in a few lines to someone non technical be able to understand it?
Thanks
Gabriel
13 years
Social login flow
by Gabriel Cardoso
When you access websites like Pinterest and Foursquare, when you click "Log in with Facebook" you're redirected to a page / modal window asking to allow the website to access your information. In this flow, we can ask the user to fulfill more fields that we need for him to access Keycloak.
Do we need extra fields or the information provided by the social provider is enough?
Gabriel
13 years
social identity stored?
by Bill Burke
Do you guys create and persist a representation of a social user when a
social login happens? Does social logins provide some kind of unique
identifier that can be associated with the social user?
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
picketlink is a blocker
by Bill Burke
The commits I pushed for creating dynamic partitions/tiers will not be
accepted as a lot of Picketlink has been rewritten to support custom
identity types (PLINK-130). Neither will the commits I did for a
transaction abstraction.
So...the keycloak backend is in complete limbo until Picketlink gets out
another release. I'm going to keep on doing what I was doing, working
off of a picketlink fork. Hopefully it won't be that hard to port...
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
Re: [keycloak-dev] OAuth login page
by Bill Burke
Moving this to keycloak dev list.
On 7/2/2013 11:55 AM, Gabriel Cardoso wrote:
>
>>> For the login page into the identity broker admin interface, definitely,
>>> we should use UXD recommendation when they exist/make sense. I think it
>>> does in this case.
>
> Interesting point, I agree with it. Two questions:
> 1) Will we support social login for the login page into the identity broker admin interface? If so, we need to adapt the RCUE solution.
What is RCUE?
> 2) We need a register page for the Identity Broker, right? If so, it would make sense to make it in the Red Hat UI standards.
>
>>> For the application login page, the one that needs to be tuned by
>>> customers, not so much I think... The flow is different, it's an end
>>> user trying to log into a customer website and he should not be prompted
>>> with a Red Hat branded login screen but something more neutral.
>
> I guess the solution I proposed meets this requirement for now, it is pretty neutral.
>
>> Yes, the login and registration pages need to be brandable for the user. So they can have their own color schemes and logo, etc. But other than that, as long as the UXD team doesn't suck its a good idea to have company wide UI standards.
>
> So basically we need to have two login pages and two register pages (one for IdB and another for the customer), is this correct?
>
> Based on the responses I can keep talking to the UXD team about how to proceed.
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
oauth scopes
by Bill Burke
In oauth, a client can ask for a token so it can act on behalf of
another user. In Keycloak, clients will have the concept of a "scope".
The scope is the set of roles the client is allowed to ask for when it
acts on behalf of the user.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
13 years
