[keycloak-user] Best practices for building appliances

Stan Silvert ssilvert at redhat.com
Mon Feb 2 08:11:28 EST 2015

Hi Juca,

I'm working on these exact issues right now.

The current plan is to build on top of WildFly CLI.  So you would be 
able to do most/all Keycloak API calls from there.  This will allow us 
to integrate more smoothly with WildFly and achieve some of our long 
term goals for both Keycloak and WildFly.

Your specific use case is one I've been thinking about along with a 
larger scope of requirements.   I think what will happen is that the 
Keycloak subsystem will be able to do your setup at deployment time and 
configure a secure-deployment in standalone.xml or domain.xml.   I 
already have some of the code for that.  It just uses a 
secure-deployment declared as a template and then adds Keycloak to any 
unsecured WAR at deployment time.

But it will also need to be able add the application in Keycloak, find 
the public key, and obtain the client secret.  That part is not done yet.

I think I need to put together a full plan for this and many other use 
cases where we need tighter WildFly integration.  Then I'll break it all 
down into tasks.  I'll get that done as soon as possible, but shoot for 
no later than Friday.  Would you be willing to help with some of the tasks?


On 2/2/2015 7:26 AM, Juraci Paixão Kröhling wrote:
> Hash: SHA1
> All,
> In our project, we plan to have a distribution where we ship our
> application with a Wildfly bundled, a la Keycloak Appliance.
> My main concern is shipping our distribution with a default pair of
> realm keys or with a pre-filled database. I know it's possible to
> import a realm on the first boot and KC will generate the required
> keys if they are missing from the imported JSON template, but as we
> are shipping our own WAR, we would need to get the public key into our
> application's keycloak.json (or subsystem) before it gets deployed.
> I wonder if this is a common situation and what would be the best
> practices for such case. I think Stian mentioned before that a future
> version of KC would allow auto registration of applications, but until
> that is available, I'd be interested in hearing your experiences about it.
> Another situation is for a contributor of the project or for users who
> would want to build from the source: what would be the best practice
> for generating new keys at each build? If there's no easy solution for
> that now, I'd be interested in building a "keycloak-cli" utility that
> would generate realm and application JSON files, possibly with a Maven
> plugin wrapper to make it easier to consume from maven projects. Would
> something like that be interesting for the project?
> Best,
> Juca.
> Version: GnuPG v1
> DT0PLdm9nMSzCJS23Auey4XSfk3YMxaGqve0yiEAstkfkro4AsPsvmQz1H/zyyUX
> csZduMlo8zzXox1n0uK8Mz95dnikSMD4MzAqXM3g8l3a7ORiw25Gg51REBMOJPUL
> YzX0qRQlEq+MDCJw/L0G5KUZWqmrCYy5GpJ8e3wibK/MzPg/vhs7KLgxr0jh8Eee
> gjlG/H4K37crDZrRE2ILGi7xV6GZYTw6AKgm03QFqt0/9HluJFcU9vPUs4JWMKfu
> O7Nf4qQ7OJWnVijepQ1Jdcg7uRnX1a019v0kbIZT3g6YSoYT6nCRow9kCEQ0DGo=
> =wYHW
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user

More information about the keycloak-user mailing list