[keycloak-dev] provisioning/bootstrapping/installing Keycloak

Bill Burke bburke at redhat.com
Fri Sep 20 09:17:56 EDT 2013


On 9/20/2013 6:19 AM, 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.
>

All this is great, but it may effect the design, deployment, and 
provisioning of the UI, it effects the data model, the token service, 
etc. This is the feature creep I've been worrying about and what would 
delay an M1 release.  I need to think a bit more on how all this would 
be implemented and what changes would need to be made considering that 
you also want the admin UI secured by the token service.

In particular, I need to figure out how an OAuth flow would work with 
realm adminstration.  For example,  MBaaS might want to interact with an 
existing realm to add and secure MBaaS appliation instances.  MBaaS 
server would act as a OAuth client to the realm.  It would redirect the 
user to login to the realm, an OAuth Grant Page would come up asking the 
user if it grants MBaaS permission to adminster the realm, browser would 
be forwared back to MBaaS and MBaaS would have a token it can use to 
interact with the Realm's REST services.

 
 


> 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

Wildfly isn't going to happen for the first release.  Its about 1-2 
weeks of work to integrate on top of something that is still in Alpha. 
  We're building on top of AS7/EAP 6.1 for M1.

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

You can't run Wildfly on Openshift last time I looked.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-dev mailing list