[keycloak-dev] Need advice on bootstrapping Keycloak

[Stian Thorgersen]

Hi Stan,

Sorry for late reply, got lost in my todo list.

----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: "Stian Thorgersen" <stian at redhat.com>
> Cc: keycloak-dev at lists.jboss.org, "Juraci Paixão Kröhling" <jpkroehling at redhat.com>
> Sent: Friday, 25 July, 2014 7:01:04 PM
> Subject: Re: [keycloak-dev] Need advice on bootstrapping Keycloak
> 
> On 7/25/2014 8:34 AM, Stian Thorgersen wrote:
> > ----- Original Message -----
> >> From: "Stan Silvert" <ssilvert at redhat.com>
> >> To: keycloak-dev at lists.jboss.org, "Juraci Paixão Kröhling"
> >> <jpkroehling at redhat.com>
> >> Sent: Friday, 18 July, 2014 2:29:54 PM
> >> Subject: [keycloak-dev] Need advice on bootstrapping Keycloak
> >>
> >> Hi guys,
> >>
> >> My overall goal is to unite JBoss user-facing products via Keycloak
> >> SSO.  The first major task is make it as easy as possible to use
> >> Keycloak with the WildFly web console.  I have this working, but it
> >> takes quite a bit of setup.
> >>
> >> Ideally, there should be a simple switch in WildFly that says, "Use
> >> Keycloak for web console", and it all just works.
> >>
> >> So I'm looking for ideas on how to automate these setup tasks:
> >> * Deploy Keycloak auth server and keycloak-ds.xml
> > Is the plan eventually to deploy Keycloak as an extension instead of a WAR?
> > I reckon that would solve a fair amount of issues. Could even go as far as
> > creating KeycloakDS with a persistent H2 db from within the subsystem if
> > it's not available?
> Interesting idea.  What issues are you thinking this will solve?

If Keycloak is an extension rather than a WAR would we not be able to have all the modules there ready to go. Then there could be a simple one click button (maybe even in the WF console itself) to enable Keycloak, which would use DMR to enable the extension and also create the required datasource for KC.

It should also make it easier to update Keycloak as we could leverage the patching mechanism in WF right?

Our configuration mechanism (keycloak-server.json) is pluggable enough so that we could even make it possible to configure it through standalone.xml instead. Also, maybe we could leverage domains to manage a cluster of Keycloak nodes to make sure they all have the same config.

> >
> >> * Seed the database with an initial realm, user, roles, and two
> >> applications
> > What about defining a boostrap-realm.json file. We already have mechanisms
> > in place for importing a file at startup, which is only imported if the
> > realm doesn't already exist.
> How does the mechanism work?  I don't see the doco for it.  This might
> solve much of my problem.  But I need to let it generate new keys for
> the realm.  It should also generate a new secret for each application.
> Otherwise, everyone's installation would be the same.

At the moment you can either to it with a system property keycloak.import or servlet context-param keycloak.import.realm.resources to specify a json file with the contents of the realm and applications.

AeroGear guys use this to bootstrap their realm:

  https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/servers/auth-server/src/main/webapp/WEB-INF/web.xml#L9

Haven't tested this, but I believe it'll be done before the WAR is marked as deployed.

It generates new keys for the realm, but not for applications, but that's something we could add easily enough. Also I think it would be worth to make sure it only runs on the first time, at the moment it just checks to see if the realm is there. Would also be nice to be able to add some bootstrapping to the master realm as well with this mechanism (which obviously wouldn't work ATM due to it would just see the master realm and ignore it)

> 
> Can I get a callback to know when the import is complete?  After all
> that is done, I need to create the subsystem definitions for the
> applications.  So I have to query Keycloak to find out what the
> installation parameters are.  Is all that doable?
> >
> >> * Create keycloak.json files or populate keycloak subsystem for the two
> >> apps.
> > Would be cool if you had an option to automatically create Keycloak
> > subsystem definitions for apps as they're creating in KC. Could have some
> > sort of co-located option or something.
> Actually, you don't even need the co-located option.  It could issue a
> CLI command to any server that has a Keycloak subsystem.  Not only that,
> you could even deploy the WAR from Keycloak Admin if you wanted to.  But
> I don't think you want Keycloak to be in the business of managing
> deployments.
> 
> This is where true integration with our other tools comes in. Keycloak
> manages security.  Web Console and JON manage deployments. All three
> should work together.  So when I want to deploy something, I should be
> able to do all this from an integrated UI:
> * Scan the WAR to find out its roles.
> * Auto-populate Keycloak with the application and role definitions.
> * Auto-populate Keycloak with the application's Redirect URI, Base URL, etc.
> * Create the Keycloak subsystem entries
> * Decide which WildFly instances the app will be deployed to.
> * Upload and deploy the WAR

Sounds great, but will we ever be able to achieve an integrated UI at this level? A simpler solution may be to deploy a WAR in the standard way to WF. Then to go to a Keycloak WildFly extension UI to do the other steps you listed above.

> >
> >> Thanks in advance,
> >>
> >> Stan
> >> _______________________________________________
> >> keycloak-dev mailing list
> >> keycloak-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>
> 
>