[keycloak-dev] WildFly integration (READ ME!)
Stian Thorgersen
stian at redhat.com
Wed Feb 25 00:38:19 EST 2015
----- Original Message -----
> From: "Summers Pittman" <supittma at redhat.com>
> To: "Stan Silvert" <ssilvert at redhat.com>
> Cc: keycloak-dev at lists.jboss.org
> Sent: Tuesday, February 24, 2015 4:45:17 PM
> Subject: Re: [keycloak-dev] WildFly integration (READ ME!)
>
> On 02/23/2015 12:26 PM, Stan Silvert wrote:
>
>
>
> On 2/23/2015 12:23 PM, Stan Silvert wrote:
>
>
>
> On 2/23/2015 12:06 PM, Summers Pittman wrote:
>
>
>
> On 02/23/2015 11:09 AM, Stan Silvert wrote:
>
>
>
> On 2/23/2015 10:42 AM, Summers Pittman wrote:
>
>
>
> On 02/23/2015 09:50 AM, Stian Thorgersen wrote:
>
>
>
> 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.
> If I'm reading you correctly instead of
>
>
>
> ~/WILDFLY_HOME/bin/startup.sh
> code
>
> it will be
>
>
>
>
>
> $WILDFLY_HOME/bin/startup.sh
> code
> #^@%! what broke in my auth
> waste 10 minutes
> $KEYCLOAK_HOME/bin/startup.sh
> I don't understand. What would break?
> I start developing after a reboot and KeyCloak's server isn't running. The
> auth is broken because the server isn't running because I forgot to start
> it.
> Sorry. Missed this response. My question to you is would having the ability
> to deploy your app on the Keycloak distribution be sufficient?
> No. I already have a Wildfly server which is part of my development process
> that I know how to deploy things to. I don't want to set up a second one.
>
> If getting a deployable package is not an option and the only solution that
> is being entertained is a stand alone app server I will just containerize
> the thing, give it a host name alias and forget about it.
# docker run jboss/keycloak
That being said we may provide the option to install Keycloak into an existing WildFly (we'll probably only support the last version available at the time we release).
>
>
>
>
>
>
>
>
>
>
>
>
> By keeping it a separate war 1) I can download the thing faster and 2) I
> don't have to decide who to kick off of port 8080.
> I don't think we would do anything to ban you from deploying your apps in the
> same WildFly instance as Keycloak. Can you explain your concerns in more
> detail?
> My reading of the original email was that the standalone server would be the
> only distribution. IE there would be no more warfile distribution.
> Right. But it would be a distribution that has two modes. The modes would be
> standalone mode and a mode that would allow it to join a WildFly domain.
>
> You could still deploy your applications to the Keycloak distribution. But
> for production, that's probably not what you want.
>
> What I don't understand is what problems it would cause. Can you elaborate on
> that?
>
>
>
>
>
>
>
> Again, IF I'm reading your message correctly
>
>
>
>
> 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
>
>
>
>
>
> --
> 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
>
>
>
> _______________________________________________
> 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
>
>
>
> _______________________________________________
> 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
More information about the keycloak-dev
mailing list