[keycloak-dev] priorities and who is available?

[Stian Thorgersen]

+1 To all of those, especially the WildFly sub-system

I've got some more stuff:

Features for LiveOak:

* Mongo store - this would be the default used in LiveOak
* Theme support for forms - I've got an idea how this will work and I'll send out an email about it next week

General features:

* Audit - at least audit basic events for now. Start with a basic audit spi, and a log based impl? Console, read, notifications, db, etc can come later.
* Security review - we should have a security review of code/features
* Code de-crapping - there's smelly code and duplicated code, time for some refactoring? Personally I'd like to see the code improved, but I don't want to spend weeks re-learning the code base either. A good approach would be to identify the biggest pain points, discuss a solution, refactor, then once refactored send out a summary email covering the changes
* Export/import - support dumping all data to a single json file. This will be useful for migrating db between versions, moving to a different store, backup, etc..
* Data migration plan - new releases will have new db schemas. A nice and simple approach to this is to use the export/import feature. We can have a pipeline that can converts a json export from version 1, to version 2, to version 3, etc..
* HMLT5/JS lib - we have a working JS lib in LiveOak for Keycloak, we should be able to pull this in with minimum effort
* Application/client types (service, public, mobile, ?) - there's a few things that are different depending on the client type. For example a public client (i.e. html5) are required to set a valid redirect_uri and doesn't require a password, while for a private client (i.e. rest service) redirect_uri is optional and password required
* Extend testsuite - add more tests to the testsuite, especially it would be great to see some tests for the admin console
* JPA db - test on production dbs (postgresql, mysql, do we even bother with oracle?)

Some comments in-line as well.

----- Original Message -----
> From: "Bill Burke" <bburke at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, 24 January, 2014 2:29:26 AM
> Subject: [keycloak-dev] priorities and who is available?
> 
> I'd like to do another release in February.  Let's get an idea on
> available resources, what the priority are, and who can work on what.
> Let's see what work we can do in parallel.
> 
> Key functionality:
> 
> * Get Stan's Wildfly subsystem incorporated.
> * Figure out appropriate addition to admin console for Stan's subsystem.
>   An SPI or something as well as UI.
> * Composite Roles.
> * Clean up Forgot Password and Reset password.  Should be possible for
> admin to send user an email with a URL that allows them to reset the
> password.  Right now requires entering in a password, telling user, and
> sending an email.

I assume you're only talking about when an admin resets the password on-behalf of the user?

It should be simple enough to add a button to let an admin send a password reset link to a user as we already have that functionality for the user themselves. It's that what you want? We still need the option of being able to set a temp password in case the user doesn't have a email registered (or emails can't be used for whatever reason).

> * Password Policies are broken.

I'll get the ball started on the next release and fix that once I've finished writing this mail ;)

> * Revocation policies.
> * Storage protection.  Smarter password hashes and protection of private
> keys and OTP keys.
> * User session management.  Be able to show and list users logged into
> an app and be able to remotely logout one or all of them.
> * More CORS options at the adapter level.
> * Device mgmt and security.  Need input from Bruno.
> 
> Basically, we should have laser focus on critical features that must be
> implemented to have a functional Keycloak release, but also to support
> the needs of Red Hat projects specifically LiveOak, Wildfly, and
> Aerogear.  Having Keycloak drive security for those 3 projects will get
> us a lot more users than if we just went at it alone.
> 
> Personally, I'd like to get Stan's work incorporated as soon as possible
> and figure out a UI around it.  We should brainstorm together, but I
> think we may have to rethink some of our UI.
> 
> --
> 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
>