Re: [keycloak-dev] Plan for final release

I agree brute force protection is probably a lower priority for beta1, especially if we can integrate with something like fail2ban. Fail2ban looks pretty cool, and I think we can easily integrate with that as we can either use the JBoss Logging Audit Listener to create the log files required, or create a custom one that generates log files more customized for fail2ban. In the future though I think it would be nicer to have built-in support for this written in Java, which should make it easier to use and more portable. In fact that's what I had in mind initially with the audit listeners. That you'd be able to listen to events in the system and re-act accordingly. I was imagining that would be used by the brute protection to listen for failed login events. I should probably rename audit Listener to event Listener to make that clear though. If you're happy with the other high/low priority issues, as well as the release schedule I proposed, I can update JIRA to reflect this. ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; > To: keycloak-dev(a)lists.jboss.org > Sent: Thursday, 1 May, 2014 3:06:45 PM > Subject: Re: [keycloak-dev] Plan for final release > > > > On 5/1/2014 9:45 AM, Stian Thorgersen wrote: >> What are the general plans for the final release in June. I think we need >> to finish of the crucial features asap for beta1, then have a release >> cycle each for performance, testing and security. What about the following >> release schedule: >> >> * 12 May Beta1 - Feature freeze >> * 19 May Beta2 - Performance >> * 26 May Beta3 - Testing >> * 2 June RC1 - Security >> * 16 June Final >> >> With regards to Beta1 what are the outstanding required features? Those I >> can think of are: >> >> * Brute force protection - what's the status on this? > > I'm not sure brute force protection is such a high priority as long as > we log the appropriate information to log files. Go check out fail2ban. > You can set up fail2ban to change firewall rules and stuff. But, I'm > also not sure how scalable fail2ban is. > > That said, I do have user-failure based brute-force detection. It > works, but i need to add some unit tests. I still need to implement IP > based filtering (like fail2ban does). > >> * Import/export - Marek has started work on this >> * Logout everything through acct mngmt - invalidate grants, refresh tokens, >> cookies, etc for user >> * Dependencies for EAP - including support for Resteasy 2.3.6 >> * Two WARs bootstrapping example for AeroGear >> * LDAP integration - Marek is pretty much done with this >> > > I'm working on aerogear requirements. This may be more work than we > thought (see other thread). > >> Lower priority features: >> >> * Email on events - email user/admin on various events, for example if >> brute force protection suspects someone is trying to hack the account >> * Social login remember me >> * Single-sign out for JS adapter > > SSO for JS adapter can work by setting a User.notBefore on a logout with > short access tokens. Iframe might work (see OpenID connect spec). > > > -- > 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 >