Subsystem Hierarchy

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Subsystem Hierarchy

Darran Lofthouse
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/

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

Re: Subsystem Hierarchy

Brian Stansberry

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

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




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

Re: Subsystem Hierarchy

Darran Lofthouse
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 <[hidden email]> 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
>> [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
|  
Report Content as Inappropriate

Re: Subsystem Hierarchy

Harald Pehl
We often derive the navigation in HAL from the management model tree. But it's also quite common that we shuffle things around and add own hierarchies to group resources differently. So I don't think that changing the hierarchy would make any difference in terms of HAL. 

More important to me is a logical grouping of resources which belong together. This should be reflected in both the documentation and in HAL.  

On Wed, Sep 28, 2016 at 1:23 PM, Darran Lofthouse <[hidden email]> wrote:
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 <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
---
Harald Pehl
JBoss by Red Hat
http://hpehl.info

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

Re: Subsystem Hierarchy

Claudio Miranda
On Wed, Sep 28, 2016 at 9:53 AM, Harald Pehl <[hidden email]> 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


--
  Claudio Miranda

[hidden email]
http://www.claudius.com.br
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Subsystem Hierarchy

Jean-Francois Denise
Daran,

I have looked at the /subsystem=elytron content. From this long list it
is difficult to extract use cases.

Grouping the resources (as Claudio did) in a way that reflects your
object model
(https://docs.jboss.org/author/display/WFLY/WildFly+Elytron+Security)
can help. Thinking at various administrator use cases (that would
activate multiple resources in sequential steps) could help define the
best security related CLI commands.

I guess that we would not expose commands for everything but if we cover
the main actions, the low level operation support (with completion for
capabilities) would help handle the missing pieces.

I am available if you are ready to teach me a bit ;-).

Thanks.

JF


On 28/09/16 17:20, Claudio Miranda wrote:

> On Wed, Sep 28, 2016 at 9:53 AM, Harald Pehl <[hidden email]> 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
>
>

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

Re: Subsystem Hierarchy

Josef Cacek
In reply to this post by Darran Lofthouse
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" <[hidden email]>
> To: "WildFly Dev" <[hidden email]>
> 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/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/
>
> 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
> [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
|  
Report Content as Inappropriate

Fwd: Subsystem Hierarchy

Josef Cacek
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" <[hidden email]>
To: "Darran Lofthouse" <[hidden email]>
Cc: "WildFly Dev" <[hidden email]>
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" <[hidden email]>
> To: "WildFly Dev" <[hidden email]>
> 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/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/
>
> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
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
|  
Report Content as Inappropriate

Re: Subsystem Hierarchy

Darran Lofthouse
In reply to this post by Josef Cacek
I think two very different concepts are getting mixed up here,
management tooling usability and subsystem design.

At the moment we are talking about very low level access to the
subsystem - speaking with various engineers I have not yet heard a
compelling argument that this aspect of usability is something to handle
all the way at the subsystem level.

I think we need to get the original bug reports accurately re-described
for the problem they are claiming needs solving, at the moment they are
requesting a change rather than describing the problem.

Regards,
Darran Lofthouse.



On 30/09/16 09:12, Josef Cacek wrote:

> 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" <[hidden email]>
>> To: "WildFly Dev" <[hidden email]>
>> 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/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/
>>
>> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...