We need to decide what we want to do for M1. Here's my stab at it. Let's discuss in email first as much as we can and then have a hangout sometime next week to go over it and nail things down. First and foremost. We have to focus. No new features. No playing around. For example: no adding refresh token support. No client-cert support. No changes to protocols. No new backends. Let's just use Picketlink JDBC. No 'forgot password' using SMS, etc... You get the picture.

Required: * Social Broker login with as many providers as possible. Minimally Google and Facebook. * SSO and SLO (Single Log Out) * Password and TOTP login * OAuth Client Grant support * Example with apps using all o these features * Keycloak website setup and finalized * Online video walking through a demonstration of features * Online video walking though how to configure it * JBoss 7.1.x Community and JBoss EAP 6.1 support Knowing this there are two paths we can take. We can either include an Admin UI in M1 or not. IMO, if we do *NOT* have an Admin UI for M1, we probably need to not have registration or account management. Here's what it might look like: Option #1: No Input UIs * A read-only XML/JSON file-based backend. Users must edit this to add users, roles, etc... * No Admin UI * No Registration, forgotten passwords, account management. All these require runtime updates to the database. * What would we do about social though? As it requires registration? Work required (time estimates could take shorter or longer depending on interruptions): * 1-2 man-weeks to do file-based back-end * 1-5 days to design the OAuth Grant Pages. * 1 day to incorporate Grant pages * Do we want fancier demo apps to show SSO and OAuth Grants? If so, this is minimum 2 weeks. 1 to get Event Juggler hooked into Keycloak. 1+ weeks to create another related SSO application. 1+ more to create an OAuth application. * 1 week to organize the Website and create demo videos. * 1-2 weeks for documentation * 1+ weeks to decide and implement how we're going to distribute keycloak. Will it be a AS7 and/or EAP distro? A WAR? etc... So best case scenario is end of October. It would minimally require myself and Gabriel. Others would be needed if we want fancier demo apps as it is beyond my ability to create a nice looking demo app in a short period of time. Option #2: UIs This would take a lot more work as we would need to finish up the admin, registration, and account management UIs. I'd say Christmas time would be a viable M1 release for this. This would require everybody.

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt; Cc: keycloak-dev(a)lists.jboss.org Sent: Thursday, 19 September, 2013 9:28:12 AM Subject: Re: [keycloak-dev] M1 release scope On 19.9.2013 03:11, Bill Burke wrote: > We need to decide what we want to do for M1. Here's my stab at it. > Let's discuss in email first as much as we can and then have a hangout > sometime next week to go over it and nail things down. > > First and foremost. We have to focus. No new features. No playing > around. For example: no adding refresh token support. No client-cert > support. No changes to protocols. No new backends. Let's just use > Picketlink JDBC. No 'forgot password' using SMS, etc... You get the > picture. At this moment, I have working MongoDB backend and I would like to send PR with it by the end of this week. I just need to adapt this with latest changes in RealmModel and UserModel interfaces (added new fields related to requiredActions and totp). TBH I don't know why to not have it as part of M1? I am not seeing any disadvantages for people to have possibility to choose from more backends? Another thing is that it is easier for people to see or edit DB content directly in MongoDB database. Of course it's not so easy as directly edit XML/JSON file, but much easier than Picketlink IDM DB schema, which is quite complex. I am seeing just one disadvantage that every change in model interfaces needs to be adapted to both backend implementations, but you can always workaround this by implement stuff just for Picketlink and create JIRA for me to adapt changes to MongoDB backend. I can also disable MongoDB unit tests by default (ATM I have them enabled by default in my branch) Marek > > Required: > > * Social Broker login with as many providers as possible. Minimally > Google and Facebook. > * SSO and SLO (Single Log Out) > * Password and TOTP login > * OAuth Client Grant support > * Example with apps using all o these features > * Keycloak website setup and finalized > * Online video walking through a demonstration of features > * Online video walking though how to configure it > * JBoss 7.1.x Community and JBoss EAP 6.1 support > > Knowing this there are two paths we can take. We can either include an > Admin UI in M1 or not. IMO, if we do *NOT* have an Admin UI for M1, we > probably need to not have registration or account management. Here's > what it might look like: > > Option #1: No Input UIs > > * A read-only XML/JSON file-based backend. Users must edit this to add > users, roles, etc... > * No Admin UI > * No Registration, forgotten passwords, account management. All these > require runtime updates to the database. > * What would we do about social though? As it requires registration? > > Work required (time estimates could take shorter or longer depending on > interruptions): > * 1-2 man-weeks to do file-based back-end > * 1-5 days to design the OAuth Grant Pages. > * 1 day to incorporate Grant pages > * Do we want fancier demo apps to show SSO and OAuth Grants? If so, > this is minimum 2 weeks. 1 to get Event Juggler hooked into Keycloak. > 1+ weeks to create another related SSO application. 1+ more to create > an OAuth application. > * 1 week to organize the Website and create demo videos. > * 1-2 weeks for documentation > * 1+ weeks to decide and implement how we're going to distribute > keycloak. Will it be a AS7 and/or EAP distro? A WAR? etc... > > So best case scenario is end of October. It would minimally require > myself and Gabriel. Others would be needed if we want fancier demo apps > as it is beyond my ability to create a nice looking demo app in a short > period of time. > > Option #2: UIs > > This would take a lot more work as we would need to finish up the admin, > registration, and account management UIs. I'd say Christmas time would > be a viable M1 release for this. This would require everybody. > > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

