[keycloak-dev] 1.0 Final roadmap

Bill Burke bburke at redhat.com
Wed Feb 26 09:39:40 EST 2014

On 2/26/2014 9:26 AM, Bruno Oliveira wrote:
> Hi Bill, I’m not sure if this is planned, but don’t hurt to ask. For Aerogear we have the following needs and I would like to help if it's planned for Keycloak (I don't want to create overlappings)
> - Data sync
> Scenario: user must update the data on the server, but it must be stored encrypted.
> I'm considering to generate a key pair during the "handshake" between client and server and send client's public key to the server. In this way prevent user's data violation.

Does the keypair belong to the user?  Currently I'm implementing OpenID 
Connect's IDToken and having a screen that can say which ID "claims" an 
application or oauth client is allowed to view.  We could add custom 
user attributes and the ability to request a claim for them.

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

> - 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 that 
feature, but then you end up with not using 90% of Keycloak's features. 
  Is that what you mean?

Bill Burke
JBoss, a division of Red Hat

More information about the keycloak-dev mailing list