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>
To: "Stian Thorgersen" <stian(a)redhat.com>
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