Re: [keycloak-dev] 1.0 Final roadmap
Hi Bill,
On February 26, 2014 at 11:39:45 AM, Bill Burke (bburke(a)redhat.com) wrote:
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.
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
that
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.
Thanks Bill.