[keycloak-dev] WildFly integration (READ ME!)
Stan Silvert
ssilvert at redhat.com
Thu Feb 19 08:50:03 EST 2015
I think most of the answers to Stian's questions depend on what Keycloak
is going to be. In other words, what is our strategy?
If we decide that the auth server is a strictly WildFly-based product
then the answer will always be "Do it the WildFly way". If we want the
auth server to run on other containers then we need to be a lot more
careful about cross-platform compatibility in everything we do.
I don't think the answer is to have a scaled-down version of the auth
server for other platforms. It's just too hard to constantly be
thinking about what is essentially two flavors of our product.
There definitely are advantages to being container agnostic. But I
think we need to decide this question and put a stake in the ground as
soon as possible. Then the answers will become clear.
On 2/19/2015 3:32 AM, Stian Thorgersen wrote:
> No comments?!
>
> ----- 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)
>>
>> * Keycloak CLI - Should we create our own or use WildFly CLI
>>
>> * 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?
>>
>> * 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 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
>>
>> * Split sub-systems - Should we split the sub-system in two? One for the
>> auth-server and another for the adapter
>>
>> * 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)
>>
>> 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
More information about the keycloak-dev
mailing list