[keycloak-dev] 1.0 Final roadmap
matzew at apache.org
Tue Feb 25 12:57:02 EST 2014
On Tuesday, February 25, 2014, Stian Thorgersen <stian at redhat.com> 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.
We have OAuth2 (JS/iOS - Android coming).
Could give that a shot;
> 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:
> KEYCLOAK-313 Manage devices
> KEYCLOAK-311 Custom user profiles
> KEYCLOAK-310 SPI for multi-factor authentication
> KEYCLOAK-308 Cordova adapter
> KEYCLOAK-307 iPhone adapter
> KEYCLOAK-306 Android adapter
> KEYCLOAK-301 Internationalization support
> KEYCLOAK-300 Auto configuration of MySQL or PostgreSQL in OpenShift
> KEYCLOAK-266 Integrated help in admin console
> KEYCLOAK-265 Optional instructions to social providers
> KEYCLOAK-242 Add remember machine option for two factor authentication
> KEYCLOAK-182 List applications on account management
> KEYCLOAK-161 Allow users to create oauth clients through account pages
> KEYCLOAK-57 Mobile example application
> ----- Original Message -----
> > Sent: Tuesday, 25 February, 2014 4:51:44 PM
> > Subject: [keycloak-dev] 1.0 Final roadmap
> > What's left for must-have features before we can start pushing for a
> > 1.0.Final release? We need to release 1.0 sometime in June.
> Any particular reason for June?
> > * Minimal OpenID Connect support
> > * Import/Export of various items of a realm (for data migration).
> > * Aerogear bootstrap requirements
> > * Theme support for admin console so we can brand it.
> > * Revocation policies. I'm thinking Not-Before is good enough for a 1.0
> > release. We need to be able to push this to deployed apps. And also
> > maybe piggyback this information in AcessTokenResponse. This also of
> > course needs to be stored within subsystem config too, or maybe we could
> > just have adapters pull that information from server at bootup.
> 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.
> > * Remember Me for social logins
> > * Federation of users/credentials with LDAP/AD. Hopefully through
> > Picketlink.
> Is this really required for the first release?
> > * 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.
> > Scaling/Optimization:
> > * Storage cache for the token service so it doesn't hit the database.
> > * Make token service stateless for clustering environments (maybe don't
> > need for 1.0?)
> > We'll stick with only AS7/EAP/Wildfly adapters for 1st release. We also
> > have to pencil in time for weeks of test writing, benchmarking, and
> > documentation.
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> > _______________________________________________
> > keycloak-dev mailing list
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> keycloak-dev mailing list
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the keycloak-dev