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

Summers Pittman supittma at redhat.com
Tue Feb 24 10:45:17 EST 2015 

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.
>>>>>
>>>>> 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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150224/12b40437/attachment-0001.html

More information about the keycloak-dev mailing list