[JBoss JIRA] (WFCORE-2245) credential-reference capability-reference constraint
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2245?page=com.atlassian.jira.plugi... ]
Kabir Khan updated WFCORE-2245:
-------------------------------
Fix Version/s: 3.0.0.Beta2
(was: 3.0.0.Beta1)
> 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.Beta2
>
>
> 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
[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.Beta2
(was: 3.0.0.Beta1)
> 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.Beta2, 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
[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.Beta2
(was: 3.0.0.Beta1)
> 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.Beta2
>
>
> 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
[JBoss JIRA] (WFLY-8103) Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem)
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8103?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-8103:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Coverity static analysis, Dereference after null check, KeyStoreService (elytron-subsystem)
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-8103
> URL: https://issues.jboss.org/browse/WFLY-8103
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Ilia Vassilev
> Fix For: 11.0.0.Alpha1
>
>
> Coverity found 2 occurences of possible null dereference.
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=95644...
> https://scan7.coverity.com/reports.htm#v23632/p12663/fileInstanceId=95644...
> Method {{resolvePassword()}} is dereferencing {{resolvedPath}} field
> {code}
> private char[] resolvePassword() throws Exception {
> ExceptionSupplier<CredentialSource, Exception> sourceSupplier = credentialSourceSupplier.getValue();
> CredentialSource cs = sourceSupplier != null ? sourceSupplier.get() : null;
> if (cs != null) {
> return cs.getCredential(PasswordCredential.class).getPassword(ClearPassword.class).getPassword();
> } else {
> throw ROOT_LOGGER.keyStorePasswordCannotBeResolved(resolvedPath.getPath());
> }
> }
> {code}
> And method {{resolvePassword()}} is called 2 times from block, where resolvedPath is checked on null
> {code}
> try (InputStream is = resolvedPath != null ? new FileInputStream(resolvedPath) : null) {
> AtomicLoadKeyStore.LoadKey loadKey = keyStore.revertibleLoad(is, resolvePassword());
> try (InputStream is = resolvedPath != null ? new FileInputStream(resolvedPath) : null) {
> char[] password = resolvePassword();
> {code}
> Add null check into {{resolvePassword()}} method.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months
[JBoss JIRA] (WFLY-8115) Add integration tests for jaxrs.
by R Searls (JIRA)
R Searls created WFLY-8115:
------------------------------
Summary: Add integration tests for jaxrs.
Key: WFLY-8115
URL: https://issues.jboss.org/browse/WFLY-8115
Project: WildFly
Issue Type: Task
Components: REST
Affects Versions: 11.0.0.Alpha1
Reporter: R Searls
Assignee: R Searls
Priority: Minor
Add integration tests that preform testing of jaxrs 2.0 spec rules for archive processing.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 2 months