From: "Stan Silvert" <ssilvert(a)redhat.com&gt; To: keycloak-user(a)lists.jboss.org Sent: Monday, 2 February, 2015 2:11:28 PM Subject: Re: [keycloak-user] Best practices for building appliances 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?

Stan On 2/2/2015 7:26 AM, Juraci Paixão Kröhling wrote: > -----BEGIN PGP SIGNED MESSAGE----- > 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. > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

This is something that we need to figure out and find a proper solution for. It should be very easy for any JBoss project/product to both embed Keycloak and to use a centralized Keycloak for SSO. There are quite a few issues that needs resolving to achieve this properly: * Do we support embedding Keycloak in other containers than WildFly/EAP? * Do we provide a slimmed down version of Keycloak for embedding? An embedded Keycloak should be for securing the projects console in a simple deployment, not for a SSO solution. * How do we handle bootstrapping? Applications needs to configure themselves, including realm keys and application secrets. What happens if realm keys, application urls, etc change. * How do we provide a simple mechanism to link to a centralized Keycloak server * How do we make sure multiple projects can share the same Keycloak realm? Roles for example is a problem here if multiple projects use realm level roles (Keycloak itself does!) * How to enable SSL for a project? Keycloak is not secure without SSL! That's one of the downsides to bearer auth. Those issues (and probably a whole bunch more) should all be solved consistently for all JBoss projects. ----- Original Message ----- > From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; > To: keycloak-user(a)lists.jboss.org > Sent: Monday, 2 February, 2015 1:26:43 PM > Subject: [keycloak-user] Best practices for building appliances > > -----BEGIN PGP SIGNED MESSAGE----- > 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. > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

----- Original Message ----- > From: "Bob McWhirter" <bmcwhirt(a)redhat.com&gt; > To: keycloak-user(a)lists.jboss.org > Sent: Monday, 2 February, 2015 3:56:00 PM > Subject: Re: [keycloak-user] Best practices for building appliances > > fwiw— > > As a user, I enjoyed the -appliance download, but also wonder why it needs to > be based upon Wildfly, instead of maybe a smaller -appliance download based > upon just Undertow? As a user, would that be mainly the size of the download, or is there any other issues? Currently we depend on WildFly for SSL, datasources, Infinispan caches, startup script. We're discussing/considering tighter integration with WildFly in the future as there are more features we're adding which are dependent on the container such as client cert authentication, modules (classloader isolation for custom code), JEE support for providers, etc.. We may even go as far as using WildFly CLI and standalone/domain.xml.... We are considering a slimmed-down version of Keycloak to embed into other JBoss projects, but this will not be targeted at end-users. > -Bob > > > On Feb 2, 2015, at 9:42 AM, Stian Thorgersen <stian(a)redhat.com&gt; wrote: > >> This is something that we need to figure out and find a proper solution >> for. It should be very easy for any JBoss project/product to both embed >> Keycloak and to use a centralized Keycloak for SSO. >> >> There are quite a few issues that needs resolving to achieve this properly: >> >> * Do we support embedding Keycloak in other containers than WildFly/EAP? >> * Do we provide a slimmed down version of Keycloak for embedding? An >> embedded Keycloak should be for securing the projects console in a simple >> deployment, not for a SSO solution. >> * How do we handle bootstrapping? Applications needs to configure >> themselves, including realm keys and application secrets. What happens if >> realm keys, application urls, etc change. >> * How do we provide a simple mechanism to link to a centralized Keycloak >> server >> * How do we make sure multiple projects can share the same Keycloak realm? >> Roles for example is a problem here if multiple projects use realm level >> roles (Keycloak itself does!) >> * How to enable SSL for a project? Keycloak is not secure without SSL! >> That's one of the downsides to bearer auth. >> >> Those issues (and probably a whole bunch more) should all be solved >> consistently for all JBoss projects. >> >> ----- Original Message ----- >>> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; >>> To: keycloak-user(a)lists.jboss.org >>> Sent: Monday, 2 February, 2015 1:26:43 PM >>> Subject: [keycloak-user] Best practices for building appliances >>> >>> -----BEGIN PGP SIGNED MESSAGE----- >>> 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. >>> >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user

