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

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

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

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

More information about the keycloak-dev mailing list