[wildfly-dev] problems with the Elytron permission-mapping config model

[Darran Lofthouse]

I think at the moment it is fair to say the issue manipulating the default
configuration is understood and agreed, a very minor change from an
administrator can prevent further automated modifications and the
modifications that are made need to duplicated as the current default
configuration.

We do have a proposal to move the default permissions into a new resource
permission-set which will be referenced by the mapper, this will be a
resource that is addressable by name.  As subsystems are added to the
server this will be the single place to add the permissions, as subsystems
are removed this will be the single resource to remove the permission
from.

If an administrator has chosen to use their own permission mappings instead
of this permission set then they will not be affected by any automated
updates.

The change we have proposed will also be compatible with previous versions
using transformers as we can just in-line these permission sets in the
transformed model.

We have been at this stage a couple of times but although we have an option
to provide a single named resource that can be manipulated by patching this
does not seem to be sufficient - I think that is where the sticking point
is in achieving a solution for this.

Regards,
Darran Lofthouse.


On Fri, 23 Mar 2018 at 15:55 Alexey Loubyansky <alexey.loubyansky at redhat.com>
wrote:

> While this is addressed mainly to the Elytron team, it seems like we would
> appreciate opinions from other colleagues since we are basically stuck
> discussing possible ways to resolve
> https://issues.jboss.org/browse/WFCORE-3596
>
> The description in the jira is pretty brief assuming people know what that
> is about, since it's been raised before multiple times. Here is what it is
> about fundamentally.
>
> If a configuration model (of a subsystem or any other component) includes
> a list of configurable units (let's assume XML elements for simplicity)
> that don't have any identity (unique id/name/path/etc) this is a big
> problem for supporting patching and version updates preserving user
> configuration changes. Or simply customizing the default config model using
> a tool. By a big problem I mean it's simply not going to work reliably.
>
> As a simple exercise that demonstrates the issue, imagine you have two
> configs each of which includes a list of these configurable units that have
> no identity. Now try to identify the difference between the two lists. Or
> merge them with one overwriting the other. Basically components w/o an
> identity can not be manipulated. You can only add them but not modify or
> even remove (unless their index in the list is a constant value of course).
>
> I don't think I've seen any issue of this kind in our (WF/EAP) configs
> except for the Elytron's permission-mapping's. (If somebody knows such
> components please let me know).
> If I misunderstand the Elytron config model or approaching this from a
> wrong angle, please let me know.
>
> Question for the Elytron team: is the problem I am describing clear? Do
> you admit it as a problem?
>
> Thanks,
> Alexey
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180323/a91f78cf/attachment.html