Hi Stan,
Sorry for late reply, got lost in my todo list.
----- Original Message -----
From: "Stan Silvert" <ssilvert(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org, "Juraci Paixão Kröhling"
<jpkroehling(a)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(a)redhat.com>
>> To: keycloak-dev(a)lists.jboss.org, "Juraci Paixão Kröhling"
>> <jpkroehling(a)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/serve...
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(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>