[keycloak-dev] 1.0 Final roadmap
bruno at abstractj.org
Wed Feb 26 11:46:21 EST 2014
On February 26, 2014 at 11:39:45 AM, Bill Burke (bburke at redhat.com) wrote:
> Does the keypair belong to the user? Currently I'm implementing
> Connect's IDToken and having a screen that can say which ID "claims"
> application or oauth client is allowed to view. We could add custom
> user attributes and the ability to request a claim for them.
So the server could make use of that for public key encryption? If yes, that would be very handy.
> > - Unified push server
> > The passphrase is sent over the wire in raw text because that's
> required by Apple (thanks Apple). To prevent exposing user's
> passphrase. I was wondering about a key agreement to stabilish
> a shared secret between client/server, into this way the client
> could send that passphrase encrypted and the server decrypts
> it on the fly to send push messages.
> > Do you guys have something similar like that, planned? Or totally
> out of the scope? I could help.
> See above.
That might work to this scenario too.
> > - Legacy authentication
> > Currently we have basic/digest supported on the client side
> (yep, they are pretty much unsafe, but, legacies...). Is it something
> planned to be supported on Keycloak? What would be the alternatives?
> Not sure how Keycloak fits with basic/digest protocols. You
> want the
> application to handle login input and just delegate to Keycloak
> like you
> would any other JBoss/Wildfly security domain? We could provide
> feature, but then you end up with not using 90% of Keycloak's features.
> Is that what you mean?
Me neither, currently we do it with PicketLink using servlet filters, and I think we can just use Wildfly support because lose Keycloak features would be bad. The idea about basic/digest on AeroGear was to support legacy systems outside there, we can figure this out.
More information about the keycloak-dev