October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2365) Review custom-modifiable-realm resource in Elytron subsystem

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2365: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > Review custom-modifiable-realm resource in Elytron subsystem > ------------------------------------------------------------ > > Key: WFCORE-2365 > URL: https://issues.jboss.org/browse/WFCORE-2365 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Fix For: 4.0.0.Alpha3 > > > See description of JBEAP-6100 for more details. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2349) Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2349: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients. > --------------------------------------------------------------------------------- > > Key: WFCORE-2349 > URL: https://issues.jboss.org/browse/WFCORE-2349 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management, Security > Reporter: Darran Lofthouse > Fix For: 4.0.0.Alpha3 > > > Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2336) Remove ModelController.createClient

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2336: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > Remove ModelController.createClient > ----------------------------------- > > Key: WFCORE-2336 > URL: https://issues.jboss.org/browse/WFCORE-2336 > Project: WildFly Core > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Fix For: 4.0.0.Alpha3 > > > Follow up on WFCORE-1507 by removing ModelController.createClient and any use of it. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2217: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests > ----------------------------------------------------------------------------------- > > Key: WFCORE-2217 > URL: https://issues.jboss.org/browse/WFCORE-2217 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: Kabir Khan > Fix For: 4.0.0.Alpha3 > > > During a normal server boot ValidationStepHandler gets called. But during a core-model-/subsystem tests it does not get called on boot. The issue is that in these tests bootOperations.postExtensionOps are null, so the if block at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... which contains the validation logic at https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha19/controller/src... does not get called. > The fix is quite simple: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > but changing this and trying to run the widlfly-core tests causes failures in the remoting subsystem and loads in the core-model-tests. There are bound to be more in the subsystems in full. > I'd hazard a guess and say that the subsystem tests are aiming for good coverage, and so might be setting stuff which would fail validation e.g. of Alternatives. > For core model tests it is complaining about things like missing management-xxx-versions in the model, default interfaces in socket binding groups and a lot of things like that. In a lot of cases the xml used in the tests uses minimum information to set up things for what is needed. WIP for the core model tests is: > {code} > diff --git a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > index 4a6cc7c..d8e1911 100644 > --- a/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > +++ b/controller/src/main/java/org/jboss/as/controller/ModelControllerImpl.java > @@ -517,21 +517,21 @@ class ModelControllerImpl implements ModelController { > } > > resultAction = postExtContext.executeOperation(); > + } > > - if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP && bootOperations.postExtensionOps != null) { > - //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > - Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > - Resource root = managementModel.get().getRootResource(); > - addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > - > - final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > - EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > - contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > - bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > - extraValidationStepHandler, partialModel, securityIdentitySupplier); > - validateContext.addModifiedResourcesForModelValidation(validateAddresses); > - resultAction = validateContext.executeOperation(); > - } > + if (!skipModelValidation && resultAction == OperationContext.ResultAction.KEEP) { > + //Get the modified resources from the initial operations and add to the resources to be validated by the post operations > + Set<PathAddress> validateAddresses = new HashSet<PathAddress>(); > + Resource root = managementModel.get().getRootResource(); > + addAllAddresses(managementModel.get().getRootResourceRegistration(), PathAddress.EMPTY_ADDRESS, root, validateAddresses); > + > + final AbstractOperationContext validateContext = new OperationContextImpl(operationID, POST_EXTENSION_BOOT_OPERATION, > + EMPTY_ADDRESS, this, processType, runningModeControl.getRunningMode(), > + contextFlags, handler, null, managementModel.get(), control, processState, auditLogger, > + bootingFlag.get(), hostServerGroupTracker, null, null, notificationSupport, false, > + extraValidationStepHandler, partialModel, securityIdentitySupplier); > + validateContext.addModifiedResourcesForModelValidation(validateAddresses); > + resultAction = validateContext.executeOperation(); > } > > return resultAction == OperationContext.ResultAction.KEEP; > {code} > So although the fix is simple, the fallout of this is quite big. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1960) Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1960: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING > -------------------------------------------------------------------- > > Key: WFCORE-1960 > URL: https://issues.jboss.org/browse/WFCORE-1960 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Ken Wills > Fix For: 4.0.0.Alpha3 > > Attachments: rrd.txt > > > A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute. > I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+...) so removing the only usage of it will help. > We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1944) Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1944: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code. > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-1944 > URL: https://issues.jboss.org/browse/WFCORE-1944 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Fix For: 4.0.0.Alpha3 > > > The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs. > The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1649) RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1649: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave > ------------------------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-1649 > URL: https://issues.jboss.org/browse/WFCORE-1649 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Critical > Labels: domain-mode > Fix For: 4.0.0.Alpha3 > > > The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems. > This is a big problem in the following scenarios: > 1) Mixed domain, where legacy slaves do not know about newly introduced classifications. > 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present. > A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But: > -- that doesn't help with problem 2) > -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1489) Expose (un)registerNotificationHandler() on OperationContext

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1489: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > Expose (un)registerNotificationHandler() on OperationContext > ------------------------------------------------------------ > > Key: WFCORE-1489 > URL: https://issues.jboss.org/browse/WFCORE-1489 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Kabir Khan > Assignee: Jeff Mesnil > Fix For: 4.0.0.Alpha3 > > > Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2688) RestartParentWriteAttributeHandler.isResourceServiceRestartAllowed should check the AttributeDefinition

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2688?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2688: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > RestartParentWriteAttributeHandler.isResourceServiceRestartAllowed should check the AttributeDefinition > ------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2688 > URL: https://issues.jboss.org/browse/WFCORE-2688 > Project: WildFly Core > Issue Type: Enhancement > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Alpha3 > > > Besides checking with the context as to whether the allow-resource-service-restart header is set, if there is an AD available, it should be checked. > At one stroke this will turn off this ability for everything that doesn't specifically allow it. > Needs checks though to fix attributes that are meant to allow this but don't say so. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 6 months

1
0
0 / 0

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

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2746: ------------------------------------- Fix Version/s: 4.0.0.Alpha3 (was: 4.0.0.Alpha2) > Move elytron management security tests from full to core > -------------------------------------------------------- > > 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 > Fix For: 4.0.0.Alpha3 > > > 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. > Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723 > 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]- > integration/elytron/ > [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.5.0#75005)

8 years, 6 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2017