6:52 p.m.
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.
> ----- 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.
>> * 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?
>> * 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.
>> * 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!
>> 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