[keycloak-dev] 1.0 Final roadmap
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.
> - 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?
JBoss, a division of Red Hat
More information about the keycloak-dev