Re: [keycloak-dev] provisioning/bootstrapping/installing Keycloak

Initially I agree it would be simpler to have a single OpenShift instance per-organization. However, I still think there's a need for multiple realms even if it's for a single organization. For example there may be a realm used for testing/developement while another for production. There may also be distinct groups of applications that the organization wants to organize in separate realms, for example public applications and internal applications. In the future I believe developers/enterprise will expect full multi-tenancy support from middleware/servers. For MBaaS in the long run we'll need to have multiple organizations per instance as well. This obviously has impact on performance and security, but for a freebie version of MBaaS it should be greatly beneficial if we can share a single "cluster" of Keycloak. In this case we'll need to be able to cluster both Keycloak (if Keycloak was stateless that would be simpler) and the backing db (MongoDB should make this a lot simpler than PicketLink/relational). I'd also like to see proper support for collaboration to configure realms and applications. I'd imagine being able to "share" a realm with other users, and control what they can do. Maybe even the concept of an organization that "owns" one or more realms. For packaging Keycloak for M1 I would like to see: * Single zip installation - Includes WildFly, Keycloak and Keycloak console if ready. Sensible OOTB settings (including a realm for keycloak and a default realm for applications) so all a user would need to do is start it up, use the cli or console to register an application, then it should all be working * OpenShift - simple QuickStart for M1 (with a cartridge later), same as above where all that is required is to register application with a default realm to get started ----- Original Message ----- > From: "Bill Burke" <bburke(a)redhat.com&gt; To: > keycloak-dev(a)lists.jboss.org Sent: Friday, 20 September, 2013 > 12:33:32 AM Subject: [keycloak-dev] > provisioning/bootstrapping/installing Keycloak > > How will Keycloak be provisioned, bootstrapped, configured? How > will Keycloak look the first time somebody uses it? > > This are the questions I need answers to. > > We discussed earlier that a SaaS for identity is probably not a > good idea. For both security and performance reasons, Keycloak > should not support multitenancy between multiple accounts. For a > cloud environment, we will instead deploy Keycloak as a cartridge > for a specific Openshift account. > > How this effects the current code-base is that there would be no > SaaS login/registration pages. Another thing is, Stian correctly > suggested that the admin UI and admin REST services should be > deployed and secured by the token service as an Application under a > realm. Both of these things effect the design of the admin UI as > well as provisioning, installation, and bootstrapping > > Knowing this there are two routes we can take. > > Option #1: Multiple Realms per Keycloak Deployment (our current > codebase) Option #2: One Realm per Keycloak Deployment > > Let's talk about Option #2 because I think it has the potential to > make things really clean. From both a UI perspective and > installation/bootstrapping perspective. > > * The admin UI would be simplified as you would not have to have > buttons for creating realms or UI elements for switching between > realms. Since we want realm adminstration to be secured by the > realm itself, adding new realm admins is the same as managing any > other user in the system. If we allowed multiple realms per > keycloak deployment, then we would need the concept of a super user > and separate UI elements for managing them. > > * Installation/packaging Keycloak becomes simpler in the non-cloud > case. Keycloak would come pre-configured with a realm and a default > admin user for that realm with a known password. You would just > boot up Keycloak and try to login in. The admin user would force > the user to enter in a new password before they started using > Keycloak. > > * Provisioning on Openshift would also be simpler too, since the > realm name could map to a DNS name. myrealm-user.rhcloud.com > > One realm per deployment doesn't mean that we would model it in > the database that way. The data model would still support > multi-tenancy which means you could share a database between > Keycloak deployments. > > Thoughts? > > > -- 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 > _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev