[keycloak-user] Best practices for building appliances

[Stian Thorgersen]

----- 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
>