8:42 a.m.
----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Wednesday, 26 February, 2014 12:40:32 AM
Subject: Re: [keycloak-dev] 1.0 Final roadmap
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. :)
Nice :)
>
> 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.
Makes sense
>
>> * 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.
I think it's something that's a hard-requirement for anyone with really strong
security needs. I'd assume it would be an optional feature.
For audit we'll need to persist failed logins, maybe also last logins. We can
piggy-back on that.
Admins should be able to go to the admin console and view the recent audit logs. Users
should also be able to see events related to their account.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com