[keycloak-dev] M1 release scope

[Bill Burke]

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 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
>>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com