[JBoss JIRA] (WFLY-2584) RBAC: Silent failure of run-as role mapping
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2584?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2584:
----------------------------------------
Darran, I assigned this to you just to get your input re: any reason not to fail. Feel free to assign to me.
> RBAC: Silent failure of run-as role mapping
> -------------------------------------------
>
> Key: WFLY-2584
> URL: https://issues.jboss.org/browse/WFLY-2584
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Beta1
> Reporter: Brian Stansberry
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.CR1
>
>
> RunAsRoleMapper.mapRoles(Caller caller, Set<String> currentRoles, Set<String> runAsRoles, boolean sanitized) ignores false results from realRoleMapper.canRunAs(currentRoles, requestedRole) and just leaves the user running in their regular roles. Some sort of failure condition seems more appropriate.
> I noticed this when I was investigating WFLY-2318 caused by WFLY-2583. The improperly parsed role list was resulting in realRoleMapper.canRunAs(currentRoles, requestedRole) so the call would just execute as SuperUser.
> Same thing would happen with a simple typo like {roles=Mnitor}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2318) Access control exceptions missing for scoped roles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2318?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2318:
----------------------------------------
I believe the problem here is the use of multiple run-as roles is not properly supported for the CLI or HTTP clients. See WFLY-2583.
The effect was the caller was running as SuperUser, and got the response appropriate for that.
When I try with a patched build with that problem fixed, it get the expected result.
You can verify that by mapping a user to the roles instead of using run-as.
> Access control exceptions missing for scoped roles
> --------------------------------------------------
>
> Key: WFLY-2318
> URL: https://issues.jboss.org/browse/WFLY-2318
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
>
> The following setup: user with two scoped roles assigned. maintainer for "main-servers", monitor for "other-servers". Requesting the access control meta data for the server group wildcard ]does not include "exceptions".
> Expected result: the access control meta data response contains an "exception" for each server group (main-server-group & other-server-group)
> {code}
> [domain@localhost:9999 /] ./server-group=*:read-resource-description(access-control=trim-descriptions, operations=true){roles=main-servers, other-servers}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("server-group" => "*")],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "children" => {
> "deployment" => {"model-description" => undefined},
> "system-property" => {"model-description" => undefined},
> "jvm" => {"model-description" => undefined},
> "deployment-overlay" => {"model-description" => undefined}
> },
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => true,
> "attributes" => {
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => true
> },
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => true
> },
> "profile" => {
> "read" => true,
> "write" => true
> }
> },
> "operations" => {
> "read-children-names" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "remove" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "stop-servers" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "whoami" => {"execute" => true},
> "read-children-types" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "start-servers" => {"execute" => true},
> "read-children-resources" => {"execute" => true},
> "restart-servers" => {"execute" => true},
> "replace-deployment" => {"execute" => true},
> "write-attribute" => {"execute" => true}
> }
> },
> "exceptions" => {}
> }
> }
> }]
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2583) Support multiple run-as roles from CLI and HTTP clients
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-2583:
--------------------------------------
Summary: Support multiple run-as roles from CLI and HTTP clients
Key: WFLY-2583
URL: https://issues.jboss.org/browse/WFLY-2583
Project: WildFly
Issue Type: Requirement
Security Level: Public (Everyone can see)
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 8.0.0.CR1
The "run-as" roles feature with RBAC will only allow multiple role declarations if the caller provides a ModelNode of type LIST. The CLI doesn't do that and clients using the HTTP interface (e.g. web console) cannot do that. This makes doing this largely unsupported except for things like unit tests the create custom clients.
Fix is to do some more sophisticated parsing in RunAsRolesMapper.getOperationHeaderRoles(...).
1) If the trimmed role-list string starts with [ and ends with ] try to use ModelNode.fromString to parse. Return result if no error.
2) If not, or there is a parse error in 1), check for "," and use String.split(",")
3) Just return the trimmed string in a ModelNode.
Step 2 makes "," a kind of privileged char in role names. However, in the extremely remote chance users want to include "," in role names and still use this feature, the solution is to use proper DMR syntax for the roles header value, e.g.
["yuck,commas","Maintainer"]
So, in the CLI:
$ :read-resource{roles=["yuck,commas","Maintainer"]}
An HTTP client like the console should use proper DMR syntax for the value of the operation-header-roles query parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2318) Access control exceptions missing for scoped roles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2318?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2318:
-----------------------------------
Comment: was deleted
(was: The 2 scoped roles aspect doesn't seem to matter; I get the same result with {roles=main-servers}.
Which I think is good news, actually. Less likely to be some weird corner case deal.)
> Access control exceptions missing for scoped roles
> --------------------------------------------------
>
> Key: WFLY-2318
> URL: https://issues.jboss.org/browse/WFLY-2318
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
>
> The following setup: user with two scoped roles assigned. maintainer for "main-servers", monitor for "other-servers". Requesting the access control meta data for the server group wildcard ]does not include "exceptions".
> Expected result: the access control meta data response contains an "exception" for each server group (main-server-group & other-server-group)
> {code}
> [domain@localhost:9999 /] ./server-group=*:read-resource-description(access-control=trim-descriptions, operations=true){roles=main-servers, other-servers}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("server-group" => "*")],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "children" => {
> "deployment" => {"model-description" => undefined},
> "system-property" => {"model-description" => undefined},
> "jvm" => {"model-description" => undefined},
> "deployment-overlay" => {"model-description" => undefined}
> },
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => true,
> "attributes" => {
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => true
> },
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => true
> },
> "profile" => {
> "read" => true,
> "write" => true
> }
> },
> "operations" => {
> "read-children-names" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "remove" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "stop-servers" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "whoami" => {"execute" => true},
> "read-children-types" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "start-servers" => {"execute" => true},
> "read-children-resources" => {"execute" => true},
> "restart-servers" => {"execute" => true},
> "replace-deployment" => {"execute" => true},
> "write-attribute" => {"execute" => true}
> }
> },
> "exceptions" => {}
> }
> }
> }]
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2527) It's not possible to query subresources of the Infinispan subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2527?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-2527:
-----------------------------------
Summary: It's not possible to query subresources of the Infinispan subsystem (was: It's not possible to query subresourcs of the Infinispan subsystem )
> It's not possible to query subresources of the Infinispan subsystem
> --------------------------------------------------------------------
>
> Key: WFLY-2527
> URL: https://issues.jboss.org/browse/WFLY-2527
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
>
> the infinispan cache description are not provided for wildcards. Hence it's not possible to query rrd() _before_ adding a resource:
> {code}
> [domain@localhost:9990 /] /profile=default/subsystem=infinispan/cache-container=web/local-cache=local-web/eviction=*:read-resource-description()
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014883: No resource definition is registered for address [
> (\"profile\" => \"default\"),
> (\"subsystem\" => \"infinispan\"),
> (\"cache-container\" => \"web\"),
> (\"local-cache\" => \"local-web\"),
> (\"eviction\" => \"*\")
> ]",
> "rolled-back" => true
> }
> {code}
> Same for the other cache subresources. Please add the wildcard handlers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2527) It's not possible to query subresourcs of the Infinispan subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2527?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2527:
----------------------------------------
Hmm; ignore the last comment for now; I may be totally off base.
> It's not possible to query subresourcs of the Infinispan subsystem
> -------------------------------------------------------------------
>
> Key: WFLY-2527
> URL: https://issues.jboss.org/browse/WFLY-2527
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
>
> the infinispan cache description are not provided for wildcards. Hence it's not possible to query rrd() _before_ adding a resource:
> {code}
> [domain@localhost:9990 /] /profile=default/subsystem=infinispan/cache-container=web/local-cache=local-web/eviction=*:read-resource-description()
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014883: No resource definition is registered for address [
> (\"profile\" => \"default\"),
> (\"subsystem\" => \"infinispan\"),
> (\"cache-container\" => \"web\"),
> (\"local-cache\" => \"local-web\"),
> (\"eviction\" => \"*\")
> ]",
> "rolled-back" => true
> }
> {code}
> Same for the other cache subresources. Please add the wildcard handlers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2318) Access control exceptions missing for scoped roles
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2318?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2318:
----------------------------------------
The 2 scoped roles aspect doesn't seem to matter; I get the same result with {roles=main-servers}.
Which I think is good news, actually. Less likely to be some weird corner case deal.
> Access control exceptions missing for scoped roles
> --------------------------------------------------
>
> Key: WFLY-2318
> URL: https://issues.jboss.org/browse/WFLY-2318
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
>
> The following setup: user with two scoped roles assigned. maintainer for "main-servers", monitor for "other-servers". Requesting the access control meta data for the server group wildcard ]does not include "exceptions".
> Expected result: the access control meta data response contains an "exception" for each server group (main-server-group & other-server-group)
> {code}
> [domain@localhost:9999 /] ./server-group=*:read-resource-description(access-control=trim-descriptions, operations=true){roles=main-servers, other-servers}
> {
> "outcome" => "success",
> "result" => [{
> "address" => [("server-group" => "*")],
> "outcome" => "success",
> "result" => {
> "description" => undefined,
> "attributes" => undefined,
> "operations" => undefined,
> "children" => {
> "deployment" => {"model-description" => undefined},
> "system-property" => {"model-description" => undefined},
> "jvm" => {"model-description" => undefined},
> "deployment-overlay" => {"model-description" => undefined}
> },
> "access-control" => {
> "default" => {
> "read" => true,
> "write" => true,
> "attributes" => {
> "socket-binding-port-offset" => {
> "read" => true,
> "write" => true
> },
> "management-subsystem-endpoint" => {
> "read" => true,
> "write" => false
> },
> "socket-binding-group" => {
> "read" => true,
> "write" => true
> },
> "profile" => {
> "read" => true,
> "write" => true
> }
> },
> "operations" => {
> "read-children-names" => {"execute" => true},
> "read-operation-description" => {"execute" => true},
> "remove" => {"execute" => true},
> "read-resource-description" => {"execute" => true},
> "stop-servers" => {"execute" => true},
> "read-resource" => {"execute" => true},
> "add" => {"execute" => true},
> "read-attribute" => {"execute" => true},
> "whoami" => {"execute" => true},
> "read-children-types" => {"execute" => true},
> "read-operation-names" => {"execute" => true},
> "undefine-attribute" => {"execute" => true},
> "start-servers" => {"execute" => true},
> "read-children-resources" => {"execute" => true},
> "restart-servers" => {"execute" => true},
> "replace-deployment" => {"execute" => true},
> "write-attribute" => {"execute" => true}
> }
> },
> "exceptions" => {}
> }
> }
> }]
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-2527) It's not possible to query subresourcs of the Infinispan subsystem
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-2527?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-2527:
----------------------------------------
A resource description for eviction=* is not valid, because that means that resources of that type with any address value are valid, which isn't true.
The only thing I can think to do hear is to support wildcard queries a la what we do with :read-resource for :read-resource-description as well. That is, the style where you get back a list of matching addresses.
The problem is that's a breaking change to the behavior of r-r-d for the cases where there is a * registration.
> It's not possible to query subresourcs of the Infinispan subsystem
> -------------------------------------------------------------------
>
> Key: WFLY-2527
> URL: https://issues.jboss.org/browse/WFLY-2527
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Brian Stansberry
>
> the infinispan cache description are not provided for wildcards. Hence it's not possible to query rrd() _before_ adding a resource:
> {code}
> [domain@localhost:9990 /] /profile=default/subsystem=infinispan/cache-container=web/local-cache=local-web/eviction=*:read-resource-description()
> {
> "outcome" => "failed",
> "failure-description" => "JBAS014883: No resource definition is registered for address [
> (\"profile\" => \"default\"),
> (\"subsystem\" => \"infinispan\"),
> (\"cache-container\" => \"web\"),
> (\"local-cache\" => \"local-web\"),
> (\"eviction\" => \"*\")
> ]",
> "rolled-back" => true
> }
> {code}
> Same for the other cache subresources. Please add the wildcard handlers.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months
[JBoss JIRA] (WFLY-1383) Disable pooling of stateless EJBs by default
by Cheng Fang (JIRA)
[ https://issues.jboss.org/browse/WFLY-1383?page=com.atlassian.jira.plugin.... ]
Cheng Fang commented on WFLY-1383:
----------------------------------
Will manually take the changes to the 3 files from Jaikiran's PR:
{noformat}
build/src/main/resources/configuration/subsystems/ejb3.xml
testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/ejb/management/deployments/ManagedStatelessBean.java
testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/ejb/management/deployments/NoTimerStatelessBean.java
{noformat}
Changes to testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/ejb/pool/lifecycle/PooledEJBLifecycleTestCase.java is obsoleted by fixes to WFLY-1506 (Fix PooledEJBLifecycleTestCase.tesMDB and the whole testcase in general).
> Disable pooling of stateless EJBs by default
> --------------------------------------------
>
> Key: WFLY-1383
> URL: https://issues.jboss.org/browse/WFLY-1383
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EJB
> Affects Versions: 8.0.0.Alpha1
> Reporter: jaikiran pai
> Assignee: Cheng Fang
>
> A certain use case has shown that it's perhaps better to disable pooling of EJB stateless bean, by default. In AS7 we have always allowed disabling the pooling but we hadn't made it the default since we thought it might affect applications which have SLSBs with heavy @PostConstruct.
> A recent discussion has suggested that we disable the pooling by default and individual applications can enable it and set the relevant pool size themselves. The reasoning has been that, the default pool size that we ship with, anyway will have to be tweaked by the users since we can't really guess what an ideal pool size is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 8 months