Re: [keycloak-dev] M1 release scope

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(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: keycloak-dev(a)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 >