[keycloak-dev] 1.0 Final roadmap

[Bruno Oliveira]

Hi Bill,

On February 26, 2014 at 11:39:45 AM, Bill Burke (bburke at 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.