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

Stan Silvert ssilvert at redhat.com
Mon Feb 23 12:23:29 EST 2015 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20150223/6fa9b9b6/attachment-0001.html

More information about the keycloak-dev mailing list