[wildfly-dev] Subsystem Hierarchy

[Brian Stansberry]

> On Sep 27, 2016, at 9:47 AM, Darran Lofthouse <darran.lofthouse at jboss.com> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

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