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.

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 cartridge
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 -----
> From: "Bill Burke" <bburke@redhat.com>
> To: keycloak-dev@lists.jboss.org
> 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
> keycloak-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev