From mchoma at redhat.com  Tue Dec  4 12:37:34 2018
From: mchoma at redhat.com (Martin Choma)
Date: Tue, 4 Dec 2018 18:37:34 +0100
Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages
In-Reply-To: <CAMxVf4N9ShAjMZ=NSFzAHtf96KWrPR-7gMWzA2XMa9wjryQ4xg@mail.gmail.com>
References: <CAMxVf4N9ShAjMZ=NSFzAHtf96KWrPR-7gMWzA2XMa9wjryQ4xg@mail.gmail.com>
Message-ID: <CAAJBDTBnuafWTKQ47RYtFVvEYs0hGngwd6p2ynUjpKFVzHBetg@mail.gmail.com>

A few thoughts:

Real Time Updates
  - Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.
  - If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.

Support for Expressions
  - Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
standalone.xml.
  - If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
me.

On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
<darran.lofthouse at jboss.com> wrote:
>
> 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.html
>
> 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.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

From brian.stansberry at redhat.com  Tue Dec  4 17:15:20 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 4 Dec 2018 16:15:20 -0600
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
Message-ID: <CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>

This sounds pretty reasonable. There are a lot of layers but the
aggregation layers let people deal with things with a reasonable
granularity.

In the future in the tooling I don't know if there's a way to annotate
layers somehow so some get some sort of prominence in the UI (a la what the
WF CLI does with required attributes and tab completion.)  That's a very
vague thought though, and something for the future.

More inline...


On Fri, Nov 30, 2018 at 11:54 AM 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.
>

AFAIK legacy patching won't work with a custom Galleon provisioned server.
Is this layer just here as necessary bit to let us produce our standard
dists, or do you see it being used for custom servers?


> 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
>

What, roughly, is the disk footprint of an installation like this? I mean
with known tweaks and optimizations you have in your WIP.

What, roughly do the Galleon CLI commands look like to provision a server
with this, plus, say core tools and jaxrs from the full feature pack?


>
>
> 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).
>

Does that bring in JGroups? Or is this a local-only 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.
>

I'm curious why this is only in full. Not really a question for you as I
assume you put it in full because that's where it is now.

> - tools: vault, jdr, wstools, appclient
>

This might need some tweaking. AIUI appclient would bring in nearly the
entire current installation, so perhaps should be independent. I don't know
about wstools.


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

What the rough footprint of this, with core tools added?


>
> 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).


Having tools take a lot is something to attack. CLI in particular. The CLI
is useful on OpenShift as the OS console gives you a terminal on each pod
from which you can start a local CLI session. That lets you do diagnostic
stuff things like tweak log levels etc.  The CLI also gets used for things
like health/readiness probes and shutdown.

> 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.
>

The independent use is the management vault. Using that shouldn't require
everything in the current p-b module though. And arguably you could say
that use case means you need the vault tool and thus whatever layer has it.
(You don't need the vault tool though, not on the server.)

Is there any metadata type concept for marking a layer as deprecated etc?

>
> 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. ;-)
>

Phew!

>
> JF
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181204/dc4a8541/attachment-0001.html 

From cdewolf at redhat.com  Tue Dec  4 18:13:17 2018
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Wed, 5 Dec 2018 00:13:17 +0100
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
Message-ID: <05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>

On 04-12-18 23:15, Brian Stansberry wrote:
>
>     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.
>
>
> The independent use is the management vault. Using that shouldn't 
> require everything in the current p-b module though. And arguably you 
> could say that use case means you need the vault tool and thus 
> whatever layer has it. (You don't need the vault tool though, not on 
> the server.)
>
Can we change the management vault somehow to not need PicketBox at all 
anymore?

Carlo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181205/728e81af/attachment.html 

From darran.lofthouse at redhat.com  Wed Dec  5 06:04:41 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Wed, 5 Dec 2018 11:04:41 +0000
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
	<05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>
Message-ID: <CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>

Yes we can remove it entirely ;-)

On Tue, Dec 4, 2018 at 11:13 PM Carlo de Wolf <cdewolf at redhat.com> wrote:

> On 04-12-18 23:15, Brian Stansberry wrote:
>
> 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.
>>
>
> The independent use is the management vault. Using that shouldn't require
> everything in the current p-b module though. And arguably you could say
> that use case means you need the vault tool and thus whatever layer has it.
> (You don't need the vault tool though, not on the server.)
>
> Can we change the management vault somehow to not need PicketBox at all
> anymore?
>
> Carlo
> _______________________________________________
> 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/20181205/de06bee9/attachment.html 

From cdewolf at redhat.com  Wed Dec  5 06:12:59 2018
From: cdewolf at redhat.com (Carlo de Wolf)
Date: Wed, 5 Dec 2018 12:12:59 +0100
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
	<05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>
	<CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>
Message-ID: <4a9e69e9-4e69-08d4-3ba3-866958282dcc@redhat.com>

Hehe, I meant become fully optional. EAP users might still wish to 
install it.

Carlo

On 05-12-18 12:04, Darran Lofthouse wrote:
> Yes we can remove it entirely ;-)
>
> On Tue, Dec 4, 2018 at 11:13 PM Carlo de Wolf <cdewolf at redhat.com 
> <mailto:cdewolf at redhat.com>> wrote:
>
>     On 04-12-18 23:15, Brian Stansberry wrote:
>>
>>         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.
>>
>>
>>     The independent use is the management vault. Using that shouldn't
>>     require everything in the current p-b module though. And arguably
>>     you could say that use case means you need the vault tool and
>>     thus whatever layer has it. (You don't need the vault tool
>>     though, not on the server.)
>>
>     Can we change the management vault somehow to not need PicketBox
>     at all anymore?
>
>     Carlo
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto: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/20181205/d02275aa/attachment.html 

From jdenise at redhat.com  Wed Dec  5 07:33:59 2018
From: jdenise at redhat.com (Jean-Francois Denise)
Date: Wed, 5 Dec 2018 13:33:59 +0100
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
Message-ID: <d9e7f3cf-6cdb-7a2a-f598-b845969fd94a@redhat.com>

Thanks Brian,

reply inlined.


On 04/12/2018 23:15, Brian Stansberry wrote:
> This sounds pretty reasonable. There are a lot of layers but the 
> aggregation layers let people deal with things with a reasonable 
> granularity.
>
> In the future in the tooling I don't know if there's a way to annotate 
> layers somehow so some get some sort of prominence in the UI (a la 
> what the WF CLI does with required attributes and tab completion.)? 
> That's a very vague thought though, and something for the future.
>
> More inline...
>
>
> On Fri, Nov 30, 2018 at 11:54 AM Jean-Francois Denise 
> <jdenise at redhat.com <mailto: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.
>
>
> AFAIK legacy patching won't work with a custom Galleon provisioned 
> server. Is this layer just here as necessary bit to let us produce our 
> standard dists, or do you see it being used for custom servers?
It is a layer introduced to be able to provision a complete default 
standalone configuration without inheriting default packages (that 
contains all modules). Your question makes me realize that it could be 
hidden by having the default config to simply includes the package (what 
the layer does).
>
>
>     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
>
>
> What, roughly, is the disk footprint of an installation like this? I 
> mean with known tweaks and optimizations you have in your WIP.
The size is 38MB. The provisioned standalone servlet config is around 55MB.
>
> What, roughly do the Galleon CLI commands look like to provision a 
> server with this, plus, say core tools and jaxrs from the full feature 
> pack?
For now the tools layer embeds all tools. I used to have layers for each 
kind of tools (tools, ejb-appclient, wstools, jdr, jboss-client, 
jboss-cli-client) but decided to group them all for the first step. It 
seems that, according to the cloud context requirements, only the 
core-tools should be layerized (cli, add-user and elytron). Other tools 
being provisioned with default dist.

We have jaxrs that depends on web-server, we would provision: 
jaxrs,elytron,management,tools The command would look like:

install wildfly:current#16.0.0.Beta1-SNAPSHOT --dir=server 
--layers=jaxrs,management,elytron,tools

The size with all tools is 155MB, with core tools: 64MB
>
>
>
>     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).
>
>
> Does that bring in JGroups? Or is this a local-only cache?
At the configuration level it only configures a local cache 
hibernate-cache but in terms of modules, it brings jgroups.
>
>     - 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.
>
>
> I'm curious why this is only in full. Not really a question for you as 
> I assume you put it in full because that's where it is now.
Yes.
>
>     - tools: vault, jdr, wstools, appclient
>
>
> This might need some tweaking. AIUI appclient would bring in nearly 
> the entire current installation, so perhaps should be independent. I 
> don't know about wstools.
Yes, splitting tools give us much better footprint. We should only 
incorporate core tools in a core-tools layer for now.
>
>
>     Aggregation layer
>
>     - cloud-profile: contains cdi,jaxrs,jpa,activemq-jms,microprofile
>     . All
>     optionally included, allowing for exclusion (eg: exclude
>     activemq-jms).
>
>
> What the rough footprint of this, with core tools added?
>
The provisioning of cloud-profile alone is 121MB. This is the size of 
the layers with all the optional dependencies injected from DUP (minus 
passives that are not incorporated eg: weld.ejb). Some of them are quite 
big and would be not required in all cases. For example, by excluding:
org.jboss.weld.probe (cdi debug)
org.hibernate.search.orm (hibernate search)
org.jboss.resteasy.resteasy-crypto (jaxrs crypto, brings bouncycastle)
org.jboss.resteasy.resteasy-multipart-provider (brings email, multipart 
support).

the cloud-profile size is down to 108MB.

By not bringing any such optional deps we are at 104MB, but that is to 
my point of view safer to guarantee that these optional are provisioned 
and exclude the un-needed.

The size of cloud-profile and all its deps + core tools is 126MB. As a 
comparison, full provisioned standalone config is 212MB
>
>
>
>     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). 
>
>
> Having tools take a lot is something to attack. CLI in particular. The 
> CLI is useful on OpenShift as the OS console gives you a terminal on 
> each pod from which you can start a local CLI session. That lets you 
> do diagnostic stuff things like tweak log levels etc.? The CLI also 
> gets used for things like health/readiness probes and shutdown.
core tools (add-user, cli, elytron-tool) on top of base-server brings 
7MB. We could see if we can reduce that.
>
>     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.
>
>
> The independent use is the management vault. Using that shouldn't 
> require everything in the current p-b module though. And arguably you 
> could say that use case means you need the vault tool and thus 
> whatever layer has it. (You don't need the vault tool though, not on 
> the server.)
elytron has a dependency on picketbox for jacc.
>
> Is there any metadata type concept for marking a layer as deprecated etc?
no description, no metadata, yes that would help.
>
>
>     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. ;-)
>
>
> Phew!
>
>
>     JF
>
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>
>
> -- 
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181205/936f13d0/attachment-0001.html 

From jdenise at redhat.com  Wed Dec  5 08:51:32 2018
From: jdenise at redhat.com (Jean-Francois Denise)
Date: Wed, 5 Dec 2018 14:51:32 +0100
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
	<05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>
	<CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>
Message-ID: <80d5dc87-03e7-ed7b-48e6-9e2cc5fd2a72@redhat.com>

Darran,

elytron seems to have a dependency on picketbox for jacc support. Am I 
right?


On 05/12/2018 12:04, Darran Lofthouse wrote:
> Yes we can remove it entirely ;-)
>
> On Tue, Dec 4, 2018 at 11:13 PM Carlo de Wolf <cdewolf at redhat.com 
> <mailto:cdewolf at redhat.com>> wrote:
>
>     On 04-12-18 23:15, Brian Stansberry wrote:
>>
>>         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.
>>
>>
>>     The independent use is the management vault. Using that shouldn't
>>     require everything in the current p-b module though. And arguably
>>     you could say that use case means you need the vault tool and
>>     thus whatever layer has it. (You don't need the vault tool
>>     though, not on the server.)
>>
>     Can we change the management vault somehow to not need PicketBox
>     at all anymore?
>
>     Carlo
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto: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/20181205/04fe031d/attachment.html 

From darran.lofthouse at redhat.com  Wed Dec  5 08:56:39 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Wed, 5 Dec 2018 13:56:39 +0000
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <80d5dc87-03e7-ed7b-48e6-9e2cc5fd2a72@redhat.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
	<05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>
	<CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>
	<80d5dc87-03e7-ed7b-48e6-9e2cc5fd2a72@redhat.com>
Message-ID: <CAMxVf4M5ze58DGJL+t-8Xs+=NbhWK1UkR4pNXOO4GjHEWmw6qQ@mail.gmail.com>

Do you mean Elytron or the Elytron Subsystem?

I believe yes the subsystem does have that dependency but it is only
temporary until PicketBox is removed.

On Wed, Dec 5, 2018 at 1:51 PM Jean-Francois Denise <jdenise at redhat.com>
wrote:

