[keycloak-dev] Plan for final release

[Stian Thorgersen]

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at 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 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
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>