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

[Bill Burke]

On 2/3/2015 4:08 AM, Stian Thorgersen wrote:
> 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.
>

Dropping and deprecating things all depends on if we want Keycloak 
usable outside of Wildfly/EAP.

> The list of things to discuss includes:
>
> * Drop keycloak-server.json - Should we drop our own configuration file and use DMR (standalone.xml)
>

For adapters we support both a .json config and DMR.  We should do the 
same for keycloak-server.json.  Our testsuite depends on 
keycloak-server.json anyways.


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

IMO, DMR sux.  It is a lot of boilerplate code to support.  Remember 
also the admin console uses the REST interface.

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

As per our discussions today.  IMO Community should be this:
* Wildfly appliance
* EAP zip and/or installer to install Keycloak on top of EAP 6.x and 
7.x.  We can't distribute EAP, but customers may want to use community 
on EAP to use newer features.
* private WAR bundle Quickstart repo
* Individual adapter downloads.  This is great because we can see what 
people are using.

> * How should we deal with providers, themes and keycloak-server.json in domain-mode
>

There's some other requirements coming down the pipe.  For example, RHT 
IT needs to add a "Terms and Conditions" click through when logging in. 
  We'll want to support custom workflows.  This may all fall under 
deployable themes though.

> * MSC all the way - We can deploy directly through the Undertow sub-system instead of deploying a WAR from the sub-system
>

Definitely doable.

> * Split sub-systems - Should we split the sub-system in two? One for the auth-server and another for the adapter
>

YES!

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

As discussed earlier we have a private WAR bundle Quickstart repo.




-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com