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

On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <fjuma(a)redhat.com&gt; wrote: > 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. > Right. It does not change the permission-mappings, they remain to be a list of items with no identity. Which is the fundamental problem. Thanks, Alexey Thanks, > Farah > > On Fri, Mar 23, 2018 at 11:55 AM, Alexey Loubyansky < > alexey.loubyansky(a)redhat.com&gt; 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/brows >> e/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 >> > >