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

Wed Feb 25 08:08:56 EST 2015

On 02/25/2015 08:08 AM, Stian Thorgersen wrote:
>
> ----- Original Message -----
>> From: "Summers Pittman" <supittma at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: "Stan Silvert" <ssilvert at redhat.com>, keycloak-dev at 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 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).
>> 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 ;)
+1
>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>
>> --
>> Summers Pittman
>>>> Phone:404 941 4698
>>>> Java is my crack.
>>


-- 
Summers Pittman
>>Phone:404 941 4698
>>Java is my crack.