[keycloak-dev] provisioning/bootstrapping/installing Keycloak

[Bolesław Dawidowicz]

+1

On 09/20/2013 12:19 PM, Stian Thorgersen wrote:
> 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
>>
> _______________________________________________ keycloak-dev mailing
> list keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>



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