[keycloak-dev] WildFly integration (READ ME!)

Mon Feb 23 09:50:42 EST 2015

Just to clarify we're only talking about the server, not adapters.

For the best and most friction free experience it would be best to have a dedicated Keycloak server, not to co-locate it with your JEE apps by deploying a WAR. With that regards we are considering dropping support for deploying Keycloak as a WAR.

That being said we still need to support embedding Keycloak in other projects. We plan to continue to support this through the mechanism UPS does, basically build-your-own auth-server.war.

----- Original Message -----
> From: "Summers Pittman" <supittma at redhat.com>
> To: keycloak-dev at lists.jboss.org
> Sent: Friday, February 20, 2015 7:10:12 PM
> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
> 
> On 02/20/2015 12:52 PM, Stan Silvert wrote:
> > On 2/20/2015 10:05 AM, Summers Pittman wrote:
> >> On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
> >>> No comments?!
> >> Peanut gallery chiming in; you asked for it ;)
> >>
> >> I am not a WildFly developer or administrator.  So read this email as
> >> the opinions of a talented developer who loves the hell out of using
> >> KeyCloak and WildFly and sings its praises from the roof tops but has no
> >> idea what you are talking about.
> > Thanks Summers.  Very valuable feedback.
> Thanks for taking the time to explain some things I know more than I did
> this morning.
> >>> ----- Original Message -----
> >>>> From: "Stian Thorgersen" <stian at redhat.com>
> >>>> To: "keycloak dev" <keycloak-dev at lists.jboss.org>
> >>>> Sent: Tuesday, February 3, 2015 10:08:50 AM
> >>>> Subject: [keycloak-dev] WildFly integration (READ ME!)
> >>>>
> >>>> All,
> >>>>
> >>>> We have a few decisions to make in the not so far future. I'm away from
> >>>> Thursday, so let's have a hangout when I get back on the 17th February
> >>>> if
> >>>> that works for everyone.
> >>>>
> >>>> The list of things to discuss includes:
> >>>>
> >>>> * Drop keycloak-server.json - Should we drop our own configuration file
> >>>> and
> >>>> use DMR (standalone.xml)
> >> If on day one enabling KeyCloak in my project was any more complicated
> >> than dropping a pregenerated file into my WEB-INF directory I would have
> >> closed the project and never looked back.  -1
> > We're talking about the auth server's config rather than the config for
> > your project.   For projects, we want to make it even easier to the
> > point where you don't even need the json file to get a default
> > configuration.
> Ah, that makes more sense.
> >>>> * Keycloak CLI - Should we create our own or use WildFly CLI
> >> On the one hand the wildfly CLI is black magic.  On the other hand it is
> >> really well done black magic.  It is very hard to do CLIs well so I
> >> would like to see the wildfly CLI be used.
> > That's the general feedback we often get from the WildFly community.  I
> > agree.
> >>>> * Admin operations exposed over DMR - Should we expose none, some or all
> >>>> admin operations over DMR? If we expose all should we deprecate the
> >>>> current
> >>>> REST endpoints?
> >> Is DMR the thing that puts stuff in the WildFly admin UI (I tried to
> >> read the google result for "wildfly DMR" but it quickly turned into
> >> turtles all the way down)?
> > At its core, DMR is really just a tiny single-package library where the
> > API is just 3 or 4 classes.  Those classes are the "language" spoken to
> > make changes to the WildFly management model
> > (standalone.xml/domain.xml).  So the question is whether we should hook
> > into the management model infrastructure to make Keycloak changes.
> >> In my experience I don't LIKE using the WildFly admin UI, I would rather
> >> use the CLI, scripts, etc.
> > Also a typical response.  Again, I agree.  Thankfully, the Keycloak
> > admin UI doesn't suffer from the same deficiencies as the WildFly admin UI.
> >
> > But with Keycloak, we don't yet have a CLI, so there are lots of
> > questions around whether we piggyback on WildFly CLI, which means
> > adopting DMR in some way.
> >> I haven't used the KeyCloak REST endpoints
> >> and keeping them just increases the attack surface.
> > Do you mean that keeping the REST endpoints would be a good thing or a
> > bad thing?  Can we hear more from you on this topic?
> I think that if there were a WildFly way to do all of the admin tasks
> that the RESTful endpoints do now it would be good to remove the RESTful
> API to decrease the API surface to just WildFly.  IE fewer things to
> worry about getting hacked and to watch for for vulnerabilities.
> >>>> * Packaging/distribution - How do we distribute Keycloak? Options:
> >>>>      - Full WildFly
> >>>>      - Core/web WildFly
> >>>>      - Overlay/installer/feature-pack to install to existing WF and EAP
> >>>>      - WAR bundle
> >> How about a shell script that examines a WF install directory and does
> >> all the magic for me or aDocker container?
> >>
> >> In general I have not liked the experience of having wildfly bundled
> >> with a product.  It tends to mess with other servers I have installed
> >> and be a general PITA to maintain for anything more than the most
> >> trivial of demos.
> > Good feedback.
> >>>> * How should we deal with providers, themes and keycloak-server.json in
> >>>> domain-mode
> >>>>
> >>>> * MSC all the way - We can deploy directly through the Undertow
> >>>> sub-system
> >>>> instead of deploying a WAR from the sub-system
> >> What is MSC?
> > Modular Service Container.  It's the thing that lets you declare and
> > register services in WildFly.  But I'm not completely sure what Stian is
> > proposing here.
> >>>> * Split sub-systems - Should we split the sub-system in two? One for the
> >>>> auth-server and another for the adapter
> >> What are the trade offs?  What will using KeyCloak look like from my POV
> >> if we split?
> > Instead of
> >
> > subsystem=keycloak/auth-server=main-auth-server
> > subsystem=keycloak/secure-deployment=foo
> >
> > you would have
> >
> > subsystem=keycloak-server/auth-server=main-auth-server
> > subsystem=keycloak-deployments/secure-deployment=foo
> >
> > Another option would be to just leave it as it is today and just hide
> > the "auth-server" resource for installations where you don't expect the
> > auth server to run.
> >
> > The answer will probably be more a function of how we want to organize
> > the code rather than how it will look to the end user.
> As a end user it sounds like both work for me.
> >>>> * Deployable to other containers - Should it be possible to deploy
> >>>> Keycloak
> >>>> to Tomcat, Jetty, Fuse, etc..? One option could be to have reduced
> >>>> features
> >>>> in other containers (for example no client-cert)
> >> The awesomeness of WildFly has forever made web containers look
> >> insignificant to me.  If Glassfish still had a community edition worth a
> >> damn I would say target it as well.  I don't know how TomEE is but that
> >> may be good to support just for a "first one's free" to get people into
> >> WildFly land.
> >>
> >> I don't think Websphere or WebLogic support has ever gotten anyone
> >> excited about a project.  Honestly they are the technology equivalent of
> >> taking a cold shower with grandma.
> > I could have done without that image. :-|
> >
> > But thanks again!
> YW.
> >>>> Please add any other relevant topics.
> >>>>
> >>>> Next big discussion I want to have is about distribution of adapters,
> >>>> but
> >>>> let's do one at a time ;)
> >>>> _______________________________________________
> >>>> keycloak-dev mailing list
> >>>> keycloak-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> >>>>
> >>> _______________________________________________
> >>> keycloak-dev mailing list
> >>> keycloak-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> > _______________________________________________
> > keycloak-dev mailing list
> > keycloak-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 
> 
> --
> Summers Pittman
> >>Phone:404 941 4698
> >>Java is my crack.
> 
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
> 