[keycloak-dev] 1.0 Final roadmap

[Corinne Krych]

On 26 February 2014 15:42, Stian Thorgersen <stian at redhat.com> wrote:

>
>
> ----- Original Message -----
> > From: "Bill Burke" <bburke at redhat.com>
> > To: "Stian Thorgersen" <stian at redhat.com>
> > Cc: keycloak-dev at lists.jboss.org
> > Sent: Wednesday, 26 February, 2014 12:40:32 AM
> > Subject: Re: [keycloak-dev] 1.0 Final roadmap
> >
> >
> >
> > On 2/25/2014 12:44 PM, Stian Thorgersen wrote:
> > > See comments in-line
> > >
> > > Mobile adapters would be really good to have. If we can get help from
> the
> > > AeroGear team to do these, maybe we could include this as well? For
> > > simplicity we could just aim for a working Cordova example, but Android
> > > and iOS adapters would be great.
>

Sure, we could give it a trial with our iOS adapter.
Android one is not yet available.



> > >
> >
> > Unless we get a community submission for mobile adapters, this is going
> > to have to wait as I'm not sure we have time.  I also wanted Tomcat,
> > Jetty, Node.js, and JIRA adapters too, but those I think might have to
> wait.
> >
> > > It would also be nice to make Keycloak more "embeddable". I'd like to
> be
> > > able to improve how Keycloak is embedded into LiveOak, but there's also
> > > the issue around WildFly console needing to embed it. Let's have a
> > > separate thread on this, but my current (updated) thinking is to
> utilize
> > > RestEasy, but to remove use of servlets
> > >
> > > There's a whole bunch of JIRA issues with fix for beta1. In the effort
> to
> > > prune this list a bit, here's some I think we can postpone to later:
> > >
> >
> > I vote we keep everything in JIRA until we start running out of time,
> > then we'll defer.
> >
> > >
> > > Any particular reason for June?
> > >
> >
> > Aerogear requirement to get us in product.  Which is a good thing. :)
>
> Nice :)
>
> >
> > >
> > > We probably need a separate thread to discuss this, but it's important
> that
> > > users can view what applications can currently access their account and
> > > revoke access to individual apps. This means we need to know what
> refresh
> > > tokens are valid, and which have been revoked by a user.
> > >
> >
> > Crap.  I forgot about this.  Thanks for reminding me.
> >
> > >> * Remember Me for social logins
> > >> * Federation of users/credentials with LDAP/AD.  Hopefully through
> > >> Picketlink.
> > >
> > > Is this really required for the first release?
> >
> > If we want to be considered in Middleware BU as an SSO solution, we need
> > this.  Also will relieve some tensions with PL team hopefully if we
> > leverage their stuff.
>
> Makes sense
>
> >
> > >
> > >> * User session management.  Admin can logout a user.
> > >> * Audit log.
> > >
> > > Related things we'll need are brute force protection (including max
> failed
> > > login attempt before locking a users account) and email notifications
> on
> > > certain events.
> > >
> >
> > Wouldn't it be better just to add a 1 second sleep?  Checking max failed
> > logins would require persistence per authentication.
>
> I think it's something that's a hard-requirement for anyone with really
> strong security needs. I'd assume it would be an optional feature.
>
> For audit we'll need to persist failed logins, maybe also last logins. We
> can piggy-back on that.
>
> Admins should be able to go to the admin console and view the recent audit
> logs. Users should also be able to see events related to their account.
>
> >
> > --
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20140226/59a06557/attachment.html