On Sep 27, 2016, at 9:47 AM, Darran Lofthouse <darran.lofthouse(a)jboss.com&gt; wrote: I have received the following request regarding the hierarchy of the Elytron subystem so just wanted to get some additional opinions: - https://issues.jboss.org/browse/WFLY-7190 The Elytron subsystem is implemented by having a number of different capabilities that are then chained together in the model to expose four / five capabilities that are then used across the application server to access security related services. https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/e... The reason for following the capability approach along with a component assembly approach to assembling the configuration is so that we are ready for other subsystems to be added to the server potentially providing their own implementations of these capabilities. For our capabilities we have one or more resource definitions making it possible to configure different implementations of the capabilities whilst having the configuration fully described in the model unlike the previous map approach for login modules. So the general problem is how should an administrator be able to see the resources by type. Within the admin console Claudio it looking at a tabbed interface where different tabs can contain different resources so that seems to be reasonably covered. Within the CLI however an administrator is just presented by all resource types within the subsystem when they use tab completion. One option could be for us to introduce an arbitrary layer in the subsystem and group our resources, e.g. /subsystem=elytron/component=name-rewriter/ /subsystem=elytron/component=security-realm/

But before taking that approach it feels as though this information is already there and there are possibly some other alternatives we could consider. Firstly I wonder if some of the read-* operations could have an opportunity to take into account capabilities of child resources to offer a filtered view?

Another possible option could be CLI commands e.g. add-name-rewriter, add-security-realm - not sure if that would be one way to give a better user experience.

Anyway just some random thoughts for the moment but wanted to open this up before jumping immediately to the artificial hierarchy solution. Regards, Darran Lofthouse. _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

Thanks Brian. I kind of think, even if we don't know the solution today but we do think usability is something we should handle in the admin tools then it will be better to leave the hierarchy as-is - alternatively if we felt this is insufficient information from the subsystem then modify the hierarchy there. In the documentation I want to add a structure similar to the grouping Claudio is using for HAL but generally if an administrator is looking to add a resource for a specific capability e.g. security-realm all resources will be listed together in the documentation. Another random CLI option: - Add an add-capability command relative to a point in the hierarchy. - capability would be a parameter which can tab complete based on capabilities at that point. - type can tab complete a much shorter list once we know the desired capability. - name the name the new resource will have. At that point additional parameters could tab complete as we know the resource type. Darran. On 27/09/16 16:59, Brian Stansberry wrote: > >> On Sep 27, 2016, at 9:47 AM, Darran Lofthouse < darran.lofthouse(a)jboss.com&gt; wrote: >> >> I have received the following request regarding the hierarchy of the >> Elytron subystem so just wanted to get some additional opinions: - >> >> https://issues.jboss.org/browse/WFLY-7190 >> >> The Elytron subsystem is implemented by having a number of different >> capabilities that are then chained together in the model to expose four >> / five capabilities that are then used across the application server to >> access security related services. >> >> https://github.com/wildfly-security-incubator/wildfly- capabilities/tree/elytron_integration/org/wildfly/security >> >> The reason for following the capability approach along with a component >> assembly approach to assembling the configuration is so that we are >> ready for other subsystems to be added to the server potentially >> providing their own implementations of these capabilities. >> >> For our capabilities we have one or more resource definitions making it >> possible to configure different implementations of the capabilities >> whilst having the configuration fully described in the model unlike the >> previous map approach for login modules. >> >> So the general problem is how should an administrator be able to see the >> resources by type. >> >> Within the admin console Claudio it looking at a tabbed interface where >> different tabs can contain different resources so that seems to be >> reasonably covered. >> >> Within the CLI however an administrator is just presented by all >> resource types within the subsystem when they use tab completion. >> >> One option could be for us to introduce an arbitrary layer in the >> subsystem and group our resources, e.g. >> >> /subsystem=elytron/component=name-rewriter/ >> /subsystem=elytron/component=security-realm/ >> > > So then > > /subsystem=elytron/component=name-rewriter/custom-name-rewriter=foo > /subsystem=elytron/component=security-realm/jdbc-realm=bar > > That’s not clearly a benefit; it may be worse. > > The point here is better navigation. So the user isn’t sure: > > /subsystem=elytron/<TAB> > > Now unless there are no normal children, you see whatever stuff remains at the top, and ‘component’. Picking a couple at random to provide an example > > component dir-context empty-role-decoder ... > > Now ‘component’ isn’t intuitive at all. But if the list is only 3-4 or less then maybe they guess it. Otherwise it is both obscure and buried amongst other things. > > /subsystem=elytron/component=<TAB> > > Now they get a more refined list, and there is some benefit > > name-writer security-realm … > > /subsystem=elytron/component=name-rewriter/<TAB> > > custom-name-rewriter constant-name-rewriter ….. > > And finally they get to > > /subsystem=elytron/component=name-rewriter/custom-name-rewriter > > That’s 2 extra tab completes (four if you count the extra ‘=‘ and ‘/‘ in the path), the decision that ‘component’ is what they want, and the recognition that the thing they want, a ‘custom-name-rewriter’ is a form of ‘name-rewriter’. > > So it’s dubious there is much of a gain. And of course for other use cases where people know what they want it’s added superfluous typing. > > A side benefit of the added level is it provides a place to describe the general characteristics of the component category in the read-resource-description output. > >> But before taking that approach it feels as though this information is >> already there and there are possibly some other alternatives we could >> consider. >> >> Firstly I wonder if some of the read-* operations could have an >> opportunity to take into account capabilities of child resources to >> offer a filtered view? >> > > So > > /subsystem=elytron:read-children-types(provided-capability=org.wildfly. elytron.name-rewriter) > > I’m not sure how much that helps. This call would be used by the CLI to feed tab completion, not the user. But somehow the CLI needs the value 'org.wildfly.elytron.name-rewriter’ and that cannot be inferred; it requires user input. > > Or > > /subsystem=elytron:read-children-resources(provided- capability=org.wildfly.elytron.name-rewriter) > > Here there’s some benefit but CLI would need to offer tab completion for 'provided-capability’. > > Before I’d want to invest energy in implementing that I’d like to see some concrete demand for that exact use case. It’s a pretty big jump from ‘the subsystem is too flat’ to “significant numbers of users will make use of this specific read-children-resources variant" > >> Another possible option could be CLI commands e.g. add-name-rewriter, >> add-security-realm - not sure if that would be one way to give a better >> user experience. >> > > This seems more direct. TBH though I’ve spent most of my thinking on my bits above and haven’t thought hard about this one. :) > >> Anyway just some random thoughts for the moment but wanted to open this >> up before jumping immediately to the artificial hierarchy solution. >> >> Regards, >> Darran Lofthouse. >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev

