----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Thursday, 1 May, 2014 5:12:32 PM
Subject: Re: [keycloak-dev] Plan for final release
Brute force needs to be integrated with code as it has to refuse before
the login screen is even shown (by IP address) or after the user
attempts to login (by username).
Could we do it by adding more events? We could have events both before/after login?
That would allow us to plug-in other things to the login-cycle, and you could also re-use
the same event handlers for social and SAML logins. We could have built-in event handlers,
but also let users register their own through the SPI.
I really want the ability to redirect the user to a account management
warning screen that says something like "You logged into your account
from China. Was that you? If not, you might want to change your
credentials".
Only China? Might be worth considering North Korea as well ;)
On 5/1/2014 11:57 AM, Stian Thorgersen wrote:
> 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
>>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com