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(a)redhat.com>
>>>>>> To:keycloak-dev@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(a)redhat.com>
>>>>>>>>>> To: "keycloak
dev"<keycloak-dev(a)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(a)lists.jboss.org
>>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> keycloak-dev mailing list
>>>>>>>>> keycloak-dev(a)lists.jboss.org
>>>>>>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>>> _______________________________________________
>>>>>>> keycloak-dev mailing list
>>>>>>> keycloak-dev(a)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(a)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(a)lists.jboss.org
>>>>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/keycloak-dev
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev >Phone:404 941 4698
>Java is my crack.