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

[Darran Lofthouse]

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

> On Fri, Mar 23, 2018 at 6:20 PM, 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.
>>
>
> Right. It does not change the permission-mappings, they remain to be a
> list of items with no identity. Which is the fundamental problem.
>

But why is that a problem? I think that is the piece still missing.

By moving the list of the permissions into a single named resource the
tooling no longer has a need to be performing the manipulation within the
simple permission mapper so that can be left to the administrator to look
after independently.


>
> Thanks,
> Alexey
>
> 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/4b49e290/attachment-0001.html