[JBoss JIRA] (WFCORE-2682) Elytron token-realm attributes validations
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2682?page=com.atlassian.jira.plugi... ]
Chao Wang resolved WFCORE-2682.
-------------------------------
Fix Version/s: 3.0.0.Beta16
Resolution: Duplicate Issue
> Elytron token-realm attributes validations
> ------------------------------------------
>
> Key: WFCORE-2682
> URL: https://issues.jboss.org/browse/WFCORE-2682
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta13
> Reporter: Martin Choma
> Fix For: 3.0.0.Beta16
>
>
> * I am able to set both {{key-store}} and {{public-key}} attributes. However based on model they should be alternatives and thus only one of them should be allowed.
> * Althought, {{key-store}} and {{certificate}} are configured as requires in model, validation does not work.
> Seems it is caused by WFCORE-2317.
> {code}
> "public-key" => {
> "type" => STRING,
> "description" => "A public key in PEM Format. During validation, if a public key is provided, signature will be verified based on the key you provided here.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "alternatives" => [
> "key-store",
> "certificate"
> ],
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "key-store" => {
> "type" => STRING,
> "description" => "A key store from where the certificate with a public key should be loaded from.",
> "expressions-allowed" => false,
> "required" => false,
> "nillable" => true,
> "alternatives" => ["public-key"],
> "requires" => ["certificate"],
> "capability-reference" => "org.wildfly.security.key-store",
> "min-length" => 1L,
> "max-length" => 2147483647L
> },
> "certificate" => {
> "type" => STRING,
> "description" => "The name of the certificate with a public key to load from the key store.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "alternatives" => ["public-key"],
> "requires" => ["key-store"],
> "min-length" => 1L,
> "max-length" => 2147483647L
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (WFCORE-2746) Move elytron management security tests from core to full
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugi... ]
Ondrej Lukas commented on WFCORE-2746:
--------------------------------------
[~luck3y] PR with org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase is still not merged. See https://github.com/wildfly-security-incubator/wildfly/pull/194.
> 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
[JBoss JIRA] (WFLY-8684) Confusing exception during deployment when ldap-realm does not include password reference
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-8684?page=com.atlassian.jira.plugin.... ]
Chao Wang moved WFCORE-2587 to WFLY-8684:
-----------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-8684 (was: WFCORE-2587)
Component/s: Security
Web (Undertow)
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 3.0.0.Beta10)
> Confusing exception during deployment when ldap-realm does not include password reference
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-8684
> URL: https://issues.jboss.org/browse/WFLY-8684
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Chao Wang
> Labels: user_experience
>
> In case when {{ldap-realm}} is configured with {{direct-verification=false}} and no {{identity-mapping.user-password-mapper}} is provided then deployment which using this realm fails with Exception:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:241)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$6(ApplicationSecurityDomainDefinition.java:492)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:489)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239)
> ... 8 more
> {code}
> Throwing exception is correct since deployment has no possibility how to verify a password through given ldap-realm. However message given to user is confusing, it says "The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.". Information that ldap-realm is insufficiently configured for given deployment should be propagated to the user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (WFCORE-2587) Confusing exception during deployment when ldap-realm does not include password reference
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2587?page=com.atlassian.jira.plugi... ]
Chao Wang reassigned WFCORE-2587:
---------------------------------
Assignee: Chao Wang (was: Darran Lofthouse)
> Confusing exception during deployment when ldap-realm does not include password reference
> -----------------------------------------------------------------------------------------
>
> Key: WFCORE-2587
> URL: https://issues.jboss.org/browse/WFCORE-2587
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta10
> Reporter: Ondrej Lukas
> Assignee: Chao Wang
> Labels: user_experience
>
> In case when {{ldap-realm}} is configured with {{direct-verification=false}} and no {{identity-mapping.user-password-mapper}} is provided then deployment which using this realm fails with Exception:
> {code}
> ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 62) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./print-roles: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./print-roles: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:84)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 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)
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:241)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:99)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:81)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$6(ApplicationSecurityDomainDefinition.java:492)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:489)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$2(ApplicationSecurityDomainDefinition.java:425)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:415)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:211)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:174)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:239)
> ... 8 more
> {code}
> Throwing exception is correct since deployment has no possibility how to verify a password through given ldap-realm. However message given to user is confusing, it says "The required mechanism 'BASIC' is not available from the HttpAuthenticationFactory.". Information that ldap-realm is insufficiently configured for given deployment should be propagated to the user.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (DROOLS-1529) Return in new item returns to the home screen instead of creating the item
by Martijn Burger (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1529?page=com.atlassian.jira.plugi... ]
Martijn Burger commented on DROOLS-1529:
----------------------------------------
Just tested this item in 7.0.0.CR2 and is still present there. Also tested the item in different browsers and I can reproduce the item in Edge, Chrome and Internet Explorer. Firefox works okay, there no reaction on hitting enter.
> Return in new item returns to the home screen instead of creating the item
> --------------------------------------------------------------------------
>
> Key: DROOLS-1529
> URL: https://issues.jboss.org/browse/DROOLS-1529
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.0.0.CR1
> Environment: wildfly 10.0 - Windows 10 - Microsoft Edge
> Reporter: Martijn Burger
> Assignee: Guilherme Carreiro
> Priority: Minor
>
> When I create a new item in the KIE Workbench, for instance a DRL file, after entering the item name when a hit enter, I expect that the item will be created. Instead the system returns me to the home screen without creating the item.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[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 updated WFCORE-2746:
------------------------------
Description:
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.
was:
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.*
org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase
org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]
[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.
> 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
[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:
-----------------------------------
org.jboss.as.test.integration.security.perimeter.* look like they need Arqullian, I assume the test runner bit will remove this requirement?
I don't see an org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase anywhere, in either core or full, am I missing something?
> 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.*
> org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase
> org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]
> [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.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years
[JBoss JIRA] (WFCORE-2738) SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy()
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2738?page=com.atlassian.jira.plugi... ]
Radoslav Husar updated WFCORE-2738:
-----------------------------------
Fix Version/s: 3.0.0.Beta18
> SubDeploymentProcessor leaks Attachments.SUB_DEPLOYMENTS on undeploy()
> ----------------------------------------------------------------------
>
> Key: WFCORE-2738
> URL: https://issues.jboss.org/browse/WFCORE-2738
> Project: WildFly Core
> Issue Type: Bug
> Affects Versions: 3.0.0.Beta17
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 3.0.0.Beta18
>
>
> {noformat}
> 19:33:36,944 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".DEPENDENCIES: org.jboss.msc.service.StartException in service jboss.deployment.unit."clusterbench-ee7-singleton-jbossall.ear".DEPENDENCIES: WFLYSRV0153: Failed to process phase DEPENDENCIES of deployment "clusterbench-ee7-singleton-jbossall.ear"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:172)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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.NullPointerException
> at org.jboss.as.server.deployment.module.SubDeploymentDependencyProcessor.deploy(SubDeploymentDependencyProcessor.java:74)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:165)
> ... 5 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years