[keycloak-dev] M1 release scope

[Stian Thorgersen]

How about:

* Everything Bill listed in the first mail - maybe videos post-release?
* Move database implementations into separate Maven components - for M1 we'll focus on MongoDB and disable PicketLink (and only enable for M1 if we can do it timely, but it will have low priority)
* Move console into separate github project (https://github.com/keycloak/keycloak-console) - this is then released separately
* Drop auth from SaasService and use TokenService directly
* Document/tweak REST endpoints for admin/devs 
* Document/tweak REST endpoints for end-user actions
* Forms for login, registration, oauth grants, security error, reset password, verify email and update profile (social) - other than those user account management pushed to M2 (or later)
* cUrl recipes (or a simple cli ~ https://github.com/keycloak/keycloak-cli) for configuring KC - create/edit realm, create/edit app, manage users

----- 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, 19 September, 2013 1:29:52 PM
> Subject: Re: [keycloak-dev] M1 release scope
> 
> 
> 
> On 9/19/2013 5:10 AM, Stian Thorgersen wrote:
> > Bill, I assume you would be happy with Marek adding MongoDB to M1 as long
> > as we take on any work related to it?
> >
> > It's important for the MBaaS project.
> 
> I'd be happy to ditch Picketlink and use Mongo.  Marek, is it something
> that can be learned quickly?
> 
> > I think we need to have:
> >
> 
> Keep in mind that this is just a milestone release to garner community
> interest and show Red Hat management that we're capable of delivering
> something.
> 
> > * REST endpoints for admin tasks - managing realms, applications and users
> > - it should be possible to authenticate to these using TokenService
> > * REST endpoints for user tasks - login, register, change password, etc. -
> > same again authenticate using TokenService
> > * Document all REST endpoints
> > * Forms for required user actions - register, verify email, reset password,
> > update profile (for social)
> >
> 
> As I said in the OP, if we had a read-only backend that was just one or
> two big JSON or XML files, the admin could edit them directly.  Then
> there would be no need for a management REST or UI interface, no need
> for registration, email verification, reset password, etc...  We would
> just ship a token service, login page, and oauth grant page in this
> scenario.  As I mentioned in the OP, there's still a lot of work to do
> just to do this.
> 
> Another option is to hold off on the Admin Web UI and do a console
> command line interface.  This would allow us to flush out the admin REST
> interfaces.
> 
> All this depends when we want to do an M1 release.  If we're find with
> an end-of-year release, then we can keep doing what we're doing instead
> of refocusing.
> 
> > The admin console could be (and should be IMO) separated out completely. To
> > enable it you would register it as an application with the Keycloak server
> > and configure it in the same way as you use any other application. This
> > way it can be released separately to the main Keycloak server (and also
> > deployed separately). I also think we should get rid of the authentication
> > parts in SaasService and use TokenService instead. This is to reduce the
> > duplicated effort, and also I think that's the correct approach in either
> > case - the admin console (and any other consoles, cli, etc.) should just
> > be applications registered with Keycloak and use public rest endpoints for
> > authentication and to manage realms/apps/users.
> >
> 
> Ok, that sounds good.  I agree that SaaS login and registration probably
> needs to go.  From our conversations it seems that we're not going to be
> deploying Keycloak as a SaaS that services multiple accounts, even in a
> cloud environment.   All this effects the design of the backend and how
> we bootstrap, configure, and install Keycloak.  We need a separate email
> thread to discuss this.
> 
> 
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>