[wildfly-dev] Wildfly layers

[Jean-Francois Denise]

Hi,

here is an attempt to describe the galleon layers we could see exposed 
in order to build custom configurations. The way layers are provisioned 
by galleon make the provisioned server to be much smaller (in term of 
XML config and num of provisioned modules) than the default 
installation/configurations. We are here covering standalone kind of 
configuration.

Feedbacks would be really welcome.

I took the approach to not have layers to depend on legacy 
security-realms, we want elytron to be the way to go, so depending on 
these first place would create a maintainability issue. This does create 
some complexity when defining default configs, default config have to 
associate realms with management and subsystems to produce the default 
standalone configs we know. This complexity is not exposed.

Each layer is "runnable", you can provision it and run it. Only common.* 
and standalone.* scripts are provisioned. Doesn't mean that running it 
alone makes sense.

Any combination of layers should be valid.

A layer brings its own dependencies and its XML configuration. Each 
subsystem (even server) is in charge to advertise to galleon what are 
the additional modules it is injecting or loading that should be 
provisioned but are not referenced from extension module. All the 
subsystems involved in the following layers have been updated to express 
these dependencies.

Because Full layers are far from being defined, we could expect some 
adjustment.

For core:

Layers not bound to subsystems

- base-server: root resource, pubic interface and socket binding. All 
layers depend at least on it.
- management: unsecured management interface, management sockets, 
http-interface
- secure-management: depends on management, configures elytron sasl 
authentication factory for management http interface
- tools: all modules and tools script files (cli, add-user,...)
- patching: patching modules.

Layers bound to subsystems

- core-management
- deployment-scanner
- discovery
- elytron (brings openssl artifacts, openssl can't be used if elytron 
openssl provider is not configured.).
- io
- jmx
- jmx-remoting: depends on jmx and configure remoting-connector. Depend 
on management (requires jboss.remoting.endpoint.management service)
- logging
- remoting: depends on io
- request-controller
- security-manager

Aggregation Layer

This layer defines a server with elytron secured management and all 
layers one would expect when running a core-server

- core-server: depends on secure-management (brings elytron), 
jmx-remoting (brings jmx), logging, core-management, request-controller, 
security-manager.

For servlet

Layers not bound to subsystems

- picketbox: A layer to brings picketbox module (and optional deps of 
picketbox present in servlet FP). Picketbox could be combined with some 
core layers without requiring the legacy security subsystem to be present.

Layers bound to subsystems

- ee: depends on naming
- legacy-security (security sub-system): depends on naming and picketbox.
- naming
- undertow: depends on io and picketbox (to bring optional deps of 
picketbox, we still have hard dep on picketbox from 
security-negociation). This is a base undertow server, no security, no 
https-listener, empty servlet container (no support for servlet, jsp 
deployments). NB: welcome-content is not part of the layer, it is bring 
by the default configs. legacy default-security-domain "other" is also 
not configured, that is done in the default config too.
- undertow-load-balancer: depends on io and picketbox. Undertow 
configured to act as a load-balancer.

Web server layer

This layer defines a server containing all layers one would expect when 
running an unsecure web-server. legacy-security is not included. In 
addition, this layer evolves undertow to be a full servlet-container 
(jsp, servlet, web-socket) and http-invoker.

- web-server: ee (brings naming), deployment-scanner, undertow (brings 
picketbox and io)

A note on combining layers.

In order to evolve a web-server to become fully manageable, one would 
combine core-server (the management features) with web-server (web 
support).

Because core layers are accessible from servlet FP, one could pick and 
choose from servlet FP to assemble his server. For example, a basic 
manageable unsecured (but ready to be configured for security) undertow 
server: undertow+management+elytron


For full:

We have identified an initial set of layers that would be the building 
blocks to help define cloud oriented configurations.

Layers bound to subsystem:

These layers depend (at least) on web-server (from servlet)

- cdi: brings in weld and bean-validation
- jaxrs
- jpa: brings in hibernate default providers. In addition brings-in 
transactions, jca and infinispan (hibernate infinispan-cache).
- activemq-jms: naked subsystem, no server configured. In addition 
brings-in transactions and jca
- microprofile: opentracing, config, healths and metrics (last 2 depend 
on management).

Layers that are simple extension of existing layers (would not appear as 
new layers but would extend content of servlet/core ones).

- ee: add optional dependencies injected by dup present in full FP.
- undertow: add undertow.js package.
- tools: vault, jdr, wstools, appclient

Aggregation layer

- cloud-profile: contains cdi,jaxrs,jpa,activemq-jms,microprofile . All 
optionally included, allowing for exclusion (eg: exclude activemq-jms).


Open questions

SSL undertow

As you noticed we don't have a layer for an SSL undertow. elytron 
doesn't offer an out of the box generation of self-signed certificate. 
Only legacy security realms offer this. So the way to go would be to 
provision undertow+elytron+management+tools (management+tools to use 
CLI), create the keystore, do the elytron configuration, add an 
https-listener, set the ssl-context, remove all the management related 
stuff from CLI. Then exclude the management+tools layers to get a 
smaller foot-print (tools bring a lot). NB: we could imagine that the 
CLI configuration is done from a provisioned server that contains tools 
so no need to provision tools with undertow.

I am wandering if we should create an elytron SSL context that points to 
a "REPLACE_WITH_THE_PATH_TO_YOUR_KEYSTORE" kind of configuration to 
simplify configuration steps? I don't really like this idea to generate 
config that points to invalid artifacts but would simplify the 
configuration steps.

Picketbox layer

Because we want at some point to get rid-off this dependency, I am 
wandering if we should really define a layer for it. Could be that any 
dependency on it would imply the use of legacy-security layer. Picketbox 
is implicit when legacy-security layer is provisioned.

Full layers granularity

For now, we have included some major features (transactions, jca, 
infinispan) without making them layers. The layers that are depending on 
them are for the only consumers. When we progress with new layers, this 
would be revisited.

Thank-you for having reached the end. ;-)

JF