[keycloak-dev] provisioning/bootstrapping/installing Keycloak

[Stian Thorgersen]

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 at redhat.com>
> To: keycloak-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>