> Darran,
>
> elytron seems to have a dependency on picketbox for jacc support. Am I
> right?
>
> On 05/12/2018 12:04, Darran Lofthouse wrote:
>
> Yes we can remove it entirely ;-)
>
> On Tue, Dec 4, 2018 at 11:13 PM Carlo de Wolf <cdewolf at redhat.com> wrote:
>
>> On 04-12-18 23:15, Brian Stansberry wrote:
>>
>> 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.
>>>
>>
>> The independent use is the management vault. Using that shouldn't require
>> everything in the current p-b module though. And arguably you could say
>> that use case means you need the vault tool and thus whatever layer has it.
>> (You don't need the vault tool though, not on the server.)
>>
>> Can we change the management vault somehow to not need PicketBox at all
>> anymore?
>>
>> Carlo
>> _______________________________________________
>> 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/20181205/bfecd906/attachment.html 

From jdenise at redhat.com  Wed Dec  5 08:58:33 2018
From: jdenise at redhat.com (Jean-Francois Denise)
Date: Wed, 5 Dec 2018 14:58:33 +0100
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <CAMxVf4M5ze58DGJL+t-8Xs+=NbhWK1UkR4pNXOO4GjHEWmw6qQ@mail.gmail.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
	<05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>
	<CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>
	<80d5dc87-03e7-ed7b-48e6-9e2cc5fd2a72@redhat.com>
	<CAMxVf4M5ze58DGJL+t-8Xs+=NbhWK1UkR4pNXOO4GjHEWmw6qQ@mail.gmail.com>
Message-ID: <3a4551ed-59b1-9cea-8328-377ae2c9edb3@redhat.com>

The subsystem. So we could imagine that user would install both elytron 
and picketbox.


On 05/12/2018 14:56, Darran Lofthouse wrote:
> Do you mean Elytron or the Elytron Subsystem?
>
> I believe yes the subsystem does have that dependency but it is only 
> temporary until PicketBox is removed.
>
> On Wed, Dec 5, 2018 at 1:51 PM Jean-Francois Denise 
> <jdenise at redhat.com <mailto:jdenise at redhat.com>> wrote:
>
>     Darran,
>
>     elytron seems to have a dependency on picketbox for jacc support.
>     Am I right?
>
>
>     On 05/12/2018 12:04, Darran Lofthouse wrote:
>>     Yes we can remove it entirely ;-)
>>
>>     On Tue, Dec 4, 2018 at 11:13 PM Carlo de Wolf <cdewolf at redhat.com
>>     <mailto:cdewolf at redhat.com>> wrote:
>>
>>         On 04-12-18 23:15, Brian Stansberry wrote:
>>>
>>>             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.
>>>
>>>
>>>         The independent use is the management vault. Using that
>>>         shouldn't require everything in the current p-b module
>>>         though. And arguably you could say that use case means you
>>>         need the vault tool and thus whatever layer has it. (You
>>>         don't need the vault tool though, not on the server.)
>>>
>>         Can we change the management vault somehow to not need
>>         PicketBox at all anymore?
>>
>>         Carlo
>>         _______________________________________________
>>         wildfly-dev mailing list
>>         wildfly-dev at lists.jboss.org <mailto: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/20181205/d44af9c7/attachment.html 

From darran.lofthouse at redhat.com  Wed Dec  5 09:01:04 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Wed, 5 Dec 2018 14:01:04 +0000
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <3a4551ed-59b1-9cea-8328-377ae2c9edb3@redhat.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
	<05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>
	<CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>
	<80d5dc87-03e7-ed7b-48e6-9e2cc5fd2a72@redhat.com>
	<CAMxVf4M5ze58DGJL+t-8Xs+=NbhWK1UkR4pNXOO4GjHEWmw6qQ@mail.gmail.com>
	<3a4551ed-59b1-9cea-8328-377ae2c9edb3@redhat.com>
Message-ID: <CAMxVf4Nk5tSi673cGrE4PUnBKVSncWo4C0GLDGuW7YCR6fFFew@mail.gmail.com>

We could also imagine the user will only install Elytron and there will be
no such thing as PicketBox at some point.

On Wed, Dec 5, 2018 at 1:58 PM Jean-Francois Denise <jdenise at redhat.com>
wrote:

> The subsystem. So we could imagine that user would install both elytron
> and picketbox.
>
> On 05/12/2018 14:56, Darran Lofthouse wrote:
>
> Do you mean Elytron or the Elytron Subsystem?
>
> I believe yes the subsystem does have that dependency but it is only
> temporary until PicketBox is removed.
>
> On Wed, Dec 5, 2018 at 1:51 PM Jean-Francois Denise <jdenise at redhat.com>
> wrote:
>
>> Darran,
>>
>> elytron seems to have a dependency on picketbox for jacc support. Am I
>> right?
>>
>> On 05/12/2018 12:04, Darran Lofthouse wrote:
>>
>> Yes we can remove it entirely ;-)
>>
>> On Tue, Dec 4, 2018 at 11:13 PM Carlo de Wolf <cdewolf at redhat.com> wrote:
>>
>>> On 04-12-18 23:15, Brian Stansberry wrote:
>>>
>>> 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.
>>>>
>>>
>>> The independent use is the management vault. Using that shouldn't
>>> require everything in the current p-b module though. And arguably you could
>>> say that use case means you need the vault tool and thus whatever layer has
>>> it. (You don't need the vault tool though, not on the server.)
>>>
>>> Can we change the management vault somehow to not need PicketBox at all
>>> anymore?
>>>
>>> Carlo
>>> _______________________________________________
>>> 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/20181205/352c88ea/attachment-0001.html 

From jdenise at redhat.com  Wed Dec  5 09:23:38 2018
From: jdenise at redhat.com (Jean-Francois Denise)
Date: Wed, 5 Dec 2018 15:23:38 +0100
Subject: [wildfly-dev] Wildfly layers
In-Reply-To: <CAMxVf4Nk5tSi673cGrE4PUnBKVSncWo4C0GLDGuW7YCR6fFFew@mail.gmail.com>
References: <ed6bbb4a-b218-4854-5615-158c531b233a@redhat.com>
	<CAPhbRDbC-GKjPDjsQQ3B1h8OFmfgSC_YDKVYZNrobGKhxQaz_w@mail.gmail.com>
	<05460309-feb6-72b3-ca00-178566c5ef1e@redhat.com>
	<CAMxVf4N5eYP_PGtb6fhey7_yLG8TgyyX9DdEPcjEzw2mN=aXQg@mail.gmail.com>
	<80d5dc87-03e7-ed7b-48e6-9e2cc5fd2a72@redhat.com>
	<CAMxVf4M5ze58DGJL+t-8Xs+=NbhWK1UkR4pNXOO4GjHEWmw6qQ@mail.gmail.com>
	<3a4551ed-59b1-9cea-8328-377ae2c9edb3@redhat.com>
	<CAMxVf4Nk5tSi673cGrE4PUnBKVSncWo4C0GLDGuW7YCR6fFFew@mail.gmail.com>
Message-ID: <ce4ae828-b23a-f647-c892-6ace0a12e24e@redhat.com>

Ok, so it seems that picketbox shouldn't emerge as a layer. During the 
transient period where elytron relies on it, we would not support (using 
layers) elytron+jacc without implying the inclusion of a vault layer.
vault layer would? be a rename of the picketbox layer in servlet FP.
vault-tool (module and script) could appear as a layer in full FP if we 
think it is worth it in the first cloud scenario we are addressing 
(otherwise one would need to install a full server to get it).

On 05/12/2018 15:01, Darran Lofthouse wrote:
> We could also imagine the user will only install Elytron and there 
> will be no such thing as PicketBox at some point.
>
> On Wed, Dec 5, 2018 at 1:58 PM Jean-Francois Denise 
> <jdenise at redhat.com <mailto:jdenise at redhat.com>> wrote:
>
>     The subsystem. So we could imagine that user would install both
>     elytron and picketbox.
>
>
>     On 05/12/2018 14:56, Darran Lofthouse wrote:
>>     Do you mean Elytron or the Elytron Subsystem?
>>
>>     I believe yes the subsystem does have that dependency but it is
>>     only temporary until PicketBox is removed.
>>
>>     On Wed, Dec 5, 2018 at 1:51 PM Jean-Francois Denise
>>     <jdenise at redhat.com <mailto:jdenise at redhat.com>> wrote:
>>
>>         Darran,
>>
>>         elytron seems to have a dependency on picketbox for jacc
>>         support. Am I right?
>>
>>
>>         On 05/12/2018 12:04, Darran Lofthouse wrote:
>>>         Yes we can remove it entirely ;-)
>>>
>>>         On Tue, Dec 4, 2018 at 11:13 PM Carlo de Wolf
>>>         <cdewolf at redhat.com <mailto:cdewolf at redhat.com>> wrote:
>>>
>>>             On 04-12-18 23:15, Brian Stansberry wrote:
>>>>
>>>>                 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.
>>>>
>>>>
>>>>             The independent use is the management vault. Using that
>>>>             shouldn't require everything in the current p-b module
>>>>             though. And arguably you could say that use case means
>>>>             you need the vault tool and thus whatever layer has it.
>>>>             (You don't need the vault tool though, not on the server.)
>>>>
>>>             Can we change the management vault somehow to not need
>>>             PicketBox at all anymore?
>>>
>>>             Carlo
>>>             _______________________________________________
>>>             wildfly-dev mailing list
>>>             wildfly-dev at lists.jboss.org
>>>             <mailto: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/20181205/4b22cb18/attachment.html 

From brian.stansberry at redhat.com  Thu Dec  6 20:34:08 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Thu, 6 Dec 2018 19:34:08 -0600
Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages
In-Reply-To: <CAAJBDTBnuafWTKQ47RYtFVvEYs0hGngwd6p2ynUjpKFVzHBetg@mail.gmail.com>
References: <CAMxVf4N9ShAjMZ=NSFzAHtf96KWrPR-7gMWzA2XMa9wjryQ4xg@mail.gmail.com>
	<CAAJBDTBnuafWTKQ47RYtFVvEYs0hGngwd6p2ynUjpKFVzHBetg@mail.gmail.com>
Message-ID: <CAPhbRDYc=RxyBXk87i378e_Cvzeq4Ji6wTeykCEmM4gd76UojQ@mail.gmail.com>

On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <mchoma at redhat.com> wrote:

> A few thoughts:
>
> Real Time Updates
>   - Runtime changes in era of OpenShift become less and less important
> as configuration should be immutable. Runtime changes should be
> addressed on OpenShift level. At least in past some of my "runtime
> changes" issues were denied with this argument.
>

This is certainly something to consider when considering any new management
functionality.

Another thing to consider is what services are going to utilize any
real-time update? Are there many resources that respond to a credential
attribute value change (e.g. write-attribute) without triggering
reload-required? If they do trigger reload-required it seems likely that's
because making a new value take effect was considered to be too difficult
compared to the gain. In an immutable world the gain is likely even less.

>   - If this will be decided to accomplish I think it is enough when
> updates take in action on explicit administrator command.
>
> Support for Expressions
>   - Really question here is if vault wasn't misused as external
> configuration storage for standalone.xml holding environment
> properties on one place. Which could be more convenient as specifying
> bunch of system properties. If so we should address this feature
> separately - way to specify configuration property file for server
> standalone.xml.
>

I hope people aren't using a vault just for that. If you want to group
together properties you can use bin/standalone.sh -P.  On OpenShift you can
mount a ConfigMap as a source of env var values, and env vars are used in
expression resolution.

I could imagine people sticking a username in a vault just because they put
the password in the vault and administratively it was simpler to manage the
two related values together. No idea if that's really done; I just can
imagine it. ;)

  - If purpose is to really treat different arguments as security
> sensitive then proposed encryption/decryption way seems promising to
> me.
>
> On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
> <darran.lofthouse at jboss.com> wrote:
> >
> > 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.html
> >
> > 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.
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181206/9d67579a/attachment.html 

From darran.lofthouse at redhat.com  Fri Dec  7 06:32:42 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Fri, 7 Dec 2018 11:32:42 +0000
Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages
In-Reply-To: <CAPhbRDYc=RxyBXk87i378e_Cvzeq4Ji6wTeykCEmM4gd76UojQ@mail.gmail.com>
References: <CAMxVf4N9ShAjMZ=NSFzAHtf96KWrPR-7gMWzA2XMa9wjryQ4xg@mail.gmail.com>
	<CAAJBDTBnuafWTKQ47RYtFVvEYs0hGngwd6p2ynUjpKFVzHBetg@mail.gmail.com>
	<CAPhbRDYc=RxyBXk87i378e_Cvzeq4Ji6wTeykCEmM4gd76UojQ@mail.gmail.com>
Message-ID: <CAMxVf4OZ4NA_UBP9L+vgjVxek1baqfkSzLY+BbHh63Rxz79XPA@mail.gmail.com>

On Fri, Dec 7, 2018 at 1:34 AM Brian Stansberry <brian.stansberry at redhat.com>
wrote:

>
>
> On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <mchoma at redhat.com> wrote:
>
>> A few thoughts:
>>
>> Real Time Updates
>>   - Runtime changes in era of OpenShift become less and less important
>> as configuration should be immutable. Runtime changes should be
>> addressed on OpenShift level. At least in past some of my "runtime
>> changes" issues were denied with this argument.
>>
>
> This is certainly something to consider when considering any new
> management functionality.
>
> Another thing to consider is what services are going to utilize any
> real-time update? Are there many resources that respond to a credential
> attribute value change (e.g. write-attribute) without triggering
> reload-required? If they do trigger reload-required it seems likely that's
> because making a new value take effect was considered to be too difficult
> compared to the gain. In an immutable world the gain is likely even less.
>

Yes the real time updates could only ever be approached on a resource by
resource basis so existing resources (at least we have a finite set to
consider) would either need to already update real time password updates or
be retrospectively modified to support them - for the credential store the
best we can do it make this a possibility.


>   - If this will be decided to accomplish I think it is enough when
>> updates take in action on explicit administrator command.
>>
>> Support for Expressions
>>   - Really question here is if vault wasn't misused as external
>> configuration storage for standalone.xml holding environment
>> properties on one place. Which could be more convenient as specifying
>> bunch of system properties. If so we should address this feature
>> separately - way to specify configuration property file for server
>> standalone.xml.
>>
>
> I hope people aren't using a vault just for that. If you want to group
> together properties you can use bin/standalone.sh -P.  On OpenShift you can
> mount a ConfigMap as a source of env var values, and env vars are used in
> expression resolution.
>
> I could imagine people sticking a username in a vault just because they
> put the password in the vault and administratively it was simpler to manage
> the two related values together. No idea if that's really done; I just can
> imagine it. ;)
>

Rather than focusing on the management side of the credential store and
features like real time updates it feels to me that emphasis should be on
this username / password problem - any enhancements in this area having a
better chance for long term relevance.

As I have mentioned previously we know we have some resources that only
require a credential, such as unlocking a local KeyStore.

The username / password pairing is a common issue - we don't really have a
clean solution for this yet so would be a good area to focus.

However a number of newer authentication mechanisms have moved beyond the
traditional username / password combo, some need an alternative to a
password, some don't need a username at all.  These also often have an
option to delegate the callers identity to the remote endpoint etc...

Better solving these last two would seem to be a better investment of
effort, regardless of how static future configurations do or do not become
this would still be relevant.

We already have the client side authentication context which provides a
very flexible configuration selection approach based on the endpoint being
connected to and additional information available as the connection is
requested.  Whilst very flexible this does add a level of complexity in
understanding how the configuration is assembled and how mappings are
applied.

The next resource we have is the existing authentication-configuration,
this is effectively a single client side authentication policy for an
outbound connection.

I think from an end users perspective it is clearer to visualise a 1:1
relationship between the resource defining the outbound connection and the
resource defining the authentication policy.  From a tooling perspective as
these are linked by capabilities a user doesn't even need to fully see the
separation, e.g. as you edited a datasource the console could offer an
option to edit the authentication-configuration which could open without
forcing the user to navigate to a different location in the model hierarchy.

We would need to look into more detail as to the suitability of this
resource and exactly how we would integrate it but this would generally be
my preferred starting point over trying to replicate expression expansion.


>
>   - If purpose is to really treat different arguments as security
>> sensitive then proposed encryption/decryption way seems promising to
>> me.
>>
>> On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
>> <darran.lofthouse at jboss.com> wrote:
>> >
>> > 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.html
>> >
>> > 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.
>> > _______________________________________________
>> > wildfly-dev mailing list
>> > wildfly-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181207/c39e3cec/attachment-0001.html 

From darran.lofthouse at redhat.com  Fri Dec  7 08:16:03 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Fri, 7 Dec 2018 13:16:03 +0000
Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages
In-Reply-To: <CAMxVf4OZ4NA_UBP9L+vgjVxek1baqfkSzLY+BbHh63Rxz79XPA@mail.gmail.com>
References: <CAMxVf4N9ShAjMZ=NSFzAHtf96KWrPR-7gMWzA2XMa9wjryQ4xg@mail.gmail.com>
	<CAAJBDTBnuafWTKQ47RYtFVvEYs0hGngwd6p2ynUjpKFVzHBetg@mail.gmail.com>
	<CAPhbRDYc=RxyBXk87i378e_Cvzeq4Ji6wTeykCEmM4gd76UojQ@mail.gmail.com>
	<CAMxVf4OZ4NA_UBP9L+vgjVxek1baqfkSzLY+BbHh63Rxz79XPA@mail.gmail.com>
Message-ID: <CAMxVf4PdXmCQ5NeC=rYLYzCpug1d=wFnKtsRQBWg_gxmOfehFw@mail.gmail.com>

Following on from my last e-mail this brings us to a follow on step for the
users that are looking to externalise both their username and credential
configuration together.

Within the Elytron subsystem I can now add a new
'authentication-client-file' resource to load static definitions from file,
as static definitions these will not be manageable.  By using child
resources however I can still hook these into capabilities to make them
referenceable.

By loading from file we could also consider a couple of additional options
such as encrypting the file, we could also consider bundling within a jar
allowing other resources such as keytabs and certificates to be bundled
with the configuration.

After this stage we then have further possibilities to expand on this
further.

We could add a custom authentication-client resolver SPI to allow for
custom resolvers, anyone who wants to resolve from custom locations could
add their own implementation.  In hosted environments such as OpenShift
custom resolvers could be used to obtain authentication policies being
managed elsewhere without relying on property expansion.

Additionally by having all of this wrapped in an API we have the ability to
add both auditing and authorization for anything accessing this
configuration - something that is not possible in solutions that rely on
expression expansion.

Regards,
Darran Lofthouse.



On Fri, 7 Dec 2018, 11:32 Darran Lofthouse <darran.lofthouse at redhat.com
wrote:

>
> On Fri, Dec 7, 2018 at 1:34 AM Brian Stansberry <
> brian.stansberry at redhat.com> wrote:
>
>>
>>
>> On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <mchoma at redhat.com> wrote:
>>
>>> A few thoughts:
>>>
>>> Real Time Updates
>>>   - Runtime changes in era of OpenShift become less and less important
>>> as configuration should be immutable. Runtime changes should be
>>> addressed on OpenShift level. At least in past some of my "runtime
>>> changes" issues were denied with this argument.
>>>
>>
>> This is certainly something to consider when considering any new
>> management functionality.
>>
>> Another thing to consider is what services are going to utilize any
>> real-time update? Are there many resources that respond to a credential
>> attribute value change (e.g. write-attribute) without triggering
>> reload-required? If they do trigger reload-required it seems likely that's
>> because making a new value take effect was considered to be too difficult
>> compared to the gain. In an immutable world the gain is likely even less.
>>
>
> Yes the real time updates could only ever be approached on a resource by
> resource basis so existing resources (at least we have a finite set to
> consider) would either need to already update real time password updates or
> be retrospectively modified to support them - for the credential store the
> best we can do it make this a possibility.
>
>
>>   - If this will be decided to accomplish I think it is enough when
>>> updates take in action on explicit administrator command.
>>>
>>> Support for Expressions
>>>   - Really question here is if vault wasn't misused as external
>>> configuration storage for standalone.xml holding environment
>>> properties on one place. Which could be more convenient as specifying
>>> bunch of system properties. If so we should address this feature
>>> separately - way to specify configuration property file for server
>>> standalone.xml.
>>>
>>
>> I hope people aren't using a vault just for that. If you want to group
>> together properties you can use bin/standalone.sh -P.  On OpenShift you can
>> mount a ConfigMap as a source of env var values, and env vars are used in
>> expression resolution.
>>
>> I could imagine people sticking a username in a vault just because they
>> put the password in the vault and administratively it was simpler to manage
>> the two related values together. No idea if that's really done; I just can
>> imagine it. ;)
>>
>
> Rather than focusing on the management side of the credential store and
> features like real time updates it feels to me that emphasis should be on
> this username / password problem - any enhancements in this area having a
> better chance for long term relevance.
>
> As I have mentioned previously we know we have some resources that only
> require a credential, such as unlocking a local KeyStore.
>
> The username / password pairing is a common issue - we don't really have a
> clean solution for this yet so would be a good area to focus.
>
> However a number of newer authentication mechanisms have moved beyond the
> traditional username / password combo, some need an alternative to a
> password, some don't need a username at all.  These also often have an
> option to delegate the callers identity to the remote endpoint etc...
>
> Better solving these last two would seem to be a better investment of
> effort, regardless of how static future configurations do or do not become
> this would still be relevant.
>
> We already have the client side authentication context which provides a
> very flexible configuration selection approach based on the endpoint being
> connected to and additional information available as the connection is
> requested.  Whilst very flexible this does add a level of complexity in
> understanding how the configuration is assembled and how mappings are
> applied.
>
> The next resource we have is the existing authentication-configuration,
> this is effectively a single client side authentication policy for an
> outbound connection.
>
> I think from an end users perspective it is clearer to visualise a 1:1
> relationship between the resource defining the outbound connection and the
> resource defining the authentication policy.  From a tooling perspective as
> these are linked by capabilities a user doesn't even need to fully see the
> separation, e.g. as you edited a datasource the console could offer an
> option to edit the authentication-configuration which could open without
> forcing the user to navigate to a different location in the model hierarchy.
>
> We would need to look into more detail as to the suitability of this
> resource and exactly how we would integrate it but this would generally be
> my preferred starting point over trying to replicate expression expansion.
>
>
>>
>>   - If purpose is to really treat different arguments as security
>>> sensitive then proposed encryption/decryption way seems promising to
>>> me.
>>>
>>> On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
>>> <darran.lofthouse at jboss.com> wrote:
>>> >
>>> > 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.html
>>> >
>>> > 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.
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>>
>> --
>> Brian Stansberry
>> Manager, Senior Principal Software Engineer
>> Red Hat
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181207/4b98b47f/attachment.html 

From tdiesler at redhat.com  Wed Dec 12 07:35:27 2018
From: tdiesler at redhat.com (Thomas Diesler)
Date: Wed, 12 Dec 2018 13:35:27 +0100
Subject: [wildfly-dev] WildFly-Camel 9.0.0 released
Message-ID: <D78FFCDF-1A4F-4268-8305-7CD1E1DEDD7A@redhat.com>

WildFly-Camel 9.0.0 provides Camel-2.23.0 integration with WildFly-15.0.0

This is a major WildFly upgrade that also comes with a new Camel version. It's main focus has been on CXF/Elytron integration.

Component upgrades include

WildFly-15.0.0
Camel-2.23.0
Hawtio-2.3.0
In addition to that, we also resolved a number of other tasks and bugs <https://github.com/wildfly-extras/wildfly-camel/blob/master/docs/Changelog.md>.

For details please see the 9.0.0 Milestone <https://github.com/wildfly-extras/wildfly-camel/issues?q=milestone%3A9.0.0>.

Enjoy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181212/6503a9af/attachment.html 

From rory.odonnell at oracle.com  Fri Dec 14 05:06:43 2018
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 14 Dec 2018 10:06:43 +0000
Subject: [wildfly-dev] JDK 12 enters Rampdown Phase One
Message-ID: <bac4ea69-d92b-dfc3-b89c-9afc27ac8855@oracle.com>

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181214/aa86f092/attachment-0001.html 

From brian.stansberry at redhat.com  Tue Dec 18 16:51:14 2018
From: brian.stansberry at redhat.com (Brian Stansberry)
Date: Tue, 18 Dec 2018 15:51:14 -0600
Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages
In-Reply-To: <CAMxVf4PdXmCQ5NeC=rYLYzCpug1d=wFnKtsRQBWg_gxmOfehFw@mail.gmail.com>
References: <CAMxVf4N9ShAjMZ=NSFzAHtf96KWrPR-7gMWzA2XMa9wjryQ4xg@mail.gmail.com>
	<CAAJBDTBnuafWTKQ47RYtFVvEYs0hGngwd6p2ynUjpKFVzHBetg@mail.gmail.com>
	<CAPhbRDYc=RxyBXk87i378e_Cvzeq4Ji6wTeykCEmM4gd76UojQ@mail.gmail.com>
	<CAMxVf4OZ4NA_UBP9L+vgjVxek1baqfkSzLY+BbHh63Rxz79XPA@mail.gmail.com>
	<CAMxVf4PdXmCQ5NeC=rYLYzCpug1d=wFnKtsRQBWg_gxmOfehFw@mail.gmail.com>
Message-ID: <CAPhbRDYGyo0tH0jSJ_GNr37DJKqt89DU4WzJQNezo1ue2Me41g@mail.gmail.com>

Sorry for the slow reply.

This last post sounds quite a bit like the vault. But with an updated
API/SPI and a much richer possible set of behavior. And instead of using
expression resolution for access, which has the negative of making it
theoretically usable for pretty much any attribute, but with the system not
really knowing how it is being used, there is proper capability-based
integration. Is that a fair read on this?

On Fri, Dec 7, 2018 at 7:16 AM Darran Lofthouse <darran.lofthouse at redhat.com>
wrote:

> Following on from my last e-mail this brings us to a follow on step for
> the users that are looking to externalise both their username and
> credential configuration together.
>
> Within the Elytron subsystem I can now add a new
> 'authentication-client-file' resource to load static definitions from file,
> as static definitions these will not be manageable.  By using child
> resources however I can still hook these into capabilities to make them
> referenceable.
>
> By loading from file we could also consider a couple of additional options
> such as encrypting the file, we could also consider bundling within a jar
> allowing other resources such as keytabs and certificates to be bundled
> with the configuration.
>
> After this stage we then have further possibilities to expand on this
> further.
>
> We could add a custom authentication-client resolver SPI to allow for
> custom resolvers, anyone who wants to resolve from custom locations could
> add their own implementation.  In hosted environments such as OpenShift
> custom resolvers could be used to obtain authentication policies being
> managed elsewhere without relying on property expansion.
>
> Additionally by having all of this wrapped in an API we have the ability
> to add both auditing and authorization for anything accessing this
> configuration - something that is not possible in solutions that rely on
> expression expansion.
>
> Regards,
> Darran Lofthouse.
>
>
>
> On Fri, 7 Dec 2018, 11:32 Darran Lofthouse <darran.lofthouse at redhat.com
> wrote:
>
>>
>> On Fri, Dec 7, 2018 at 1:34 AM Brian Stansberry <
>> brian.stansberry at redhat.com> wrote:
>>
>>>
>>>
>>> On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <mchoma at redhat.com> wrote:
>>>
>>>> A few thoughts:
>>>>
>>>> Real Time Updates
>>>>   - Runtime changes in era of OpenShift become less and less important
>>>> as configuration should be immutable. Runtime changes should be
>>>> addressed on OpenShift level. At least in past some of my "runtime
>>>> changes" issues were denied with this argument.
>>>>
>>>
>>> This is certainly something to consider when considering any new
>>> management functionality.
>>>
>>> Another thing to consider is what services are going to utilize any
>>> real-time update? Are there many resources that respond to a credential
>>> attribute value change (e.g. write-attribute) without triggering
>>> reload-required? If they do trigger reload-required it seems likely that's
>>> because making a new value take effect was considered to be too difficult
>>> compared to the gain. In an immutable world the gain is likely even less.
>>>
>>
>> Yes the real time updates could only ever be approached on a resource by
>> resource basis so existing resources (at least we have a finite set to
>> consider) would either need to already update real time password updates or
>> be retrospectively modified to support them - for the credential store the
>> best we can do it make this a possibility.
>>
>>
>>>   - If this will be decided to accomplish I think it is enough when
>>>> updates take in action on explicit administrator command.
>>>>
>>>> Support for Expressions
>>>>   - Really question here is if vault wasn't misused as external
>>>> configuration storage for standalone.xml holding environment
>>>> properties on one place. Which could be more convenient as specifying
>>>> bunch of system properties. If so we should address this feature
>>>> separately - way to specify configuration property file for server
>>>> standalone.xml.
>>>>
>>>
>>> I hope people aren't using a vault just for that. If you want to group
>>> together properties you can use bin/standalone.sh -P.  On OpenShift you can
>>> mount a ConfigMap as a source of env var values, and env vars are used in
>>> expression resolution.
>>>
>>> I could imagine people sticking a username in a vault just because they
>>> put the password in the vault and administratively it was simpler to manage
>>> the two related values together. No idea if that's really done; I just can
>>> imagine it. ;)
>>>
>>
>> Rather than focusing on the management side of the credential store and
>> features like real time updates it feels to me that emphasis should be on
>> this username / password problem - any enhancements in this area having a
>> better chance for long term relevance.
>>
>> As I have mentioned previously we know we have some resources that only
>> require a credential, such as unlocking a local KeyStore.
>>
>> The username / password pairing is a common issue - we don't really have
>> a clean solution for this yet so would be a good area to focus.
>>
>> However a number of newer authentication mechanisms have moved beyond the
>> traditional username / password combo, some need an alternative to a
>> password, some don't need a username at all.  These also often have an
>> option to delegate the callers identity to the remote endpoint etc...
>>
>> Better solving these last two would seem to be a better investment of
>> effort, regardless of how static future configurations do or do not become
>> this would still be relevant.
>>
>> We already have the client side authentication context which provides a
>> very flexible configuration selection approach based on the endpoint being
>> connected to and additional information available as the connection is
>> requested.  Whilst very flexible this does add a level of complexity in
>> understanding how the configuration is assembled and how mappings are
>> applied.
>>
>> The next resource we have is the existing authentication-configuration,
>> this is effectively a single client side authentication policy for an
>> outbound connection.
>>
>> I think from an end users perspective it is clearer to visualise a 1:1
>> relationship between the resource defining the outbound connection and the
>> resource defining the authentication policy.  From a tooling perspective as
>> these are linked by capabilities a user doesn't even need to fully see the
>> separation, e.g. as you edited a datasource the console could offer an
>> option to edit the authentication-configuration which could open without
>> forcing the user to navigate to a different location in the model hierarchy.
>>
>> We would need to look into more detail as to the suitability of this
>> resource and exactly how we would integrate it but this would generally be
>> my preferred starting point over trying to replicate expression expansion.
>>
>>
>>>
>>>   - If purpose is to really treat different arguments as security
>>>> sensitive then proposed encryption/decryption way seems promising to
>>>> me.
>>>>
>>>> On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
>>>> <darran.lofthouse at jboss.com> wrote:
>>>> >
>>>> > 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.html
>>>> >
>>>> > 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.
>>>> > _______________________________________________
>>>> > wildfly-dev mailing list
>>>> > wildfly-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> wildfly-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>
>>>
>>> --
>>> Brian Stansberry
>>> Manager, Senior Principal Software Engineer
>>> Red Hat
>>>
>>

-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181218/02f4f8b5/attachment.html 

From darran.lofthouse at redhat.com  Wed Dec 19 06:25:40 2018
From: darran.lofthouse at redhat.com (Darran Lofthouse)
Date: Wed, 19 Dec 2018 11:25:40 +0000
Subject: [wildfly-dev] WildFly Elytron - Credential Store - Next Stages
In-Reply-To: <CAPhbRDYGyo0tH0jSJ_GNr37DJKqt89DU4WzJQNezo1ue2Me41g@mail.gmail.com>
References: <CAMxVf4N9ShAjMZ=NSFzAHtf96KWrPR-7gMWzA2XMa9wjryQ4xg@mail.gmail.com>
	<CAAJBDTBnuafWTKQ47RYtFVvEYs0hGngwd6p2ynUjpKFVzHBetg@mail.gmail.com>
	<CAPhbRDYc=RxyBXk87i378e_Cvzeq4Ji6wTeykCEmM4gd76UojQ@mail.gmail.com>
	<CAMxVf4OZ4NA_UBP9L+vgjVxek1baqfkSzLY+BbHh63Rxz79XPA@mail.gmail.com>
	<CAMxVf4PdXmCQ5NeC=rYLYzCpug1d=wFnKtsRQBWg_gxmOfehFw@mail.gmail.com>
	<CAPhbRDYGyo0tH0jSJ_GNr37DJKqt89DU4WzJQNezo1ue2Me41g@mail.gmail.com>
Message-ID: <CAMxVf4OqmMomD1E8Z+_29zj9jqJ=97-2w9v3v8xhB+asq4C==g@mail.gmail.com>

Hi Brian.

I think approximately yes, the vault was intended for storing passwords
then was used for storing other things as well, the credential store is the
evolution of the vault but is truly about passwords only.  The next stage I
am proposing is a complete client side authentication policy which achieves
the pairing that went into the vault but also an awful lot more.

Regards,
Darran Lofthouse.


On Tue, Dec 18, 2018 at 9:51 PM Brian Stansberry <
brian.stansberry at redhat.com> wrote:

> Sorry for the slow reply.
>
> This last post sounds quite a bit like the vault. But with an updated
> API/SPI and a much richer possible set of behavior. And instead of using
> expression resolution for access, which has the negative of making it
> theoretically usable for pretty much any attribute, but with the system not
> really knowing how it is being used, there is proper capability-based
> integration. Is that a fair read on this?
>
> On Fri, Dec 7, 2018 at 7:16 AM Darran Lofthouse <
> darran.lofthouse at redhat.com> wrote:
>
>> Following on from my last e-mail this brings us to a follow on step for
>> the users that are looking to externalise both their username and
>> credential configuration together.
>>
>> Within the Elytron subsystem I can now add a new
>> 'authentication-client-file' resource to load static definitions from file,
>> as static definitions these will not be manageable.  By using child
>> resources however I can still hook these into capabilities to make them
>> referenceable.
>>
>> By loading from file we could also consider a couple of additional
>> options such as encrypting the file, we could also consider bundling within
>> a jar allowing other resources such as keytabs and certificates to be
>> bundled with the configuration.
>>
>> After this stage we then have further possibilities to expand on this
>> further.
>>
>> We could add a custom authentication-client resolver SPI to allow for
>> custom resolvers, anyone who wants to resolve from custom locations could
>> add their own implementation.  In hosted environments such as OpenShift
>> custom resolvers could be used to obtain authentication policies being
>> managed elsewhere without relying on property expansion.
>>
>> Additionally by having all of this wrapped in an API we have the ability
>> to add both auditing and authorization for anything accessing this
>> configuration - something that is not possible in solutions that rely on
>> expression expansion.
>>
>> Regards,
>> Darran Lofthouse.
>>
>>
>>
>> On Fri, 7 Dec 2018, 11:32 Darran Lofthouse <darran.lofthouse at redhat.com
>> wrote:
>>
>>>
>>> On Fri, Dec 7, 2018 at 1:34 AM Brian Stansberry <
>>> brian.stansberry at redhat.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <mchoma at redhat.com> wrote:
>>>>
>>>>> A few thoughts:
>>>>>
>>>>> Real Time Updates
>>>>>   - Runtime changes in era of OpenShift become less and less important
>>>>> as configuration should be immutable. Runtime changes should be
>>>>> addressed on OpenShift level. At least in past some of my "runtime
>>>>> changes" issues were denied with this argument.
>>>>>
>>>>
>>>> This is certainly something to consider when considering any new
>>>> management functionality.
>>>>
>>>> Another thing to consider is what services are going to utilize any
>>>> real-time update? Are there many resources that respond to a credential
>>>> attribute value change (e.g. write-attribute) without triggering
>>>> reload-required? If they do trigger reload-required it seems likely that's
>>>> because making a new value take effect was considered to be too difficult
>>>> compared to the gain. In an immutable world the gain is likely even less.
>>>>
>>>
>>> Yes the real time updates could only ever be approached on a resource by
>>> resource basis so existing resources (at least we have a finite set to
>>> consider) would either need to already update real time password updates or
>>> be retrospectively modified to support them - for the credential store the
>>> best we can do it make this a possibility.
>>>
>>>
>>>>   - If this will be decided to accomplish I think it is enough when
>>>>> updates take in action on explicit administrator command.
>>>>>
>>>>> Support for Expressions
>>>>>   - Really question here is if vault wasn't misused as external
>>>>> configuration storage for standalone.xml holding environment
>>>>> properties on one place. Which could be more convenient as specifying
>>>>> bunch of system properties. If so we should address this feature
>>>>> separately - way to specify configuration property file for server
>>>>> standalone.xml.
>>>>>
>>>>
>>>> I hope people aren't using a vault just for that. If you want to group
>>>> together properties you can use bin/standalone.sh -P.  On OpenShift you can
>>>> mount a ConfigMap as a source of env var values, and env vars are used in
>>>> expression resolution.
>>>>
>>>> I could imagine people sticking a username in a vault just because they
>>>> put the password in the vault and administratively it was simpler to manage
>>>> the two related values together. No idea if that's really done; I just can
>>>> imagine it. ;)
>>>>
>>>
>>> Rather than focusing on the management side of the credential store and
>>> features like real time updates it feels to me that emphasis should be on
>>> this username / password problem - any enhancements in this area having a
>>> better chance for long term relevance.
>>>
>>> As I have mentioned previously we know we have some resources that only
>>> require a credential, such as unlocking a local KeyStore.
>>>
>>> The username / password pairing is a common issue - we don't really have
>>> a clean solution for this yet so would be a good area to focus.
>>>
>>> However a number of newer authentication mechanisms have moved beyond
>>> the traditional username / password combo, some need an alternative to a
>>> password, some don't need a username at all.  These also often have an
>>> option to delegate the callers identity to the remote endpoint etc...
>>>
>>> Better solving these last two would seem to be a better investment of
>>> effort, regardless of how static future configurations do or do not become
>>> this would still be relevant.
>>>
>>> We already have the client side authentication context which provides a
>>> very flexible configuration selection approach based on the endpoint being
>>> connected to and additional information available as the connection is
>>> requested.  Whilst very flexible this does add a level of complexity in
>>> understanding how the configuration is assembled and how mappings are
>>> applied.
>>>
>>> The next resource we have is the existing authentication-configuration,
>>> this is effectively a single client side authentication policy for an
>>> outbound connection.
>>>
>>> I think from an end users perspective it is clearer to visualise a 1:1
>>> relationship between the resource defining the outbound connection and the
>>> resource defining the authentication policy.  From a tooling perspective as
>>> these are linked by capabilities a user doesn't even need to fully see the
>>> separation, e.g. as you edited a datasource the console could offer an
>>> option to edit the authentication-configuration which could open without
>>> forcing the user to navigate to a different location in the model hierarchy.
>>>
>>> We would need to look into more detail as to the suitability of this
>>> resource and exactly how we would integrate it but this would generally be
>>> my preferred starting point over trying to replicate expression expansion.
>>>
>>>
>>>>
>>>>   - If purpose is to really treat different arguments as security
>>>>> sensitive then proposed encryption/decryption way seems promising to
>>>>> me.
>>>>>
>>>>> On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
>>>>> <darran.lofthouse at jboss.com> wrote:
>>>>> >
>>>>> > 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.html
>>>>> >
>>>>> > 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.
>>>>> > _______________________________________________
>>>>> > wildfly-dev mailing list
>>>>> > wildfly-dev at lists.jboss.org
>>>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>
>>>>
>>>> --
>>>> Brian Stansberry
>>>> Manager, Senior Principal Software Engineer
>>>> Red Hat
>>>>
>>>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181219/0a15d9c5/attachment-0001.html