May 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFCORE-13: ---------------------------------------- GenericModelDescribeOperationHandler.DEFINITION was added for WFCORE-401 for internal use in the domain; it's not part of the usual 'describe' op that's been around since AS 7 and I see no reason to "consider 'hidden'" for it. > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Assignee: Brian Stansberry > Labels: EAP > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6290) XTS does not work with jbossws.undefined.host in WS config

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6290?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6290: ----------------------------------------------- Jiri Ondrusek <jondruse(a)redhat.com> changed the Status of [bug 1333968|https://bugzilla.redhat.com/show_bug.cgi?id=1333968] from NEW to ASSIGNED > XTS does not work with jbossws.undefined.host in WS config > ---------------------------------------------------------- > > Key: WFLY-6290 > URL: https://issues.jboss.org/browse/WFLY-6290 > Project: WildFly > Issue Type: Bug > Components: XTS > Reporter: Gytis Trikleris > Assignee: Ivo Studensky > Fix For: 10.2.0.Final > > > XTS uses ServerConfig to initialise it's configuration. However, we should rely on jboss.bind.address instead, because wsdl-host could take "jbossws.undefined.host" as a value. > "jbossws.undefined.host" will cause UnknownHostException, because address rewriting is not executed in XTS. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry commented on WFCORE-13: ---------------------------------------- [~ctomc] Thanks. For now I'll proceed with the 'hidden' thing on that as it's one line of typing and I suspect otherwise I'll have to remove the setPrivateEntry for it to continue to work in test code. If your move-the-op PR is merged first I'll drop that bit from mine. > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Assignee: Brian Stansberry > Labels: EAP > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFCORE-13: -------------------------------------- Assignee: Brian Stansberry > End users can call non-published management API operations > ---------------------------------------------------------- > > Key: WFCORE-13 > URL: https://issues.jboss.org/browse/WFCORE-13 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Ladislav Thon > Assignee: Brian Stansberry > Labels: EAP > > It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces. > The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen. > What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized. > I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2547) Revisit the meaning of aggregate-principal-transformer

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2547?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2547: ------------------------------------- Fix Version/s: 3.0.0.Beta18 > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: WFCORE-2547 > URL: https://issues.jboss.org/browse/WFCORE-2547 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Labels: principal-transformer > Fix For: 3.0.0.Beta18 > > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2500) Elytron, changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2500?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2500: ------------------------------------- Fix Version/s: 3.0.0.Beta18 > Elytron, changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2500 > URL: https://issues.jboss.org/browse/WFCORE-2500 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Martin Choma > Assignee: Tomas Hofman > Fix For: 3.0.0.Beta11, 3.0.0.Beta18 > > > Changing attribute changing http-server-mechanism-factory of http-authentication-factory ends in reload-required state even though header allow-resource-service-restart=true is used > {code} > [standalone@localhost:9990 /] /subsystem=elytron/http-authentication-factory=application-http-authentication:write-attribute(name=http-server-mechanism-factory, value=global){allow-resource-service-restart=true} > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > Header should work as attribute is declared as {{"restart-required" => "resource-services"}} > {code} > "http-server-mechanism-factory" => { > "type" => STRING, > "description" => "The HttpServerAuthenticationMechanismFactory to associate with this resource", > "expressions-allowed" => false, > "required" => true, > "nillable" => false, > "capability-reference" => "org.wildfly.security.http-server-mechanism-factory", > "min-length" => 1L, > "max-length" => 2147483647L, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "resource-services" > } > {code} > And according to documentation [1]: > resource-services – The operation can only immediately update the persistent configuration; applying the operation to the runtime will require a subsequent restart of some services associated with the resource. If the operation includes the request header "allow-resource-service-restart" => true, the handler for the operation will go ahead and restart the runtime service. Otherwise executing the operation will put the server into a "reload-required" state. (See the discussion of "all-services" above for more on the "reload-required" state.) > [1] https://docs.jboss.org/author/display/WFLY10/Description+of+the+Managemen... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2715) principal and authentication-context in Elytron dir-context should be mutually exclusive

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2715?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2715: ------------------------------------- Fix Version/s: 3.0.0.Beta18 > principal and authentication-context in Elytron dir-context should be mutually exclusive > ---------------------------------------------------------------------------------------- > > Key: WFCORE-2715 > URL: https://issues.jboss.org/browse/WFCORE-2715 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta13 > Reporter: Ondrej Lukas > Assignee: Chao Wang > Priority: Critical > Fix For: 3.0.0.Beta18 > > > To avoid possibility when two different principals are configured in Elytron dir-context, its attributes {{principal}} and {{authentication-context}} should be mutually exclusive. > It is similar issue as WFCORE-2396. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2415) credential-reference must have defined combinations of constraints

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2415?page=com.atlassian.jira.plugi... ] Darran Lofthouse updated WFCORE-2415: ------------------------------------- Fix Version/s: 3.0.0.Beta18 > credential-reference must have defined combinations of constraints > ------------------------------------------------------------------ > > Key: WFCORE-2415 > URL: https://issues.jboss.org/browse/WFCORE-2415 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > Fix For: 3.0.0.Beta18 > > > credential-reference must have defined these combinations of constraints: > requires constraint: > alias "requires" [store], > store "requires" [alias] > alternatives constraint: > clear-text "alternatives" [store] > store "alternatives" [clear-text] > optional: type -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2755) Elytron Audit Logging: rotating-file-audit-log's event timestamp lacks information about seconds

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2755?page=com.atlassian.jira.plugi... ] Yeray Borges reassigned WFCORE-2755: ------------------------------------ Assignee: Yeray Borges > Elytron Audit Logging: rotating-file-audit-log's event timestamp lacks information about seconds > ------------------------------------------------------------------------------------------------ > > Key: WFCORE-2755 > URL: https://issues.jboss.org/browse/WFCORE-2755 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Jan Tymel > Assignee: Yeray Borges > Priority: Blocker > > The format of _rotating-file-audit-log's_ timestamp is insufficient. It lacks the information about seconds which might be a problem in an environment with thousands of active users. > Furthermore the format of timestamp is inconsistent with the _file-audit-log_. > _file-audit-log:_ > {code} > 2017-05-03 13:44:07 > {code} > _rotating-file-audit-log:_ > {code} > 5/3/17 1:44 PM > {code} > Suggestions for improvement: > Use the same format of timestamp in_rotating-file-audit-log_ as is already used in _file-audit-log_. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from core to full

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-2746: ----------------------------------- That's fine with me if we merge it and move it afterwards. > Move elytron management security tests from core to full > -------------------------------------------------------- > > Key: WFCORE-2746 > URL: https://issues.jboss.org/browse/WFCORE-2746 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security, Test Suite > Reporter: Brian Stansberry > > Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested. > There are a number of aspects to this, for which I'll create subtasks. > Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list. > org.jboss.as.test.integration.security.perimeter.* [2] > org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase > org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1] > org.jboss.as.test.integration.security.credentialreference [2] > [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now. > [2] Currently using Arquillian. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 8 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2017