On Wed, Sep 28, 2016 at 9:53 AM, Harald Pehl <hpehl(a)redhat.com&gt; wrote: > More important to me is a logical grouping of resources which belong > together. This should be reflected in both the documentation and in HAL. This is the grouping I did, suggestions are welcome * Role Mapper add-prefix-role-mapper add-suffix-role-mapper aggregate-role-mapper constant-role-mapper custom-role-mapper logical-role-mapper * Decoder aggregate-principal-decoder concatenating-principal-decoder constant-principal-decoder custom-principal-decoder x500-attribute-principal-decoder custom-role-decoder empty-role-decoder simple-role-decoder * Factory aggregate-http-server-mechanism-factory aggregate-sasl-server-factory configurable-http-server-mechanism-factory configurable-sasl-server-factory custom-credential-security-factory http-authentication-factory kerberos-security-factory mechanism-provider-filtering-sasl-server-factory provider-http-server-mechanism-factory provider-sasl-server-factory sasl-authentication-factory service-loader-http-server-mechanism-factory service-loader-sasl-server-factory * Realm properties-realm filesystem-realm jdbc-realm ldap-realm key-store-realm aggregate-realm custom-modifiable-realm custom-realm custom-realm-mapper mapped-regex-realm-mapper simple-regex-realm-mapper * Rewriter aggregate-name-rewriter chained-name-rewriter constant-name-rewriter custom-name-rewriter regex-name-validating-rewriter regex-name-rewriter * Permission Mapper custom-permission-mapper logical-permission-mapper simple-permission-mapper * SSL key-managers key-store provider-loader server-ssl-context trust-managers * Security Domain security-domain security-property * LDAP Connection dir-context

From: "Darran Lofthouse" <darran.lofthouse(a)jboss.com&gt; To: "WildFly Dev" <wildfly-dev(a)lists.jboss.org&gt; Sent: Tuesday, September 27, 2016 4:47:06 PM Subject: [wildfly-dev] Subsystem Hierarchy I have received the following request regarding the hierarchy of the Elytron subystem so just wanted to get some additional opinions: - https://issues.jboss.org/browse/WFLY-7190 The Elytron subsystem is implemented by having a number of different capabilities that are then chained together in the model to expose four / five capabilities that are then used across the application server to access security related services. https://github.com/wildfly-security-incubator/wildfly-capabilities/tree/e... The reason for following the capability approach along with a component assembly approach to assembling the configuration is so that we are ready for other subsystems to be added to the server potentially providing their own implementations of these capabilities. For our capabilities we have one or more resource definitions making it possible to configure different implementations of the capabilities whilst having the configuration fully described in the model unlike the previous map approach for login modules. So the general problem is how should an administrator be able to see the resources by type. Within the admin console Claudio it looking at a tabbed interface where different tabs can contain different resources so that seems to be reasonably covered. Within the CLI however an administrator is just presented by all resource types within the subsystem when they use tab completion. One option could be for us to introduce an arbitrary layer in the subsystem and group our resources, e.g. /subsystem=elytron/component=name-rewriter/ /subsystem=elytron/component=security-realm/ But before taking that approach it feels as though this information is already there and there are possibly some other alternatives we could consider. Firstly I wonder if some of the read-* operations could have an opportunity to take into account capabilities of child resources to offer a filtered view? Another possible option could be CLI commands e.g. add-name-rewriter, add-security-realm - not sure if that would be one way to give a better user experience. Anyway just some random thoughts for the moment but wanted to open this up before jumping immediately to the artificial hierarchy solution. Regards, Darran Lofthouse. _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev