[keycloak-dev] M1 release scope

[Bolesław Dawidowicz]

Is the UI main factor for end of the year timeframe? If such I think we 
should consider having something along what Stian proposed earlier 
(Alpha/M01) - maybe around late October. Then have more with UI around 
end of the year. We don't need to make a huge buzz about first one - but 
still would be good to have something wrapped up to show.

On 09/20/2013 01:45 AM, Bill Burke wrote:
> 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
>>>
>



-- 
Bolesław Dawidowicz
JBoss Portal Platform Architect | GateIn Portal Project Lead