Re: [keycloak-dev] 1.0 Final roadmap

From: "Corinne Krych" <corinnekrych(a)gmail.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Wednesday, 26 February, 2014 3:09:43 PM Subject: Re: [keycloak-dev] 1.0 Final roadmap On 26 February 2014 15:42, Stian Thorgersen <stian(a)redhat.com&gt; wrote: > > > ----- Original Message ----- > > From: "Bill Burke" <bburke(a)redhat.com&gt; > > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > > 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. > Sure, we could give it a trial with our iOS adapter. Android one is not yet available.

> > > > > > > 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 > > > _______________________________________________ > keycloak-dev mailing list > keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev >