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

[Farah Juma]

A solution to part of the problem mentioned in WFCORE-3596 that was
discussed is to introduce the concept of named permission sets. In
particular, instead of having a permission-mapping reference permissions,
it would instead reference named permission-sets. This would allow the
provisioning tool to be able to add/remove permissions to/from a default
permission-set based on the presence/absence of a specific subsystem when
generating the default configuration. However, as Alexey pointed out, this
doesn't solve the problem of knowing which permission-mapping a
permission-set should be added to when attempting to preserve user
configuration changes for patching, version updates, etc.

Thanks,
Farah

On Fri, Mar 23, 2018 at 11:55 AM, 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/357d96a7/attachment.html