<div dir="ltr">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.<div><br></div><div>Regards,</div><div>Darran Lofthouse.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Nov 30, 2018 at 5:53 PM Jean-Francois Denise <<a href="mailto:jdenise@redhat.com">jdenise@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
here is an attempt to describe the galleon layers we could see exposed <br>
in order to build custom configurations. The way layers are provisioned <br>
by galleon make the provisioned server to be much smaller (in term of <br>
XML config and num of provisioned modules) than the default <br>
installation/configurations. We are here covering standalone kind of <br>
configuration.<br>
<br>
Feedbacks would be really welcome.<br>
<br>
I took the approach to not have layers to depend on legacy <br>
security-realms, we want elytron to be the way to go, so depending on <br>
these first place would create a maintainability issue. This does create <br>
some complexity when defining default configs, default config have to <br>
associate realms with management and subsystems to produce the default <br>
standalone configs we know. This complexity is not exposed.<br>
<br>
Each layer is "runnable", you can provision it and run it. Only common.* <br>
and standalone.* scripts are provisioned. Doesn't mean that running it <br>
alone makes sense.<br>
<br>
Any combination of layers should be valid.<br>
<br>
A layer brings its own dependencies and its XML configuration. Each <br>
subsystem (even server) is in charge to advertise to galleon what are <br>
the additional modules it is injecting or loading that should be <br>
provisioned but are not referenced from extension module. All the <br>
subsystems involved in the following layers have been updated to express <br>
these dependencies.<br>
<br>
Because Full layers are far from being defined, we could expect some <br>
adjustment.<br>
<br>
For core:<br>
<br>
Layers not bound to subsystems<br>
<br>
- base-server: root resource, pubic interface and socket binding. All <br>
layers depend at least on it.<br>
- management: unsecured management interface, management sockets, <br>
http-interface<br>
- secure-management: depends on management, configures elytron sasl <br>
authentication factory for management http interface<br>
- tools: all modules and tools script files (cli, add-user,...)<br>
- patching: patching modules.<br>
<br>
Layers bound to subsystems<br>
<br>
- core-management<br>
- deployment-scanner<br>
- discovery<br>
- elytron (brings openssl artifacts, openssl can't be used if elytron <br>
openssl provider is not configured.).<br>
- io<br>
- jmx<br>
- jmx-remoting: depends on jmx and configure remoting-connector. Depend <br>
on management (requires jboss.remoting.endpoint.management service)<br>
- logging<br>
- remoting: depends on io<br>
- request-controller<br>
- security-manager<br>
<br>
Aggregation Layer<br>
<br>
This layer defines a server with elytron secured management and all <br>
layers one would expect when running a core-server<br>
<br>
- core-server: depends on secure-management (brings elytron), <br>
jmx-remoting (brings jmx), logging, core-management, request-controller, <br>
security-manager.<br>
<br>
For servlet<br>
<br>
Layers not bound to subsystems<br>
<br>
- picketbox: A layer to brings picketbox module (and optional deps of <br>
picketbox present in servlet FP). Picketbox could be combined with some <br>
core layers without requiring the legacy security subsystem to be present.<br>
<br>
Layers bound to subsystems<br>
<br>
- ee: depends on naming<br>
- legacy-security (security sub-system): depends on naming and picketbox.<br>
- naming<br>
- undertow: depends on io and picketbox (to bring optional deps of <br>
picketbox, we still have hard dep on picketbox from <br>
security-negociation). This is a base undertow server, no security, no <br>
https-listener, empty servlet container (no support for servlet, jsp <br>
deployments). NB: welcome-content is not part of the layer, it is bring <br>
by the default configs. legacy default-security-domain "other" is also <br>
not configured, that is done in the default config too.<br>
- undertow-load-balancer: depends on io and picketbox. Undertow <br>
configured to act as a load-balancer.<br>
<br>
Web server layer<br>
<br>
This layer defines a server containing all layers one would expect when <br>
running an unsecure web-server. legacy-security is not included. In <br>
addition, this layer evolves undertow to be a full servlet-container <br>
(jsp, servlet, web-socket) and http-invoker.<br>
<br>
- web-server: ee (brings naming), deployment-scanner, undertow (brings <br>
picketbox and io)<br>
<br>
A note on combining layers.<br>
<br>
In order to evolve a web-server to become fully manageable, one would <br>
combine core-server (the management features) with web-server (web <br>
support).<br>
<br>
Because core layers are accessible from servlet FP, one could pick and <br>
choose from servlet FP to assemble his server. For example, a basic <br>
manageable unsecured (but ready to be configured for security) undertow <br>
server: undertow+management+elytron<br>
<br>
<br>
For full:<br>
<br>
We have identified an initial set of layers that would be the building <br>
blocks to help define cloud oriented configurations.<br>
<br>
Layers bound to subsystem:<br>
<br>
These layers depend (at least) on web-server (from servlet)<br>
<br>
- cdi: brings in weld and bean-validation<br>
- jaxrs<br>
- jpa: brings in hibernate default providers. In addition brings-in <br>
transactions, jca and infinispan (hibernate infinispan-cache).<br>
- activemq-jms: naked subsystem, no server configured. In addition <br>
brings-in transactions and jca<br>
- microprofile: opentracing, config, healths and metrics (last 2 depend <br>
on management).<br>
<br>
Layers that are simple extension of existing layers (would not appear as <br>
new layers but would extend content of servlet/core ones).<br>
<br>
- ee: add optional dependencies injected by dup present in full FP.<br>
- undertow: add undertow.js package.<br>
- tools: vault, jdr, wstools, appclient<br>
<br>
Aggregation layer<br>
<br>
- cloud-profile: contains cdi,jaxrs,jpa,activemq-jms,microprofile . All <br>
optionally included, allowing for exclusion (eg: exclude activemq-jms).<br>
<br>
<br>
Open questions<br>
<br>
SSL undertow<br>
<br>
As you noticed we don't have a layer for an SSL undertow. elytron <br>
doesn't offer an out of the box generation of self-signed certificate. <br>
Only legacy security realms offer this. So the way to go would be to <br>
provision undertow+elytron+management+tools (management+tools to use <br>
CLI), create the keystore, do the elytron configuration, add an <br>
https-listener, set the ssl-context, remove all the management related <br>
stuff from CLI. Then exclude the management+tools layers to get a <br>
smaller foot-print (tools bring a lot). NB: we could imagine that the <br>
CLI configuration is done from a provisioned server that contains tools <br>
so no need to provision tools with undertow.<br>
<br>
I am wandering if we should create an elytron SSL context that points to <br>
a "REPLACE_WITH_THE_PATH_TO_YOUR_KEYSTORE" kind of configuration to <br>
simplify configuration steps? I don't really like this idea to generate <br>
config that points to invalid artifacts but would simplify the <br>
configuration steps.<br>
<br>
Picketbox layer<br>
<br>
Because we want at some point to get rid-off this dependency, I am <br>
wandering if we should really define a layer for it. Could be that any <br>
dependency on it would imply the use of legacy-security layer. Picketbox <br>
is implicit when legacy-security layer is provisioned.<br>
<br>
Full layers granularity<br>
<br>
For now, we have included some major features (transactions, jca, <br>
infinispan) without making them layers. The layers that are depending on <br>
them are for the only consumers. When we progress with new layers, this <br>
would be revisited.<br>
<br>
Thank-you for having reached the end. ;-)<br>
<br>
JF<br>
<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div>