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

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

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

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

More information about the keycloak-dev mailing list