February 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1965) Remove the jboss-logging-annotations dependency from the core feature pack.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1965?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-1965: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Remove the jboss-logging-annotations dependency from the core feature pack. > --------------------------------------------------------------------------- > > Key: WFCORE-1965 > URL: https://issues.jboss.org/browse/WFCORE-1965 > Project: WildFly Core > Issue Type: Task > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta4 > > > This was added inadvertently with some other changes: - > {noformat} > <dependency> > <groupId>org.jboss.logging</groupId> > <artifactId>jboss-logging-annotations</artifactId> > </dependency> > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2136) Using management CLI with client configuration still prompts for username/password

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2136?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2136: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Using management CLI with client configuration still prompts for username/password > ---------------------------------------------------------------------------------- > > Key: WFCORE-2136 > URL: https://issues.jboss.org/browse/WFCORE-2136 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Security > Reporter: Zach Rhoads > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta4 > > > When configuring the wildfly management cli to use an elytron client config file, server still prompts for username password. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2101) Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2101?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2101: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Ensure the default configurations used by clients will be compatible with stronger authentication mechanisms > ------------------------------------------------------------------------------------------------------------ > > Key: WFCORE-2101 > URL: https://issues.jboss.org/browse/WFCORE-2101 > Project: WildFly Core > Issue Type: Task > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Blocker > Fix For: 3.0.0.Beta4 > > > i.e. a later AS release will start to enable mechs like SCRAM, client should work without additional configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2100) Upgrade to WildFly Elytron 1.1.0.Final

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2100?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2100: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Upgrade to WildFly Elytron 1.1.0.Final > -------------------------------------- > > Key: WFCORE-2100 > URL: https://issues.jboss.org/browse/WFCORE-2100 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta4 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2267) Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2267?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2267: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Delete all legacy code from CallbackHandlerService and SubjectSupplemental implementations > ------------------------------------------------------------------------------------------ > > Key: WFCORE-2267 > URL: https://issues.jboss.org/browse/WFCORE-2267 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta4 > > > Only the Elytron realms are now used. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2245) credential-reference capability-reference constraint

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2245: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > credential-reference capability-reference constraint > ---------------------------------------------------- > > Key: WFCORE-2245 > URL: https://issues.jboss.org/browse/WFCORE-2245 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Claudio Miranda > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta4 > > > There attribute credential-reference is defined in many subsystems as below. Looks like the capability-reference constraint should be set in the "store" field of the value-type, therefore I request a review on this capability-constraint placement. > {code} > "credential-reference" => { > "type" => OBJECT, > "description" => "Credential (from Credential Store) to authenticate on data source", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "capability-reference" => "org.wildfly.security.credential-store", > "access-constraints" => {"sensitive" => { > "credential" => {"type" => "core"}, > "data-source-security" => {"type" => "datasources"} > }}, > "value-type" => { > "store" => { > "type" => STRING, > "description" => "The name of the credential store holding the alias to credential", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "alias" => { > "type" => STRING, > "description" => "The alias which denotes stored secret or credential in the store", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "type" => { > "type" => STRING, > "description" => "The type of credential this reference is denoting", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > }, > "clear-text" => { > "type" => STRING, > "description" => "Secret specified using clear text (check credential store way of supplying credential/secrets to services)", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "min-length" => 1L, > "max-length" => 2147483647L > } > }, > "access-type" => "read-write", > "storage" => "configuration", > "restart-required" => "all-services" > }, > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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: 3.0.0.Beta4 (was: 3.0.0.Beta3) > 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: Component Upgrade > Components: Domain Management > Affects Versions: 3.0.0.Alpha16 > Reporter: Kabir Khan > Assignee: Brian Stansberry > Fix For: 3.0.0.Beta4, 4.0.0.Beta1 > > > 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.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2163: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface > --------------------------------------------------------------------------------------------------- > > Key: WFCORE-2163 > URL: https://issues.jboss.org/browse/WFCORE-2163 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 3.0.0.Beta4 > > > In case when legacy security-realm for SSL is used together with Elytron authentication in HTTP management interface then server is not started. > I am using following configuration for HTTP management interface (see Steps to Reproduce for more details): > {code} > <http-interface http-authentication-factory="management-http-authentication" security-realm="ManagementRealmHTTPS"> > <http-upgrade enabled="true" sasl-authentication-factory="management-sasl-authentication"/> > <socket-binding http="management-http" https="management-https"/> > </http-interface> > {code} > Server is not started and following errors occur in log: > {code} > ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service org.wildfly.management.http.extensible: org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:330) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963) > at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided. > at org.jboss.as.domain.http.server.ManagementHttpServer.getSSLContext(ManagementHttpServer.java:225) > at org.jboss.as.domain.http.server.ManagementHttpServer.create(ManagementHttpServer.java:254) > at org.jboss.as.domain.http.server.ManagementHttpServer.access$2400(ManagementHttpServer.java:107) > at org.jboss.as.domain.http.server.ManagementHttpServer$Builder.build(ManagementHttpServer.java:589) > at org.jboss.as.server.mgmt.UndertowHttpManagementService.start(UndertowHttpManagementService.java:292) > ... 5 more > {code} > and > {code} > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([ > ("core-service" => "management"), > ("management-interface" => "http-interface") > ]) - failure description: { > "WFLYCTL0080: Failed services" => {"org.wildfly.management.http.extensible" => "org.jboss.msc.service.StartException in service org.wildfly.management.http.extensible: WFLYSRV0083: Failed to start the http-interface service > Caused by: java.lang.IllegalStateException: WFLYDMHTTP0015: No SecurityRealm or SSLContext has been provided."}, > "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.management.http.extensible"], > "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined > } > {code} > According to comments in EAP7-545 Analysis document [1], when security-realm and http-authentication-factory are specified but no ssl-context is used then it should lead to use legacy security-realm for SSL configuration and http-authentication-factory for authentication. > [1] https://docs.google.com/document/d/1LsS-CGUJSDwGcFUva0g-BF9ZIq0jwx__1e_oJ... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2206) Upgrade to WildFly Elytron 1.1.0.Beta20

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2206?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2206: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Upgrade to WildFly Elytron 1.1.0.Beta20 > --------------------------------------- > > Key: WFCORE-2206 > URL: https://issues.jboss.org/browse/WFCORE-2206 > Project: WildFly Core > Issue Type: Component Upgrade > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta4 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2302) Ensure sensitivity CREDENTIAL is only applied to clear-password, add CredentialRef for the referencing attribute.

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2302?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2302: ------------------------------------- Fix Version/s: 3.0.0.Beta4 (was: 3.0.0.Beta3) > Ensure sensitivity CREDENTIAL is only applied to clear-password, add CredentialRef for the referencing attribute. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2302 > URL: https://issues.jboss.org/browse/WFCORE-2302 > Project: WildFly Core > Issue Type: Task > Components: Domain Management, Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 3.0.0.Beta4 > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 2 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 February 2017