WildFly Elytron - Credential Store - Next Stages
by Darran Lofthouse
During WildFly 15 and WildFly 16 I am looking at the next stages for
credential store development based on a few feature requests we have not
handled yet.
We are at the stage where this development is likely to affect multiple
areas of the application server, additionally we need to consider these
requests as a set so we don't take a decision for one that prevents us
working on the remainder.
I have put together a blog post describing some of the general issues we
want to look into: -
http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next...
Some of these changes will have an impact on any subsystem currently
referencing the credential store.
Other changes we will need to decide if the solution lies within WildFly
Elytron, the management tier of the server, or the admin tools - or
possibly a combination of all three.
I am also going to share this link in the community forums to try and
obtain some additional feedback from end users.
Regards,
Darran Lofthouse.
5 years, 11 months
JDK 12 enters Rampdown Phase One
by Rory O'Donnell
Hi David & Richard,*
*
*JDK 12 Early Access build 22 **is now available **at : - jdk.java.net/12/*
* Per the JDK 12 schedule [1], we are now in Rampdown Phase One.
o For more details , see Mark Reinhold's email to jdk-dev mailing
list [2]
o The overall feature set is frozen, no further JEPs will be
targeted to this release.
o We’ve forked the main-line source repository, jdk/jdk, to the
JDK 12 stabilization repository.
Changes since the last availability email
* JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector
(Experimental) <http://openjdk.java.net/jeps/189> moved to *Targeted*.
* JEP 334: JVM Constants API <http://openjdk.java.net/jeps/334> moved
to *Targeted*.
* JEP 344: Abortable Mixed Collections for G1
<http://openjdk.java.net/jeps/344> moved to *Targeted*.
* JEP 346: Promptly Return Unused Committed Memory from G1
<http://openjdk.java.net/jeps/346> to *Targeted*.
* JEP 326: Raw String Literals <https://openjdk.java.net/jeps/326>
(Preview) *Proposed to drop from JDK 12*
o link to proposal on jdk-dev
<https://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002402.html>
Bug fixes reported by Open Source Projects :
o JDK-8211051 - fixed in b22 - reported by JUnit5
o JDK-8211422 - fixed in b23 - reported by Apache Batik
The Java Crypto Roadmap <https://java.com/cryptoroadmap> has been
updated with the following target:
* With the 2019-04-16 CPU,
o Targeted Releases - JDK 12, JDK 11, JDK 8, and JDK 7
o Distrust TLS server certificates anchored by Symantec Root CAs.
Oracle Java SE 8 Release Updates [3]
* Public updates for Oracle Java SE 8 released after January 2019 will
not be available for business, commercial or production use without
a commercial license.
Rgds, Rory
[1] http://openjdk.java.net/projects/jdk/12/#Schedule
[2] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-December/002405.html
[3] https://java.com/en/download/release_notice.jsp
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
5 years, 11 months
Wildfly layers
by 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
5 years, 11 months
