[keycloak-user] Best practices for building appliances

Wed Feb 4 07:43:53 EST 2015

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 at redhat.com>
>>> To: keycloak-user at 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 at redhat.com> 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 at kroehling.de>
>>>>> To: keycloak-user at 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.
>>>>>
>>>>> -----BEGIN PGP SIGNATURE-----
>>>>> Version: GnuPG v1
>>>>>
>>>>> iQEcBAEBAgAGBQJUz20DAAoJEDnJtskdmzLMbUYH/A0bclPFHI5FhL85lAXUrJ+a
>>>>> DT0PLdm9nMSzCJS23Auey4XSfk3YMxaGqve0yiEAstkfkro4AsPsvmQz1H/zyyUX
>>>>> csZduMlo8zzXox1n0uK8Mz95dnikSMD4MzAqXM3g8l3a7ORiw25Gg51REBMOJPUL
>>>>> YzX0qRQlEq+MDCJw/L0G5KUZWqmrCYy5GpJ8e3wibK/MzPg/vhs7KLgxr0jh8Eee
>>>>> gjlG/H4K37crDZrRE2ILGi7xV6GZYTw6AKgm03QFqt0/9HluJFcU9vPUs4JWMKfu
>>>>> O7Nf4qQ7OJWnVijepQ1Jdcg7uRnX1a019v0kbIZT3g6YSoYT6nCRow9kCEQ0DGo=
>>>>> =wYHW
>>>>> -----END PGP SIGNATURE-----
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>> _______________________________________________
>>>> keycloak-user mailing list
>>>> keycloak-user at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>> _______________________________________________
>>> keycloak-user mailing list
>>> keycloak-user at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user