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
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
WildFly 15 frozen
by Kabir Khan
Hi all,
The WildFly master branch is now frozen until we release WildFly
15.0.0.Final. We need to sync up with Jason, but I expect it to be released
today or over the weekend.
Thanks,
Kabir
5 years, 11 months
Re: [wildfly-dev] Opentracing extension in WFLY - EAR + Weld Probe
by Matej Novotny
Thanks for your response.
I'll send a PR soon as I can get to it.
Matej
----- Original Message -----
> From: "Juraci Paixão Kröhling" <jpkroehling(a)redhat.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>, "WildFly Dev" <wildfly-dev(a)lists.jboss.org>
> Cc: "Martin Kouba" <mkouba(a)redhat.com>, "Nikoleta Ziakova" <nziakova(a)redhat.com>
> Sent: Thursday, November 29, 2018 1:52:03 PM
> Subject: Re: Opentracing extension in WFLY - EAR + Weld Probe
>
> On 11/28/18 1:31 PM, Matej Novotny wrote:
> > during recent Weld release a noticed that one of Weld examples stopped
> > working on WFLY 14.
>
> WF14 shipped with a bug that prevented the subsystem from working properly:
> https://issues.jboss.org/browse/WFLY-10961
>
> I don't think it affects your examples, though.
>
> > Looking at opentracing extension, why are there no dependencies added to
> > the root of EAR[4]?
> > For the record I did try removing that 'if' statement and then executing
> > test[5] related to the PR in which it was added and it passed (and solved
> > my deployment problem as well).
> > If the above approach is fine, I can create JIRA and send a PR, I just
> > wanted to check with someone who has more knowledge about that opentracing
> > extension than I do.
>
> I trust your judgment on how it should look like. As long as the tests
> are passing, I'd say that it's OK to change.
>
> IIRC, we needed this conditional statement because we need each
> subdeployment to have its own tracer instance. If you are saying that we
> can get this scenario without that conditional, please do change it :)
>
> - Juca.
>
5 years, 11 months
wildfly14 JMS security config question
by Marlow, Andrew
Hello everyone,
I am trying to disable JMS security in wildfly14 with activemq but can't see how to do it. Googling, I find the advice: add "<security enabled="false"/> to your config but whereabouts should it be added? I tried immediately after <subsystem xmlns="urn:jboss:domain:messaging-activemq:4.0"> but this gave WFLYCTL0085: Failed to parse configuration.
BTW the problem I am trying to solve is user null does not have permission='consume' on address. This is despite me having
<server name="default">
<security-setting name="#">
<role name="guest" send="true" consume="true" create-non-durable-queue="true" delete-non-durable-queue="true"/>
</security-setting>
in my config.
Andrew Marlow
Consultant developer, Apex
38th Floor, 25 Canada Square,
Canary Wharf, London E14 5LQ
T: 020-8081-2367 / 07966-451-521
E: andrew.marlow(a)fisglobal.com<mailto:andrew.marlow@fisglobal.com>
FIS | Empowering the Financial World [cid:image001.png@01D112FA.C4A77D90] <https://www.facebook.com/FIStoday> [cid:image002.png@01D112FA.C4A77D90] <https://twitter.com/FISGlobal> [cid:image003.png@01D112FA.C4A77D90] <https://www.linkedin.com/company/fis>
FIS Apex (UK) Limited * Registered in England and Wales No. 3573008 * Registered Office: 38th floor, 25 Canada Square, London, E14 5LQ, United Kingdom
[50_3]
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
5 years, 11 months
Global module with ejbs
by Nikola Malenic
I deployed a global module with remote ejbs defined, but I can't access them
from deployed applications.
Here is the interface:
@Remote
public interface ICryptoAPI..
and bean definition:
@Stateless
public class CryptoAPI implements ICryptoAPI ...
How can I find jndi name of the ejbs deployed, since default @Ejb cannot
find bean? Just to mention, /subsystem=naming:jndi-view() from jboss-cli
doesn't print anything about deployed module and there are no errors in
wildfly log.
Maybe, it is not possible to define injectable ejbs in global modules?
5 years, 11 months
Subsystems to advertise implicit and optional dependencies to galleon
by Jean-Francois Denise
Hi,
in the galleon project, in a context where we would not provision a
complete server but just a subset required to run a given configuration,
we have identified a need for subsystems to advertise to the galleon
tooling some modules in addition to the modules galleon discover by
traversing the module dependency tree.
The first case is DeploymentProcessor injecting modules into the
deployment units (implicit modules).
The deployment injected ones are not required to be a dependency of the
subsystem module, so galleon has the risk to miss some of them.
As an example, in logging subsystem we have the following non optional
injected modules :
"org.jboss.logging",
"org.apache.commons.logging",
"org.apache.log4j",
"org.slf4j",
"org.jboss.logging.jul-to-slf4j-stub"
Some of these modules are direct dependencies of logging subsystem, some
others are indirect dependencies, others could be not present at all in
the module dependency tree (eg: org.jboss.logging.jul-to-slf4j-stub).
So we are thinking at solving this issue in 2 possible ways:
1) Mandate that all injected modules become dependencies of the
subsystem module at the cost to load some useless modules at runtime.
2) Possibly better, make the subsystem to call
RuntimeCapability.addAdditionalRequiredPackages (package name being
module name) for each injected module. An existing capability or a new
one would have to be created.
There is also the case of optional injected module dependencies (eg: ee
subsystem org.glassfish.javax.el, org.eclipse.yasson, ...). We need to
treat them differently. When one is provisioning a server using galleon
he can choose to exclude some packages from the provisioned server.
Optional packages can be excluded without making the provisioned state
invalid (as opposed to required package that can't be excluded). These
optional implicit dependencies are typical usage of this, they are not
required by the deployment unit to properly operate.
For these, we plan to use
RuntimeCapability.addAdditionalOptionalPackages. We can't make them
"optional" in JBoss module. When galleon provision a subset of the
server we don't include all optional dependencies.
This brings the case of provisioning of optional dependencies present in
JBOSS module.xml.
We have identified multiple kind of optional dependencies.
1) The optional dependencies that are referencing modules only in use
when a feature is present in the configuration of the subsystem (eg: jmx
subsystem optional dep on org.jboss.remoting-jmx due to
<remoting-connector/>, remoting subsystem optional dep on
io.undertow.core for <http-connector/>, elytron subsystem optional dep
on org.picketbox for <jacc-policy>)
In order to have these dependencies to be provisioned with the
subsystem, we can attach thanks to
RuntimeCapability.addAdditionalRequiredPackages the modules to the
feature. When the feature is present in the configuration, the module is
no more optional but required.
2) The optional dependencies that reference modules that are part of
another subsystems and only use if this other subsystem is present (eg:
org.jboss.as.jpa optional dep on org.jboss.as.ejb3,
org.jboss.as.transactions optional dep on org.jboss.remoting). These
ones are simply not taken into account
3) The optional dependencies that reference modules that are not part
of another subsystem (so are not provisioned by another source) but are
only meaningful if the other subsystem is present. We call these ones
"passive" (eg: org.jboss.as.weld optional dependency on
org.jboss.as.weld.ejb|jpa|beanvalidation|webservices|transactions).
"passive" are analyzed. If all their dependencies are present, then they
are included. Some implicit optional dependencies can fall into this
category (eg: org.jboss.jaxrs optional dep on
org.jboss.resteasy.resteasy-validator-provider-11).
The passive optional dependencies would be advertised with
RuntimeCapability.addAdditionalPassiveOptionalPackages(optional
dependency package name).
So to summarize:
- RuntimeCapability.addAdditionalRequiredPackages for all required
implicit modules
- RuntimeCapability.addAdditionalRequiredPackages to associate optional
dependencies to a feature
- RuntimeCapability.addAdditionalOptionalPackages for all optional
implicit dependencies that are not passive
- RuntimeCapability.addAdditionalPassiveOptionalPackages for all
optional dependencies (implicit or not) that are passive
Is it something that subsystems owner would be ready to put in place to
help galleon in this task? It would require a bit of analysis of the
dependencies of your modules but the gain could be quite important. Some
early experimentation of this has shown a big reduction of the server
filesystem footprint (web server + cdi has been reduced from 156MB to
46MB). The runtime memory usage reduction is not that big, but less
modules being loaded we have a gain.
Thanks for reading.
JF
6 years
-Xbootclasspath/p:jboss-logmanager-<VERSION>.jar equivalent during runtime
by Sam Thomas
Hi,
I understand when starting jboss you can supply the above to specify the
logmanager. If this is not supplied during start up and an agent connects
to jboss during runtime using agentmain(), how can I replicate the
-Xbootclasspath/p: behavior during runtime?
Thanks and Regards
Sam Thomas
6 years
