problems with the Elytron permission-mapping config model

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

problems with the Elytron permission-mapping config model

Alexey Loubyansky
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Darran Lofthouse
I think at the moment it is fair to say the issue manipulating the default configuration is understood and agreed, a very minor change from an administrator can prevent further automated modifications and the modifications that are made need to duplicated as the current default configuration.

We do have a proposal to move the default permissions into a new resource permission-set which will be referenced by the mapper, this will be a resource that is addressable by name.  As subsystems are added to the server this will be the single place to add the permissions, as subsystems are removed this will be the single resource to remove the permission from.  

If an administrator has chosen to use their own permission mappings instead of this permission set then they will not be affected by any automated updates.

The change we have proposed will also be compatible with previous versions using transformers as we can just in-line these permission sets in the transformed model.

We have been at this stage a couple of times but although we have an option to provide a single named resource that can be manipulated by patching this does not seem to be sufficient - I think that is where the sticking point is in achieving a solution for this.

Regards,
Darran Lofthouse.


On Fri, 23 Mar 2018 at 15:55 Alexey Loubyansky <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Farah Juma
In reply to this post by Alexey Loubyansky
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Alexey Loubyansky
In reply to this post by Farah Juma
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Alexey Loubyansky
BTW, I want to highlight an important point here. I don't care about how it will look like in the XML. It may remain this list in the XML. What I care about is how it appears in the domain management model and its description.

Thanks,
Alexey

On Fri, Mar 23, 2018 at 6:49 PM, Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Darran Lofthouse
In reply to this post by Alexey Loubyansky
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Brian Stansberry


On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <[hidden email]> wrote:
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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:


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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Alexey Loubyansky
In reply to this post by Alexey Loubyansky
Apparently all your responses to this thread Darran didn't show up in my view of the thread. No idea why. If not Brian's response to your email I wouldn't have found out that.

Copying your email from the list archive:

"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."

It doesn't work like that. It's not like "you can manage this part of the config and this part should be left out".
About the permission-mappings and why this list is a problem. We need to be able to compute a diff between two Elytron subsystem configs. They may match, may be slightly different, may be completely different. To do that we need to be able to identify comparable pieces the config consists of. Named permission-sets are no problem. Now I get to the list of permission-mappings, as it is a part of the Elytron's subsystem config. How can I compare these lists?
Well, naturally a list is a collection of items in a specific order. So what I am going to do is assume that I should be comparing the items in the order they appear in two lists. And generate the diff based on that order. Which in some cases will be useless. The thing is that, I will not only be calculating the diff I will also be applying it to the config. In some cases the result will be pretty much unexpected. Does it make any sense to you?

Thanks,
Alexey

