[
https://issues.jboss.org/browse/WFCORE-639?page=com.atlassian.jira.plugin...
]
Brian Stansberry commented on WFCORE-639:
-----------------------------------------
Emmanuel, we don't need to do this as part of this fix, but since we're changing
APIs anyway it's worth considering. Should the JmxPermissionFactory interface go away?
The new getUserPermissions and getRequiredPermissions methods can go in the
PermissionFactory interface. The existing JmxPermissionFactory.getUserRoles method will no
longer be used. And the JmxPermissionFactory.isNonFacadeMBeansSensitive method is an odd
fit and doesn't really belong in a "permission factory" interface.
ManagementPermissionAuthorizer is limited to the standard roles for
its authorizeJmxOperation impl
--------------------------------------------------------------------------------------------------
Key: WFCORE-639
URL:
https://issues.jboss.org/browse/WFCORE-639
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: ehsavoie Hugonnet
ManagementPermissionAuthorizer.authorizeJmxOperation uses hard coded decision making
based on the standard 7 roles. This is inflexible and specifically doesn't allow
scoped roles to function properly.
I believe the JmxPermissionFactory interface needs to be redone to use permissions
instead of role names. It should have an API more like
org.jboss.as.controller.access.permission.PermissionFactory, with getUserPermissions and
getRequiredPermissions. Something like
PermissionCollection getUserPermissions(Caller caller, Environment callEnvironment,
JmxAction action)
PermissionCollection getRequiredPermissions(JmxAction action);
Then ManagementPermissionAuthorizer.authorizeJmxOperation does a permission match check
similar to what it does for management resource permissions.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)