<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">On 2/23/2015 12:06 PM, Summers Pittman
      wrote:<br>
    </div>
    <blockquote cite="mid:54EB5E2D.2070508@redhat.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 02/23/2015 11:09 AM, Stan Silvert
        wrote:<br>
      </div>
      <blockquote cite="mid:54EB50A8.6050702@redhat.com" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">On 2/23/2015 10:42 AM, Summers
          Pittman wrote:<br>
        </div>
        <blockquote cite="mid:54EB4A5B.6040201@redhat.com" type="cite">
          <meta http-equiv="content-type" content="text/html;
            charset=windows-1252">
          <div class="moz-cite-prefix">On 02/23/2015 09:50 AM, Stian
            Thorgersen wrote:<br>
          </div>
          <blockquote
            cite="mid:704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com"
            type="cite">
            <pre wrap="">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.</pre>
          </blockquote>
          If I'm reading you correctly instead of <br>
          <br>
          <blockquote><tt>~/WILDFLY_HOME/bin/startup.sh</tt><br>
            <tt>code</tt><br>
          </blockquote>
          <br>
          it will be <br>
          <p><tt><br>
            </tt></p>
          <blockquote><tt>$WILDFLY_HOME/bin/startup.sh</tt><br>
            <tt>code</tt><br>
            <tt>#^@%! what broke in my auth</tt><br>
            <tt>waste 10 minutes</tt><br>
            <tt>$KEYCLOAK_HOME/bin/startup.sh</tt><br>
          </blockquote>
        </blockquote>
        I don't understand.  What would break?<br>
      </blockquote>
      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.  <br>
      <blockquote cite="mid:54EB50A8.6050702@redhat.com" type="cite">
        <blockquote cite="mid:54EB4A5B.6040201@redhat.com" type="cite">
          <blockquote> </blockquote>
          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.  <br>
        </blockquote>
        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?<br>
      </blockquote>
      My reading of the original email was that the standalone server
      would be the only distribution.  IE there would be no more warfile
      distribution.<br>
    </blockquote>
    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. <br>
    <br>
    You could still deploy your applications to the Keycloak
    distribution.  But for production, that's probably not what you
    want.<br>
    <br>
    What I don't understand is what problems it would cause.  Can you
    elaborate on that?<br>
    <blockquote cite="mid:54EB5E2D.2070508@redhat.com" type="cite">
      <blockquote cite="mid:54EB50A8.6050702@redhat.com" type="cite">
        <blockquote cite="mid:54EB4A5B.6040201@redhat.com" type="cite">
          <br>
          Again, IF I'm reading your message correctly<br>
          <br>
          <blockquote
            cite="mid:704793002.13480640.1424703042016.JavaMail.zimbra@redhat.com"
            type="cite">
            <pre wrap="">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 -----
</pre>
            <blockquote type="cite">
              <pre wrap="">From: "Summers Pittman" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:supittma@redhat.com">&lt;supittma@redhat.com&gt;</a>
To: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
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:
</pre>
              <blockquote type="cite">
                <pre wrap="">On 2/20/2015 10:05 AM, Summers Pittman wrote:
</pre>
                <blockquote type="cite">
                  <pre wrap="">On 02/19/2015 03:32 AM, Stian Thorgersen wrote:
</pre>
                  <blockquote type="cite">
                    <pre wrap="">No comments?!
</pre>
                  </blockquote>
                  <pre wrap="">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.
</pre>
                </blockquote>
                <pre wrap="">Thanks Summers.  Very valuable feedback.
</pre>
              </blockquote>
              <pre wrap="">Thanks for taking the time to explain some things I know more than I did
this morning.
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <pre wrap="">----- Original Message -----
</pre>
                    <blockquote type="cite">
                      <pre wrap="">From: "Stian Thorgersen" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:stian@redhat.com">&lt;stian@redhat.com&gt;</a>
To: "keycloak dev" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E" href="mailto:keycloak-dev@lists.jboss.org">&lt;keycloak-dev@lists.jboss.org&gt;</a>
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)
</pre>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">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
</pre>
                </blockquote>
                <pre wrap="">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.
</pre>
              </blockquote>
              <pre wrap="">Ah, that makes more sense.
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre wrap="">* Keycloak CLI - Should we create our own or use WildFly CLI
</pre>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">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.
</pre>
                </blockquote>
                <pre wrap="">That's the general feedback we often get from the WildFly community.  I
agree.
</pre>
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre wrap="">* 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?
</pre>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">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)?
</pre>
                </blockquote>
                <pre wrap="">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.
</pre>
                <blockquote type="cite">
                  <pre wrap="">In my experience I don't LIKE using the WildFly admin UI, I would rather
use the CLI, scripts, etc.
</pre>
                </blockquote>
                <pre wrap="">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.
</pre>
                <blockquote type="cite">
                  <pre wrap="">I haven't used the KeyCloak REST endpoints
and keeping them just increases the attack surface.
</pre>
                </blockquote>
                <pre wrap="">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?
</pre>
              </blockquote>
              <pre wrap="">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.
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre wrap="">* 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
</pre>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">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.
</pre>
                </blockquote>
                <pre wrap="">Good feedback.
</pre>
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre wrap="">* 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
</pre>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">What is MSC?
</pre>
                </blockquote>
                <pre wrap="">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.
</pre>
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre wrap="">* Split sub-systems - Should we split the sub-system in two? One for the
auth-server and another for the adapter
</pre>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">What are the trade offs?  What will using KeyCloak look like from my POV
if we split?
</pre>
                </blockquote>
                <pre wrap="">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.
</pre>
              </blockquote>
              <pre wrap="">As a end user it sounds like both work for me.
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre wrap="">* 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)
</pre>
                    </blockquote>
                  </blockquote>
                  <pre wrap="">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.
</pre>
                </blockquote>
                <pre wrap="">I could have done without that image. :-|

But thanks again!
</pre>
              </blockquote>
              <pre wrap="">YW.
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <blockquote type="cite">
                    <blockquote type="cite">
                      <pre wrap="">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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>

</pre>
                    </blockquote>
                    <pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>
</pre>
                  </blockquote>
                </blockquote>
                <pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>
</pre>
              </blockquote>
              <pre wrap="">--
Summers Pittman
</pre>
              <blockquote type="cite">
                <blockquote type="cite">
                  <pre wrap="">Phone:404 941 4698
Java is my crack.
</pre>
                </blockquote>
              </blockquote>
              <pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a>

</pre>
              <br>
              <br>
            </blockquote>
          </blockquote>
          <br>
          <br>
          <br>
          <pre class="moz-signature" cols="72">-- 
Summers Pittman
&gt;&gt;Phone:404 941 4698
&gt;&gt;Java is my crack.
</pre>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
        </blockquote>
        <br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
keycloak-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:keycloak-dev@lists.jboss.org">keycloak-dev@lists.jboss.org</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/keycloak-dev">https://lists.jboss.org/mailman/listinfo/keycloak-dev</a></pre>
      </blockquote>
      <br>
      <br>
      <pre class="moz-signature" cols="72">-- 
Summers Pittman
&gt;&gt;Phone:404 941 4698
&gt;&gt;Java is my crack.
</pre>
    </blockquote>
    <br>
  </body>
</html>