On Fri, Mar 23, 2018 at 6:49 PM, Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Martin Choma
In reply to this post by Alexey Loubyansky
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/mechanism-realm-configurations
http-authentication-factory/mechanism-configurations
http-authentication-factory/mechanism-configurations/mechanism-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
<[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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/mechanism-realm-configurations
http-authentication-factory/mechanism-configurations
http-authentication-factory/mechanism-configurations/mechanism-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
<[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Darran Lofthouse-2
In reply to this post by Brian Stansberry
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 <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <[hidden email]> wrote:
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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:


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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Alexey Loubyansky
In reply to this post by Brian Stansberry
On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse <[hidden email]> wrote:
Ok so lets switch this another way.

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

The provisioning issue is related to the structure of the configuration model (to be more precise the representation of the resource in the domain management model since this is what is being manipulated). There are other examples of subsystems requiring configuration of other features, e.g. some subsystems may require specific socket-bindings. There is no problem with that from the provisioning perspective because the model allows to check whether the required socket-binding is already present in the config, whether its parameters need any adjustments and if the socket-binding is missing from the config it can be added.

Thanks,
Alexey
 

On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <[hidden email]> wrote:
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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:


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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Darran Lofthouse-2
The part that I am still missing is if we remove the need to manipulate an ordered list as other subsystems are added and removed how is the presence of the ordered list still an issue?  I am sure we have other examples of ordered lists out there.

Darran.


On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse <[hidden email]> wrote:
Ok so lets switch this another way.

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

The provisioning issue is related to the structure of the configuration model (to be more precise the representation of the resource in the domain management model since this is what is being manipulated). There are other examples of subsystems requiring configuration of other features, e.g. some subsystems may require specific socket-bindings. There is no problem with that from the provisioning perspective because the model allows to check whether the required socket-binding is already present in the config, whether its parameters need any adjustments and if the socket-binding is missing from the config it can be added.

Thanks,
Alexey
 

On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <[hidden email]> wrote:
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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:


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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Alexey Loubyansky
On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse <[hidden email]> wrote:
The part that I am still missing is if we remove the need to manipulate an ordered list as other subsystems are added and removed how is the presence of the ordered list still an issue?  I am sure we have other examples of ordered lists out there.

Actually, mainly in Elytron. The list in itself is not an issue, the identity of the items is. If there is a list that can be modified by various parties (end user, as a consequence of integration of other components, etc) there is a problem of merging these modifications or even identifying them in terms which items changed and how. Identifying user changes since the last official update (with the goal to preserve them after the next update) becomes a problem as well.
 
Alexey


Darran.


On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse <[hidden email]> wrote:
Ok so lets switch this another way.

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

The provisioning issue is related to the structure of the configuration model (to be more precise the representation of the resource in the domain management model since this is what is being manipulated). There are other examples of subsystems requiring configuration of other features, e.g. some subsystems may require specific socket-bindings. There is no problem with that from the provisioning perspective because the model allows to check whether the required socket-binding is already present in the config, whether its parameters need any adjustments and if the socket-binding is missing from the config it can be added.

Thanks,
Alexey
 

On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <[hidden email]> wrote:
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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:


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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Darran Lofthouse-2
How do you cope with things like a login module stack in the security subsystem?  That is also ordered where the order has a very specific meaning.  I haven't checked the configuration recently but doesn't configuration for jgroups also handle the configuration in an ordered way that an administrator could choose to modify?

The proposal we have so far is to remove the need for the manipulation of permissions in the ordered list as other subsystems are added / removed - at this point the remaining config in the permission mapper should either match the default we ship or if it is modified this should be as a result of administrator action so should be preserved as is.

The problem we have with the resource now is it must be preserved for backwards compatibility.  Broadly this means we have the following two requirements: -
 1 - Any changes we make must be transformable to the prior version of the resource.
 2 - XML configuration for a prior version of the resource must be convertible to the new version.

Alternatively we could redesign a new resource from scratch to provide model based permission mapping but a redesign from scratch is unlikely to completely cover #1 and #2 so we could end up with a deprecated resource which is not immediately removable although if we can achieve #1 removal possibly could be faster.

But is all this necessary at the moment?  Especially as at the moment we do have a proposal that moves the permissions we know need to be updated to an identifiable resource.

Darran.


On Tue, 27 Mar 2018 at 12:45 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse <[hidden email]> wrote:
The part that I am still missing is if we remove the need to manipulate an ordered list as other subsystems are added and removed how is the presence of the ordered list still an issue?  I am sure we have other examples of ordered lists out there.

Actually, mainly in Elytron. The list in itself is not an issue, the identity of the items is. If there is a list that can be modified by various parties (end user, as a consequence of integration of other components, etc) there is a problem of merging these modifications or even identifying them in terms which items changed and how. Identifying user changes since the last official update (with the goal to preserve them after the next update) becomes a problem as well.
 
Alexey


Darran.


On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse <[hidden email]> wrote:
Ok so lets switch this another way.

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

The provisioning issue is related to the structure of the configuration model (to be more precise the representation of the resource in the domain management model since this is what is being manipulated). There are other examples of subsystems requiring configuration of other features, e.g. some subsystems may require specific socket-bindings. There is no problem with that from the provisioning perspective because the model allows to check whether the required socket-binding is already present in the config, whether its parameters need any adjustments and if the socket-binding is missing from the config it can be added.

Thanks,
Alexey
 

On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <[hidden email]> wrote:
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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:


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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Alexey Loubyansky
On Tue, Mar 27, 2018 at 2:06 PM, Darran Lofthouse <[hidden email]> wrote:
How do you cope with things like a login module stack in the security subsystem?  That is also ordered where the order has a very specific meaning.  I haven't checked the configuration recently but doesn't configuration for jgroups also handle the configuration in an ordered way that an administrator could choose to modify?

They (login module stack and jgroup's protocol stack) are different in that every item on the stack has an identity. So I can see whether an item has been removed, modified or a new one added. I can't see how I can do that with the permission-mapping. This is my main problem at the moment.

About the ordered collections in general, yes, there is an issue. Like you mentioned, for a start the order can be pre-defined (it can later be re-defined although that appears to be not as easy as it should be). This is actually how it currently works.

The proposal we have so far is to remove the need for the manipulation of permissions in the ordered list as other subsystems are added / removed - at this point the remaining config in the permission mapper should either match the default we ship or if it is modified this should be as a result of administrator action so should be preserved as is.

Right, I get that. The thing is that if it is modified, it has to be fully re-defined, meaning it's not a fine-grained adjustment. Because if you want to add another permission (or the named permission-set) how to can the target permission-mapping be determined?
 
The problem we have with the resource now is it must be preserved for backwards compatibility.  Broadly this means we have the following two requirements: -
 1 - Any changes we make must be transformable to the prior version of the resource.
 2 - XML configuration for a prior version of the resource must be convertible to the new version.

The good thing is that XML is not what is being manipulated, the representation of the resource in the domain management model is. Not meaning it gives a complete freedom but it's a good thing.
 
Alternatively we could redesign a new resource from scratch to provide model based permission mapping but a redesign from scratch is unlikely to completely cover #1 and #2 so we could end up with a deprecated resource which is not immediately removable although if we can achieve #1 removal possibly could be faster.

But is all this necessary at the moment?  Especially as at the moment we do have a proposal that moves the permissions we know need to be updated to an identifiable resource.

What about the permission-mapping? Are there plans to do anything with them?

To me, it depends on what you mean by "at the moment". If you mean whether the changes need to be implemented and usable in a few weeks, no. But I think not giving it a priority now is a bad thing, because as you wrote above then we have to support the structure which limits the ability to customize the default configs, perform integration, updates and preserving user changes.

Thanks,
Alexey
 

Darran.


On Tue, 27 Mar 2018 at 12:45 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse <[hidden email]> wrote:
The part that I am still missing is if we remove the need to manipulate an ordered list as other subsystems are added and removed how is the presence of the ordered list still an issue?  I am sure we have other examples of ordered lists out there.

Actually, mainly in Elytron. The list in itself is not an issue, the identity of the items is. If there is a list that can be modified by various parties (end user, as a consequence of integration of other components, etc) there is a problem of merging these modifications or even identifying them in terms which items changed and how. Identifying user changes since the last official update (with the goal to preserve them after the next update) becomes a problem as well.
 
Alexey


Darran.


On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse <[hidden email]> wrote:
Ok so lets switch this another way.

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

The provisioning issue is related to the structure of the configuration model (to be more precise the representation of the resource in the domain management model since this is what is being manipulated). There are other examples of subsystems requiring configuration of other features, e.g. some subsystems may require specific socket-bindings. There is no problem with that from the provisioning perspective because the model allows to check whether the required socket-binding is already present in the config, whether its parameters need any adjustments and if the socket-binding is missing from the config it can be added.

Thanks,
Alexey
 

On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <[hidden email]> wrote:
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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:


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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Darran Lofthouse-2
I think this takes us all back to the start.

Why do you need to be modifying the simple-permission-mapper resource.

The proposed changes are to give you a named resource that can be safely manipulated without the simple-permission-mapper needing to be touched at all.

On Tue, 27 Mar 2018 at 16:37 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 2:06 PM, Darran Lofthouse <[hidden email]> wrote:
How do you cope with things like a login module stack in the security subsystem?  That is also ordered where the order has a very specific meaning.  I haven't checked the configuration recently but doesn't configuration for jgroups also handle the configuration in an ordered way that an administrator could choose to modify?

They (login module stack and jgroup's protocol stack) are different in that every item on the stack has an identity. So I can see whether an item has been removed, modified or a new one added. I can't see how I can do that with the permission-mapping. This is my main problem at the moment.

Isn't there a way for an equality check to be performed?  In the case of the login module stacks once modules have been added or removed it is no longer safe for you to make changes to that stack - this resource is no different.
 

About the ordered collections in general, yes, there is an issue. Like you mentioned, for a start the order can be pre-defined (it can later be re-defined although that appears to be not as easy as it should be). This is actually how it currently works.

The proposal we have so far is to remove the need for the manipulation of permissions in the ordered list as other subsystems are added / removed - at this point the remaining config in the permission mapper should either match the default we ship or if it is modified this should be as a result of administrator action so should be preserved as is.

Right, I get that. The thing is that if it is modified, it has to be fully re-defined, meaning it's not a fine-grained adjustment. Because if you want to add another permission (or the named permission-set) how to can the target permission-mapping be determined?

Why do you need to know this?  The proposed change is so you can just modify the permission-set - once the administrator updates the simple-permission-mapper they have taken ownership of that resource and we should not be automating any further changes to it.
 
 
The problem we have with the resource now is it must be preserved for backwards compatibility.  Broadly this means we have the following two requirements: -
 1 - Any changes we make must be transformable to the prior version of the resource.
 2 - XML configuration for a prior version of the resource must be convertible to the new version.

The good thing is that XML is not what is being manipulated, the representation of the resource in the domain management model is. Not meaning it gives a complete freedom but it's a good thing.

Yes but my point is we can not choose to simplify the resource as we still have to support the various permutations that could have been represented in XML against the previous version.
 
 
Alternatively we could redesign a new resource from scratch to provide model based permission mapping but a redesign from scratch is unlikely to completely cover #1 and #2 so we could end up with a deprecated resource which is not immediately removable although if we can achieve #1 removal possibly could be faster.

But is all this necessary at the moment?  Especially as at the moment we do have a proposal that moves the permissions we know need to be updated to an identifiable resource.

What about the permission-mapping? Are there plans to do anything with them?

The plan is to update the simple-permission-mapper so the permission-mapping can map to a permission-set instead of containing the permission names directly.

To me, it depends on what you mean by "at the moment". If you mean whether the changes need to be implemented and usable in a few weeks, no. But I think not giving it a priority now is a bad thing, because as you wrote above then we have to support the structure which limits the ability to customize the default configs, perform integration, updates and preserving user changes.

I would propose we go ahead and add the new permission-set resource and update the simple-permission-mapper so these can be referenced instead of listing the permission classes.

Based on the default configuration we ship we can then restructure the configuration so you have a single named resource to add and remove the permissions as appropriate where order is not relevant.

We can then look as a separate RFE at redefining permission mapping, which could mean tweaks to the existing resource or could even consider some clean designs and deprecate the current resource if we think that makes sense.
 

Thanks,
Alexey
 

Darran.


On Tue, 27 Mar 2018 at 12:45 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 1:23 PM, Darran Lofthouse <[hidden email]> wrote:
The part that I am still missing is if we remove the need to manipulate an ordered list as other subsystems are added and removed how is the presence of the ordered list still an issue?  I am sure we have other examples of ordered lists out there.

Actually, mainly in Elytron. The list in itself is not an issue, the identity of the items is. If there is a list that can be modified by various parties (end user, as a consequence of integration of other components, etc) there is a problem of merging these modifications or even identifying them in terms which items changed and how. Identifying user changes since the last official update (with the goal to preserve them after the next update) becomes a problem as well.
 
Alexey


Darran.


On Tue, 27 Mar 2018 at 12:15 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 12:34 PM, Darran Lofthouse <[hidden email]> wrote:
Ok so lets switch this another way.

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

The provisioning issue is related to the structure of the configuration model (to be more precise the representation of the resource in the domain management model since this is what is being manipulated). There are other examples of subsystems requiring configuration of other features, e.g. some subsystems may require specific socket-bindings. There is no problem with that from the provisioning perspective because the model allows to check whether the required socket-binding is already present in the config, whether its parameters need any adjustments and if the socket-binding is missing from the config it can be added.

Thanks,
Alexey
 

On Fri, 23 Mar 2018 at 20:52 Brian Stansberry <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 12:56 PM, Darran Lofthouse <[hidden email]> wrote:
On Fri, 23 Mar 2018 at 17:50 Alexey Loubyansky <[hidden email]> wrote:
On Fri, Mar 23, 2018 at 6:20 PM, Farah Juma <[hidden email]> 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:


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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Alexey Loubyansky
On Tue, Mar 27, 2018 at 6:01 PM, Darran Lofthouse <[hidden email]> wrote:
I think this takes us all back to the start.

Why do you need to be modifying the simple-permission-mapper resource.

Because users will probably need to. Two use-cases.

1) I don't want to install the default distribution with its configs and then start customizing it (given the complexity, in general, that is not a trivial and safe exercise especially if you are doing it manually). I want to install the already customized version (which is validated by the tool). Hopefully, I won't need to modify the simple-permission-mapper but what if I do want to?

2) I have my customized installation, there is a new compatible version available. I want to upgrade but don't want to do the config-customizing exercise again, i.e. i want my existing customizations to be preserved after the update. For that the tool needs to be able to identify my customizations that can be (re-)applied to the new version (assuming it is a compatible release). Now if I added a permission-set to one of the permission-mappings in the previous version, the tool won't be able to do a fine-grained diff that can be re-applied.

The answer to both, and this is what you imply by saying that once an administrator touched it it shouldn't be changed by anything else, this part of the config is an atomic unit which has to be configured in its entirety whenever you want any change in it.

Alexey

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: problems with the Elytron permission-mapping config model

Darran Lofthouse-2
Yes, once the administrator has modified the value for that single attribute the entire value for that attribute should be transferred over - the tooling should not be attempting to merge two attribute values into one.


On Tue, 27 Mar 2018 at 18:49 Alexey Loubyansky <[hidden email]> wrote:
On Tue, Mar 27, 2018 at 6:01 PM, Darran Lofthouse <[hidden email]> wrote:
I think this takes us all back to the start.

Why do you need to be modifying the simple-permission-mapper resource.

Because users will probably need to. Two use-cases.

1) I don't want to install the default distribution with its configs and then start customizing it (given the complexity, in general, that is not a trivial and safe exercise especially if you are doing it manually). I want to install the already customized version (which is validated by the tool). Hopefully, I won't need to modify the simple-permission-mapper but what if I do want to?

2) I have my customized installation, there is a new compatible version available. I want to upgrade but don't want to do the config-customizing exercise again, i.e. i want my existing customizations to be preserved after the update. For that the tool needs to be able to identify my customizations that can be (re-)applied to the new version (assuming it is a compatible release). Now if I added a permission-set to one of the permission-mappings in the previous version, the tool won't be able to do a fine-grained diff that can be re-applied.

The answer to both, and this is what you imply by saying that once an administrator touched it it shouldn't be changed by anything else, this part of the config is an atomic unit which has to be configured in its entirety whenever you want any change in it.

Alexey

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev