[JBoss JIRA] (WFCORE-2053) CoreResourceManagementTestCase tests of composites are broken
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2053:
----------------------------------------
Summary: CoreResourceManagementTestCase tests of composites are broken
Key: WFCORE-2053
URL: https://issues.jboss.org/browse/WFCORE-2053
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Test Suite
Reporter: Brian Stansberry
Assignee: Brian Stansberry
CoreResourceManagementTestCase was broken when it was moved from full to core. A number of tests are testing adds of /host=x/server=y/subsystem=io/worker=default:add but these tests are bogus:
1) The worker already exists in the profile used by the DC.
2) The params passed to the add op are bogus (leftovers from the 'full' test that tested the threads subsystem.
The tests are primarily checking for failures but these issues mean they can be falsely passing; passing due to failures unrelated to what the test is checking.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7158:
-----------------------------------
Affects Version/s: (was: 11.0.0.Alpha1)
> Working with multiple keys in key store
> ---------------------------------------
>
> Key: WFLY-7158
> URL: https://issues.jboss.org/browse/WFLY-7158
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7158) Working with multiple keys in key store
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7158?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7158:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Working with multiple keys in key store
> ---------------------------------------
>
> Key: WFLY-7158
> URL: https://issues.jboss.org/browse/WFLY-7158
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> In case when 2 keys are present in keystore, then alias-filter (filtering into single key) on key-store resource has to be specified, otherwise key-manager can't be created. If user want to use keystore with multiple keys, user has to configure multiple key-store elements with specified alias-filter (filtering into single key).
> That is pretty inconvinient. Probably introducing *alias attribute on key-manager* would be more intuitive solution to this situation.
> {code}
> /subsystem=elytron/key-managers=server:add(key-store=server,algorithm="SunX509",password=key-password)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7587) Complicated failure-description for referral-mode in Elytron dir-context
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7587?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7587:
--------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Complicated failure-description for referral-mode in Elytron dir-context
> ------------------------------------------------------------------------
>
> Key: WFLY-7587
> URL: https://issues.jboss.org/browse/WFLY-7587
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Labels: user_experience
>
> In case when attribute {{referral-mode}} is added to {{dir-context}} with wrong value then failure-description includes IllegalArgumentException instead of some non-Java admin friendly description:
> {code}
> /subsystem=elytron/dir-context=dirContext:add(url=localhost,referral-mode=abc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: No enum constant org.wildfly.security.auth.realm.ldap.DirContextFactory.ReferralMode.abc",
> "rolled-back" => true
> }
> {code}
> Suggestion for improvement:
> Use the same type of failure-description as e.g. {{logical-role-mapper}}, see:
> {code}
> /subsystem=elytron/logical-role-mapper=logicalRoleMapper:add(logical-operation=abc)
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0248: Invalid value abc for logical-operation; legal values are [OR, AND, XOR, MINUS]",
> "rolled-back" => true
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2052) Bogus README.txt
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2052:
----------------------------------------
Summary: Bogus README.txt
Key: WFCORE-2052
URL: https://issues.jboss.org/browse/WFCORE-2052
Project: WildFly Core
Issue Type: Bug
Components: Server
Reporter: Brian Stansberry
Assignee: Jason Greene
The README.txt file is wrong:
1) It says WildFly 10. Wrong for core, and wrong #.
2) Talks about javaee.
Probably this file should move to full and a simple variant for core should be written.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7687) Authentication based on certificates does not work in Elytron with Undertow
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7687?page=com.atlassian.jira.plugin.... ]
Martin Choma updated WFLY-7687:
-------------------------------
Priority: Blocker (was: Critical)
> Authentication based on certificates does not work in Elytron with Undertow
> ---------------------------------------------------------------------------
>
> Key: WFLY-7687
> URL: https://issues.jboss.org/browse/WFLY-7687
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Jan Tymel
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: deployment.war, keystores.zip, standalone-elytron.xml
>
>
> It is not possible to set up authentication based on certificates. I followed the community documentation [1,2] to set up 2-way SSL for apps and certificates based auth. Everything worked as expected until I tried to deploy an app. I got this output
> {code}
> 14:50:29,352 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 65) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./deployment: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
> 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 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:237)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
> ... 6 more
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$initialSecurityHandler$4(ApplicationSecurityDomainDefinition.java:348)
> at java.lang.Iterable.forEach(Iterable.java:75)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.initialSecurityHandler(ApplicationSecurityDomainDefinition.java:345)
> at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService.lambda$applyElytronSecurity$0(ApplicationSecurityDomainDefinition.java:293)
> at io.undertow.servlet.core.DeploymentManagerImpl.setupSecurityHandlers(DeploymentManagerImpl.java:404)
> at io.undertow.servlet.core.DeploymentManagerImpl.access$600(DeploymentManagerImpl.java:119)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:207)
> at io.undertow.servlet.core.DeploymentManagerImpl$1.call(DeploymentManagerImpl.java:172)
> 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:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1671)
> at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:235)
> ... 8 more
> 14:50:29,356 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "deployment.war")]) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./deployment" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./deployment: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory.
> Caused by: java.lang.IllegalStateException: WFLYUT0085: The required mechanism 'CLIENT_CERT' is not available from the HttpAuthenticationFactory."},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.undertow.deployment.default-server.default-host./deployment"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> {code}
> This might be caused by different representation of {{CLIENT-CERT}} attribute within Elytron and Undertow. It appears that Elytron uses {{CLIENT-CERT}} [3] whereas Undertow uses {{CLIENT_CERT}} [4]
> [1] https://docs.jboss.org/author/display/WFLY/Elytron+Examples#ElytronExampl...
> [2] https://docs.jboss.org/author/display/WFLY/Elytron+Examples#ElytronExampl...
> [3] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/...
> [4] https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7639) Missing XSD for wildfly-config.xml
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7639?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-7639:
-----------------------------------
Fix Version/s: 11.0.0.Alpha1
> Missing XSD for wildfly-config.xml
> ----------------------------------
>
> Key: WFLY-7639
> URL: https://issues.jboss.org/browse/WFLY-7639
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 11.0.0.Alpha1
>
>
> There is a new client configuration required in `wildfly-config.xml` (more in JBEAP-7104), but the `docs/schema` folder doesn't contain its XSD (schema definition).
> We have to provide one with a sufficient description of the elements and attributes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7585) Auto-completion does not work for default-realm of Elytron security-domain in CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7585?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7585:
----------------------------------------
This is an Enhancement request.
There is no requirement that tab completion work everywhere. I consider missing tab completion due to missing cap/req implementation to be a bug (really the bug is the missing cap/req) but missing tab completion due to some other completion mechanism not existing is an RFE.
I wouldn't jump through any hoops trying to get tab completion to work here. If you want to change your model for other reasons, that's fine.
> Auto-completion does not work for default-realm of Elytron security-domain in CLI
> ---------------------------------------------------------------------------------
>
> Key: WFLY-7585
> URL: https://issues.jboss.org/browse/WFLY-7585
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Labels: user_experience
>
> Auto-completion does not work for default-realm of Elytron security-domain in CLI. All attributes of security-domain support auto-completion through {{<TAB>}} button. The only one which does not support it is default-realm. It is probably caused by missing capability-reference.
> Example:
> {code}
> /subsystem=elytron/security-domain=domain:add(default-realm=<TAB>
> {code}
> Does not show any security realms. However:
> {code}
> /subsystem=elytron/security-domain=domain:add(permission-mapper=<TAB>
> {code}
> Shows possible permission mappers.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7585) Auto-completion does not work for default-realm of Elytron security-domain in CLI
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7585?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-7585:
-----------------------------------
Issue Type: Enhancement (was: Bug)
> Auto-completion does not work for default-realm of Elytron security-domain in CLI
> ---------------------------------------------------------------------------------
>
> Key: WFLY-7585
> URL: https://issues.jboss.org/browse/WFLY-7585
> Project: WildFly
> Issue Type: Enhancement
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
> Labels: user_experience
>
> Auto-completion does not work for default-realm of Elytron security-domain in CLI. All attributes of security-domain support auto-completion through {{<TAB>}} button. The only one which does not support it is default-realm. It is probably caused by missing capability-reference.
> Example:
> {code}
> /subsystem=elytron/security-domain=domain:add(default-realm=<TAB>
> {code}
> Does not show any security realms. However:
> {code}
> /subsystem=elytron/security-domain=domain:add(permission-mapper=<TAB>
> {code}
> Shows possible permission mappers.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months