[keycloak-dev] 1.0 Final roadmap

[Bill Burke]

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