Re: [keycloak-dev] 1.0 Final roadmap
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