3:18 a.m.
Hi Josephine,
there is ongoing discussion [1] about WildFly Elytron subsystem domain model and its
usability from CLI tool.
Could you share UX advices for the CLI usability of Elytron subsystem?
[1] http://lists.jboss.org/pipermail/wildfly-dev/2016-September/005487.html
Thank you,
-- Josef Cacek
JBoss EAP QE
----- Forwarded Message -----
From: "Josef Cacek" <jcacek(a)redhat.com>
To: "Darran Lofthouse" <darran.lofthouse(a)jboss.com>
Cc: "WildFly Dev" <wildfly-dev(a)lists.jboss.org>
Sent: Friday, September 30, 2016 10:12:37 AM
Subject: Re: [wildfly-dev] Subsystem Hierarchy
Hi Darran,
thank you for raising this discussion. We've heard from users/customers about
complexity of WildFly/EAP management tools and it's one of the reasons why we prefer
to split the hierarchy into logical groups instead of using the flat structure. We would
also like to hear opinion of the UX team.
What was not mentioned before is the fact that one possible grouping is already present in
the XSD of the Elytron subsystem:
- security-properties
- provider-loaders
- security-domains
- security-realms
- credential-security-factories
- mappers
- http
- sasl
- tls
- dir-contexts
IMO the domain model doesn't need to copy the XSD, but it could be a good starting
point in the discussion.
Introducing the deeper hierarchy in the model would also allow to describe what each group
("component" in your sample) is responsible for and also how it relates to other
groups.
The objection, that the experienced administrators would need to write longer commands is
not so important from our point of view. For us seems much more important the quick boot
into the configuration for administrators, which meets the Elytron subsystem for the first
time.
The flat model solution disallows to work with CLI with the way like: "I know I need
some realm, but don't know which exactly". Current flat solution is not able to
display all available security-realm.
Thanks,
-- Josef
----- Original Message -----
From: "Darran Lofthouse"
<darran.lofthouse(a)jboss.com>
To: "WildFly Dev" <wildfly-dev(a)lists.jboss.org>
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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev