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

[Darran Lofthouse]

Why would the permission-mapping resource need to be modified by tooling?

The purpose of the named permission-set is that that becomes the resource
automatically manipulated, the permission mappings should not need to be
manipulated as they either will or will not already reference the
permission-set and that should be automatically changed.

Regards,
Darran Lofthouse.


On Fri, 23 Mar 2018 at 17:21 Farah Juma <fjuma at redhat.com> 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.
>
> 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/5ee2f289/attachment-0001.html