Re: [keycloak-dev] M1 release scope

Admin UI all depends on timeframe. If we can handle an end-of-year milestone, then the UIs might be doable. Also, please see my provisioning email. I'd like M1 to be something that is a simple UNZIP and run.sh. If we had a workable admin UI, this might be nice. I'm starting to feel like an end-of-year is doable. What do you guys think? On 9/19/2013 10:36 AM, Stian Thorgersen wrote: > 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 >>