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

[Alexey Loubyansky]

Hi Martin,

thanks for the list. Right, some of those suffer from the same problem and
some seem to have an identity (not explicitly expressed since we don't have
a way to do that for a member of a complex type yet but once we do it won't
be a problem).

Ok, I had a hope we were going to address these relatively quick (given
that the issue was raised back in autumn). I don't see it happening next
month neither. So for now I am going to handle these kind of config
structures (i.e. lists of complex types) as atomic pieces (although
potentially big). They won't be mergeable during updates but one will be
replacing completely the other with the one coming in last winning.

In perspective though, I think this is going to remain a critical issue.

Thanks,
Alexey

On Mon, Mar 26, 2018 at 2:40 PM, Martin Choma <mchoma at redhat.com> wrote:

> I run through Elytron subsystem and there are other "suspicious"
> resources [1]. How it is guaranteed name/id/path attributes of
> collections are unique identifiers? On subsystem code level? Because
> this information is not in the model, as far as I know.
>
> Is it possible to declare compound unique-key? I mean for example to
> say that for permission resource (class-name,module) tuple is unique
> key.
>
> [1]
> configurable-sasl-server-factory/filters
> configurable-http-server-mechanism-factory/filters
>
> sasl-authentication-factory/mechanism-configurations
> sasl-authentication-factory/mechanism-configurations/mechani
> sm-realm-configurations
> http-authentication-factory/mechanism-configurations
> http-authentication-factory/mechanism-configurations/mechani
> sm-realm-configurations
>
> mechanism-provider-filtering-sasl-server-factory/filters
>
> ldap-realm/identity-mapping/attribute-mapping
> jdbc-realm/principal-query
> jdbc-realm/principal-query/attribute-mapping
>
> security-domain/realms
>
> On Fri, Mar 23, 2018 at 4:55 PM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180326/b152be02/attachment.html