[wildfly-dev] Wildfly layers

[Darran Lofthouse]

FYI out of the box SSL with WildFly Elytron is one of the high priority on
our roadmap, after the 10th December we should be able to discuss this one
a little further with you.

Regards,
Darran Lofthouse.


On Fri, Nov 30, 2018 at 5:53 PM Jean-Francois Denise <jdenise at redhat.com>
wrote:

> 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
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181130/c3db606d/attachment-0001.html