[JBoss JIRA] (WFCORE-2163) Server does not start when Elytron authentication + legacy SSL is used in HTTP management interface
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2163?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2163:
-------------------------------
Fix Version/s: 3.0.0.Alpha21
(was: 3.0.0.Alpha20)
> 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.Alpha21
>
>
> 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, 3 months
[JBoss JIRA] (WFCORE-2217) ValidationStepHandler does not get triggered on boot in subsystem-/core-model tests
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2217?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2217:
-------------------------------
Fix Version/s: 3.0.0.Alpha21
(was: 3.0.0.Alpha20)
> 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.Alpha21, 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, 3 months
[JBoss JIRA] (WFCORE-2224) Management issues on host after enabling RBAC
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2224?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2224:
-------------------------------
Fix Version/s: 3.0.0.Alpha21
(was: 3.0.0.Alpha20)
> Management issues on host after enabling RBAC
> ---------------------------------------------
>
> Key: WFCORE-2224
> URL: https://issues.jboss.org/browse/WFCORE-2224
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Alpha16
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha21
>
>
> When enabling RBAC ({{/core-service=management/access=authorization:write-attribute(name=provider, value=rbac)}}), it is not possible to add role mappings:
> {code}
> [domain@localhost:9990 /] /core-service=management/access=authorization/role-mapping=Maintainer:add()
> {
> "outcome" => "failed",
> "result" => undefined,
> "failure-description" => {"WFLYDC0074: Operation failed or was rolled back on all servers. Server failures:" => {"server-group" => {"main-server-group" => {"host" => {"master" => {
> "server-one" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "server-two" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found"
> }}}}}},
> "rolled-back" => true,
> "server-groups" => {"main-server-group" => {"host" => {"master" => {
> "server-one" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "rolled-back" => true
> }},
> "server-two" => {"response" => {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0216: Management resource '[
> (\"core-service\" => \"management\"),
> (\"access\" => \"authorization\"),
> (\"role-mapping\" => \"Maintainer\")
> ]' not found",
> "rolled-back" => true
> }}
> }}}}
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFLY-7575) Elytron mechanism-provider-filtering-sasl-server-factory cannot be added without filters attribute in CLI
by Claudio Miranda (JIRA)
[ https://issues.jboss.org/browse/WFLY-7575?page=com.atlassian.jira.plugin.... ]
Claudio Miranda commented on WFLY-7575:
---------------------------------------
As of today (already merged) the r-r-d shows the filters attribute is required=true and nillable=false, looks like the add operation doesn't require the filters attribute, but the description should be updated too.
{code}
"filters" => {
"type" => LIST,
"description" => "The filters to apply when comparing the mechanisms from the providers, a filter matches when all of the specified values match the mechanism / provider pair.",
"expressions-allowed" => false,
"required" => true,
"nillable" => false,
{code}
> Elytron mechanism-provider-filtering-sasl-server-factory cannot be added without filters attribute in CLI
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7575
> URL: https://issues.jboss.org/browse/WFLY-7575
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Ilia Vassilev
> Fix For: 11.0.0.Alpha1
>
>
> Adding {{mechanism-provider-filtering-sasl-server-factory}} without {{filters}} attribute through CLI causes IllegalArgumentException. Exception is not thrown when {{filters}} attribute is used.
> It has to be decided whether:
> * {{filters}} should be required, then its nillable should be changed to false and related part of XSD should not include {{minOccurs="0"}}
> * {{filters}} should not be required, then {{mechanism-provider-filtering-sasl-server-factory}} must be able to be added without {{filters}} attribute - no exception should occur and {{mechanism-provider-filtering-sasl-server-factory}} should be stored in configuration
> Exception in server log:
> {code}
> ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 6) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("mechanism-provider-filtering-sasl-server-factory" => "factory")
> ]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asList(ModelValue.java:143)
> at org.jboss.dmr.ModelNode.asList(ModelNode.java:1389)
> at org.wildfly.extension.elytron.SaslServerDefinitions$4.installService(SaslServerDefinitions.java:362)
> at org.wildfly.extension.elytron.SaslServerDefinitions$SaslServerAddHandler.performRuntime(SaslServerDefinitions.java:470)
> at org.jboss.as.controller.AbstractAddStepHandler.performRuntime(AbstractAddStepHandler.java:337)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:921)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:664)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:383)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1364)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:416)
> at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:237)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:431)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:206)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:237)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.wildfly.security.auth.client.PeerIdentity.runAsAll(PeerIdentity.java:464)
> at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:225)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:185)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> This issue is caused by fix of JBEAP-6381.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months
[JBoss JIRA] (WFCORE-2216) CLI fails to reload when connection upgrades from http to https
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2216?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-2216:
----------------------------------------------
[~brian.stansberry], the CLIModelControllerClient inherits from AbstractModelControllerClient. Making the change in the RemotingModelControllerClient shouldn't impact the CLI.
I am wandering if the RemotingModelControllerClient would be designed to deal with a change of URI. A cleanup (close) seems required to switch from http to https configuration. Perhaps introducing a completely new ModelControllerClient implementation that would mute its configuration when redirect occurs.
> CLI fails to reload when connection upgrades from http to https
> ---------------------------------------------------------------
>
> Key: WFCORE-2216
> URL: https://issues.jboss.org/browse/WFCORE-2216
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Fix For: 3.0.0.Alpha20
>
>
> reload command should manage to reconnect to a server reconfigured with https management interface.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 3 months