On 2/4/2015 3:32 AM, Marek Posolda wrote: > My take is to be ideally as much independent on Wildfly as possible. > Each dependent feature might cause issues with portability and migration. > > For example if we tightly integrate with Wildfly CLI and Wildfly 10 > would come with "New uber-cool CLI v 1.0", which won't be compatible > with previous CLI, we would need to rewrite our CLI operations or > provide abstraction/SPI to be able to run on all of Wildfly 8,9,10. Very, very, very unlikely. The whole EAP customer base would revolt. DMR/CLI was written for extreme backward compatibility.

Even when something changes for a subsystem in standalone.xml the parser can still read old standalone.xml files and act accordingly. We are allowed to break backward compatibility in major versions, but I don't think we've done that since JBoss AS 7. > It looks to me that earlier or later, we would need to provide > auth-server WAR, which will run on Jetty, Tomcat etc. Currently it's not > hard to have auth-server running on those (as recently proven by > coolmind182006 and his blogpost). Would be nice to keep it like that. > > Marek > > On 2.2.2015 16:18, Stian Thorgersen wrote: >> ----- Original Message ----- >>> From: "Bob McWhirter" <bmcwhirt(a)redhat.com&gt; >>> To: keycloak-user(a)lists.jboss.org >>> Sent: Monday, 2 February, 2015 3:56:00 PM >>> Subject: Re: [keycloak-user] Best practices for building appliances >>> >>> fwiw— >>> >>> As a user, I enjoyed the -appliance download, but also wonder why it needs to >>> be based upon Wildfly, instead of maybe a smaller -appliance download based >>> upon just Undertow? >> As a user, would that be mainly the size of the download, or is there any other issues? >> >> Currently we depend on WildFly for SSL, datasources, Infinispan caches, startup script. We're discussing/considering tighter integration with WildFly in the future as there are more features we're adding which are dependent on the container such as client cert authentication, modules (classloader isolation for custom code), JEE support for providers, etc.. We may even go as far as using WildFly CLI and standalone/domain.xml.... >> >> We are considering a slimmed-down version of Keycloak to embed into other JBoss projects, but this will not be targeted at end-users. >> >>> -Bob >>> >>> >>> On Feb 2, 2015, at 9:42 AM, Stian Thorgersen <stian(a)redhat.com&gt; wrote: >>> >>>> This is something that we need to figure out and find a proper solution >>>> for. It should be very easy for any JBoss project/product to both embed >>>> Keycloak and to use a centralized Keycloak for SSO. >>>> >>>> There are quite a few issues that needs resolving to achieve this properly: >>>> >>>> * Do we support embedding Keycloak in other containers than WildFly/EAP? >>>> * Do we provide a slimmed down version of Keycloak for embedding? An >>>> embedded Keycloak should be for securing the projects console in a simple >>>> deployment, not for a SSO solution. >>>> * How do we handle bootstrapping? Applications needs to configure >>>> themselves, including realm keys and application secrets. What happens if >>>> realm keys, application urls, etc change. >>>> * How do we provide a simple mechanism to link to a centralized Keycloak >>>> server >>>> * How do we make sure multiple projects can share the same Keycloak realm? >>>> Roles for example is a problem here if multiple projects use realm level >>>> roles (Keycloak itself does!) >>>> * How to enable SSL for a project? Keycloak is not secure without SSL! >>>> That's one of the downsides to bearer auth. >>>> >>>> Those issues (and probably a whole bunch more) should all be solved >>>> consistently for all JBoss projects. >>>> >>>> ----- Original Message ----- >>>>> From: "Juraci Paixão Kröhling" <juraci(a)kroehling.de&gt; >>>>> To: keycloak-user(a)lists.jboss.org >>>>> Sent: Monday, 2 February, 2015 1:26:43 PM >>>>> Subject: [keycloak-user] Best practices for building appliances >>>>> >>>>> -----BEGIN PGP SIGNED MESSAGE----- >>>>> 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. >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> _______________________________________________ >>> keycloak-user mailing list >>> keycloak-user(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>> >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user