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?

>>>> >>>> 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(a)redhat.com> >>>>>> To:keycloak-dev@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(a)redhat.com> >>>>>>>>>> To: "keycloak dev"<keycloak-dev(a)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(a)lists.jboss.org >>>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> keycloak-dev mailing list >>>>>>>>> keycloak-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>>>>>> _______________________________________________ >>>>>>> keycloak-dev mailing list >>>>>>> keycloak-dev(a)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(a)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(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list >>> keycloak-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

>Phone:404 941 4698 >Java is my crack.

----- Original Message ----- > From: "Summers Pittman" <supittma(a)redhat.com&gt; > To: "Stan Silvert" <ssilvert(a)redhat.com&gt; > Cc: keycloak-dev(a)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(a)redhat.com&gt; To: > keycloak-dev(a)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(a)redhat.com&gt; To: "keycloak dev" > <keycloak-dev(a)lists.jboss.org&gt; 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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list keycloak-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > _______________________________________________ > keycloak-dev mailing list keycloak-dev(a)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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list keycloak-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > _______________________________________________ > keycloak-dev mailing list keycloak-dev(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-dev

>Phone:404 941 4698 >Java is my crack.

----- Original Message ----- > From: "Summers Pittman" <supittma(a)redhat.com&gt; > To: "Stian Thorgersen" <stian(a)redhat.com&gt; > Cc: "Stan Silvert" <ssilvert(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org > Sent: Wednesday, February 25, 2015 1:52:50 PM > Subject: Re: [keycloak-dev] WildFly integration (READ ME!) > > On 02/25/2015 12:38 AM, Stian Thorgersen wrote: >> ----- Original Message ----- >>> From: "Summers Pittman" <supittma(a)redhat.com&gt; >>> To: "Stan Silvert" <ssilvert(a)redhat.com&gt; >>> Cc: keycloak-dev(a)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). > I understand you are trying to be glib, but there ARE issues with this. > First off getting a realm.json file OUT of a docker container is nigh > impossible, secondly the default configuration will lose all of your > data when it is restarted, and third on non Linux systems docker support > is pretty terrible. Data volumes do not work on Mac OS X out of the box > for example. I forgot irony doesn't translate well on email, sorry! The real answer was that we're probably going to provide an option to easily install Keycloak into an existing WildFly ;)

>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> 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(a)redhat.com&gt; To: >>> keycloak-dev(a)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(a)redhat.com&gt; To: "keycloak dev" >>> <keycloak-dev(a)lists.jboss.org&gt; 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list keycloak-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> _______________________________________________ >>> keycloak-dev mailing list keycloak-dev(a)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(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list keycloak-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>> >>> >>> >>> _______________________________________________ >>> keycloak-dev mailing list keycloak-dev(a)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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/keycloak-dev > > -- > Summers Pittman >>> Phone:404 941 4698 >>> Java is my crack. >

>Phone:404 941 4698 >Java is my crack.