[keycloak-dev] 1.0 Final roadmap

[Bill Burke]

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
http://bill.burkecentral.com