5:57 p.m.
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>
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