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

[Darran Lofthouse]

Ok so lets switch this another way.

If the addition from other subsystems was to be eliminated is there still a
provisioning issue?


On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <brian.stansberry at redhat.com>
wrote:

> On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <
> darran.lofthouse at jboss.com> wrote:
>
>> 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.
>>
>
> Is your question why is it a problem to give these things an identity? If
> so, I have the same question, although I don't think Alexey's the one to
> come up with the identity.
>
> Or is your question why is not having an identity a problem? If so, is it
> correct to say that getting rid of this bit of wrongness is the problem:
>
>
> https://github.com/wildfly/wildfly-core/blob/master/elytron/src/main/resources/subsystem-templates/elytron.xml#L125
>
> Basically right there elytron is speculatively providing configuration
> rightly owned by other subsystems. To do this correctly, each of those
> permissions should be part of the config established by other parts of the
> system. The provisioning tool is expected to do it correctly. And doing
> that requires some sort of identity for each item in the set. . Installing
> a feature should involve adding independent, identifiable chunks of config,
> not manipulating an attribute of some chunk of config owned by a different
> feature. Manipulating an attribute is not feasible and isn't correct.
>
>
>>
>>>
>>> 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
>>>>>
>>>>
>>>>
>> _______________________________________________
>> wildfly-dev mailing list
>> wildfly-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>
>
> --
> Brian Stansberry
> Manager, Senior Principal Software Engineer
> Red Hat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180327/d897f6b8/attachment-0001.html