[keycloak-dev] 1.0 Final roadmap

[Bruno Oliveira]

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.

- Unified push server 

Currently the Push server requires a passphrase for iOS variants, something like (borrowed from https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/README.md): 

curl -3 -v -b cookies.txt -c cookies.txt
  -i -H "Accept: application/json" -H "Content-type: multipart/form-data"
  -F "certificate=@/Users/matzew/Desktop/MyProdCert.p12"
  -F "passphrase=TopSecret"
  -F "production=true"  // make sure you have Production certificate and Provisioning Profile

  -X POST https://SERVER:PORT/CONTEXT/rest/applications/{pushApplicationID}/iOS

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?

Regarding the adapters, we could help with it for sure.

--  
abstractj

On February 25, 2014 at 9:40:38 PM, Bill Burke (bburke at redhat.com) wrote:
>  
>  
>  
> On 2/25/2014 12:44 PM, Stian Thorgersen wrote:
> > See comments in-line
> >
> > Mobile adapters would be really good to have. If we can get help  
> from the AeroGear team to do these, maybe we could include this  
> as well? For simplicity we could just aim for a working Cordova  
> example, but Android and iOS adapters would be great.
> >
>  
> Unless we get a community submission for mobile adapters, this  
> is going
> to have to wait as I'm not sure we have time. I also wanted Tomcat,  
> Jetty, Node.js, and JIRA adapters too, but those I think might  
> have to wait.
>  
> > It would also be nice to make Keycloak more "embeddable". I'd  
> like to be able to improve how Keycloak is embedded into LiveOak,  
> but there's also the issue around WildFly console needing to  
> embed it. Let's have a separate thread on this, but my current  
> (updated) thinking is to utilize RestEasy, but to remove use  
> of servlets
> >
> > There's a whole bunch of JIRA issues with fix for beta1. In the  
> effort to prune this list a bit, here's some I think we can postpone  
> to later:
> >
>  
> I vote we keep everything in JIRA until we start running out of  
> time,
> then we'll defer.
>  
> >
> > Any particular reason for June?
> >
>  
> Aerogear requirement to get us in product. Which is a good thing.  
> :)
>  
> >
> > We probably need a separate thread to discuss this, but it's  
> important that users can view what applications can currently  
> access their account and revoke access to individual apps. This  
> means we need to know what refresh tokens are valid, and which  
> have been revoked by a user.
> >
>  
> Crap. I forgot about this. Thanks for reminding me.
>  
> >> * Remember Me for social logins
> >> * Federation of users/credentials with LDAP/AD. Hopefully  
> through
> >> Picketlink.
> >
> > Is this really required for the first release?
>  
> If we want to be considered in Middleware BU as an SSO solution,  
> we need
> this. Also will relieve some tensions with PL team hopefully  
> if we
> leverage their stuff.
>  
> >
> >> * User session management. Admin can logout a user.
> >> * Audit log.
> >
> > Related things we'll need are brute force protection (including  
> max failed login attempt before locking a users account) and  
> email notifications on certain events.
> >
>  
> Wouldn't it be better just to add a 1 second sleep? Checking max  
> failed
> logins would require persistence per authentication.
>  
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev  
>