On 9/19/2013 4:28 AM, Marek Posolda wrote: > On 19.9.2013 03:11, Bill Burke wrote: >> We need to decide what we want to do for M1. Here's my stab at it. >> Let's discuss in email first as much as we can and then have a hangout >> sometime next week to go over it and nail things down. >> >> First and foremost. We have to focus. No new features. No playing >> around. For example: no adding refresh token support. No client-cert >> support. No changes to protocols. No new backends. Let's just use >> Picketlink JDBC. No 'forgot password' using SMS, etc... You get the >> picture. > At this moment, I have working MongoDB backend and I would like to send > PR with it by the end of this week. I just need to adapt this with > latest changes in RealmModel and UserModel interfaces (added new fields > related to requiredActions and totp). > > TBH I don't know why to not have it as part of M1? I am not seeing any > disadvantages for people to have possibility to choose from more > backends? Of course there is an advantage to Mongo et. al.! but there's a lot of work to do just to get a usable milestone release. We just have to focus on a minimal feature set to get the core done and playable to the outside world. Once we decide on our feature set for M1, you could help where needed, or you could just continue improving/expanding back-end support. Maybe moving to Mongo would be the way to go anyways considering the performance considerations? I need your input here.

> Another thing is that it is easier for people to see or edit > DB content directly in MongoDB database. Of course it's not so easy as > directly edit XML/JSON file, but much easier than Picketlink IDM DB > schema, which is quite complex. > > I am seeing just one disadvantage that every change in model interfaces > needs to be adapted to both backend implementations, but you can always > workaround this by implement stuff just for Picketlink and create JIRA > for me to adapt changes to MongoDB backend. I can also disable MongoDB > unit tests by default (ATM I have them enabled by default in my branch) > You might want to keep your backend in sync with master as I'll be needing to add features to the backend to support the management UI.

Bill

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-dev(a)lists.jboss.org Sent: Thursday, 19 September, 2013 2:11:18 AM Subject: [keycloak-dev] M1 release scope We need to decide what we want to do for M1. Here's my stab at it. Let's discuss in email first as much as we can and then have a hangout sometime next week to go over it and nail things down. First and foremost. We have to focus. No new features. No playing around. For example: no adding refresh token support. No client-cert support. No changes to protocols. No new backends. Let's just use Picketlink JDBC. No 'forgot password' using SMS, etc... You get the picture. Required: * Social Broker login with as many providers as possible. Minimally Google and Facebook. * SSO and SLO (Single Log Out) * Password and TOTP login * OAuth Client Grant support * Example with apps using all o these features * Keycloak website setup and finalized * Online video walking through a demonstration of features * Online video walking though how to configure it * JBoss 7.1.x Community and JBoss EAP 6.1 support Knowing this there are two paths we can take. We can either include an Admin UI in M1 or not. IMO, if we do *NOT* have an Admin UI for M1, we probably need to not have registration or account management. Here's what it might look like: Option #1: No Input UIs * A read-only XML/JSON file-based backend. Users must edit this to add users, roles, etc... * No Admin UI * No Registration, forgotten passwords, account management. All these require runtime updates to the database. * What would we do about social though? As it requires registration? Work required (time estimates could take shorter or longer depending on interruptions): * 1-2 man-weeks to do file-based back-end * 1-5 days to design the OAuth Grant Pages. * 1 day to incorporate Grant pages * Do we want fancier demo apps to show SSO and OAuth Grants? If so, this is minimum 2 weeks. 1 to get Event Juggler hooked into Keycloak. 1+ weeks to create another related SSO application. 1+ more to create an OAuth application. * 1 week to organize the Website and create demo videos. * 1-2 weeks for documentation * 1+ weeks to decide and implement how we're going to distribute keycloak. Will it be a AS7 and/or EAP distro? A WAR? etc... So best case scenario is end of October. It would minimally require myself and Gabriel. Others would be needed if we want fancier demo apps as it is beyond my ability to create a nice looking demo app in a short period of time. Option #2: UIs This would take a lot more work as we would need to finish up the admin, registration, and account management UIs. I'd say Christmas time would be a viable M1 release for this. This would require everybody. -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

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

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