[keycloak-dev] Plan for final release
Stian Thorgersen
stian at redhat.com
Thu May 1 11:57:36 EDT 2014
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 at redhat.com>
> To: keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
More information about the keycloak-dev
mailing list