[JBoss JIRA] (ELY-1052) For the wrapped SSLEngine and SSLSockets allow further restriction of cipher suites.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1052:
-------------------------------------
Summary: For the wrapped SSLEngine and SSLSockets allow further restriction of cipher suites.
Key: ELY-1052
URL: https://issues.jboss.org/browse/ELY-1052
Project: WildFly Elytron
Issue Type: Enhancement
Components: SSL
Reporter: Darran Lofthouse
Fix For: 2.0.0.Alpha1
We should allow further configuration where this configuration leads to a union of centrally enabled cipher suites with API specified cipher suites.
i.e. an administrator can centrally define the acceptable cipher suites but utilities using the APIs can restrict this further.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-2615:
---------------------------------
Description:
In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
We request blocker since it allows to use some SASL mechanisms even if they are not allowed on client side.
was:
In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
We request blocker since this issue blocks RFE EAP7-567 and EAP7-568 and it allows to use some SASL mechanisms even if they are not allowed on client side.
> Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-2615
> URL: https://issues.jboss.org/browse/WFCORE-2615
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta10
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: dep.war, wireshark.pcapng
>
>
> In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
> See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
> This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
> We request blocker since it allows to use some SASL mechanisms even if they are not allowed on client side.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-2615:
---------------------------------
Affects Version/s: 3.0.0.Beta10
> Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-2615
> URL: https://issues.jboss.org/browse/WFCORE-2615
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta10
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: dep.war, wireshark.pcapng
>
>
> In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
> See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
> This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
> We request blocker since this issue blocks RFE EAP7-567 and EAP7-568 and it allows to use some SASL mechanisms even if they are not allowed on client side.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
by Ondrej Lukas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ]
Ondrej Lukas updated WFCORE-2615:
---------------------------------
Attachment: dep.war
wireshark.pcapng
> Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-2615
> URL: https://issues.jboss.org/browse/WFCORE-2615
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 3.0.0.Beta10
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Blocker
> Attachments: dep.war, wireshark.pcapng
>
>
> In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
> See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
> This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
> We request blocker since this issue blocks RFE EAP7-567 and EAP7-568 and it allows to use some SASL mechanisms even if they are not allowed on client side.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
by Ondrej Lukas (JIRA)
Ondrej Lukas created WFCORE-2615:
------------------------------------
Summary: Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration
Key: WFCORE-2615
URL: https://issues.jboss.org/browse/WFCORE-2615
Project: WildFly Core
Issue Type: Bug
Components: Security
Reporter: Ondrej Lukas
Assignee: Darran Lofthouse
Priority: Blocker
In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms.
See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce".
This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client.
We request blocker since this issue blocks RFE EAP7-567 and EAP7-568 and it allows to use some SASL mechanisms even if they are not allowed on client side.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8496) Unclear model description of core-pool-size attribute in IO subsystem
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-8496?page=com.atlassian.jira.plugin.... ]
Romain Pelisse commented on WFLY-8496:
--------------------------------------
Adding upstream issue for JBEAP-8418.
> Unclear model description of core-pool-size attribute in IO subsystem
> ---------------------------------------------------------------------
>
> Key: WFLY-8496
> URL: https://issues.jboss.org/browse/WFLY-8496
> Project: WildFly
> Issue Type: Bug
> Components: IO
> Affects Versions: 11.0.0.Alpha1
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Minor
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> */subsystem=io/worker=*:read-attribute(name=core-pool-size)*
> Current model description: "Core worker thread pool size"
> Suggested improvement: "Minimum number of threads to keep in the underlying java.util.concurrent.ThreadPoolExecutor even if they are idle. Threads over this limit will be terminated over time specified by task-keepalive attribute."
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8496) Unclear model description of core-pool-size attribute in IO subsystem
by Romain Pelisse (JIRA)
Romain Pelisse created WFLY-8496:
------------------------------------
Summary: Unclear model description of core-pool-size attribute in IO subsystem
Key: WFLY-8496
URL: https://issues.jboss.org/browse/WFLY-8496
Project: WildFly
Issue Type: Bug
Components: IO
Affects Versions: 11.0.0.Alpha1
Reporter: Romain Pelisse
Assignee: Romain Pelisse
Priority: Minor
*/subsystem=io/worker=*:read-attribute(name=core-pool-size)*
Current model description: "Core worker thread pool size"
Suggested improvement: "Minimum number of threads to keep in the underlying java.util.concurrent.ThreadPoolExecutor even if they are idle. Threads over this limit will be terminated over time specified by task-keepalive attribute."
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8495) WF TS should pass with non-"en_US.UTF-8" locale settings
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-8495?page=com.atlassian.jira.plugin.... ]
Marek Kopecký updated WFLY-8495:
--------------------------------
Summary: WF TS should pass with non-"en_US.UTF-8" locale settings (was: EAP TS should pass with non-"en_US.UTF-8" locale settings)
> WF TS should pass with non-"en_US.UTF-8" locale settings
> --------------------------------------------------------
>
> Key: WFLY-8495
> URL: https://issues.jboss.org/browse/WFLY-8495
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Alpha1
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> EAP TS should pass with non-"en_US.UTF-8" locale settings. These tests needs to be fixed:
> * org.jboss.as.test.integration.ee.injection.resource.jndi.bad.BadResourceTestCase#testBadDU
> * org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneLongRunningThreadPool
> * org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneShortRunningThreadPool
> * org.jboss.as.test.integration.jpa.epcpropagation.slsbxpc.FailBecauseOfXPCNotInSFSBTestCase#testSerialization
> * org.jboss.as.test.integration.jpa.epcpropagation.unsync.TestForMixedSynchronizationTypes#testShouldGetEjbExceptionBecauseEPCIsAddedToTxAfterPc
> * org.jboss.as.test.integration.ws.authentication.EJBEndpointNoClassLevelSecurityAnnotationAuthenticationTestCase#accessHelloWithAuthenticatedUser
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8495) WF TS should pass with non-"en_US.UTF-8" locale settings
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-8495?page=com.atlassian.jira.plugin.... ]
Marek Kopecký updated WFLY-8495:
--------------------------------
Description:
WF TS should pass with non-"en_US.UTF-8" locale settings. These tests needs to be fixed:
* org.jboss.as.test.integration.ee.injection.resource.jndi.bad.BadResourceTestCase#testBadDU
* org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneLongRunningThreadPool
* org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneShortRunningThreadPool
* org.jboss.as.test.integration.jpa.epcpropagation.slsbxpc.FailBecauseOfXPCNotInSFSBTestCase#testSerialization
* org.jboss.as.test.integration.jpa.epcpropagation.unsync.TestForMixedSynchronizationTypes#testShouldGetEjbExceptionBecauseEPCIsAddedToTxAfterPc
* org.jboss.as.test.integration.ws.authentication.EJBEndpointNoClassLevelSecurityAnnotationAuthenticationTestCase#accessHelloWithAuthenticatedUser
was:
EAP TS should pass with non-"en_US.UTF-8" locale settings. These tests needs to be fixed:
* org.jboss.as.test.integration.ee.injection.resource.jndi.bad.BadResourceTestCase#testBadDU
* org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneLongRunningThreadPool
* org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneShortRunningThreadPool
* org.jboss.as.test.integration.jpa.epcpropagation.slsbxpc.FailBecauseOfXPCNotInSFSBTestCase#testSerialization
* org.jboss.as.test.integration.jpa.epcpropagation.unsync.TestForMixedSynchronizationTypes#testShouldGetEjbExceptionBecauseEPCIsAddedToTxAfterPc
* org.jboss.as.test.integration.ws.authentication.EJBEndpointNoClassLevelSecurityAnnotationAuthenticationTestCase#accessHelloWithAuthenticatedUser
> WF TS should pass with non-"en_US.UTF-8" locale settings
> --------------------------------------------------------
>
> Key: WFLY-8495
> URL: https://issues.jboss.org/browse/WFLY-8495
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Alpha1
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> WF TS should pass with non-"en_US.UTF-8" locale settings. These tests needs to be fixed:
> * org.jboss.as.test.integration.ee.injection.resource.jndi.bad.BadResourceTestCase#testBadDU
> * org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneLongRunningThreadPool
> * org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneShortRunningThreadPool
> * org.jboss.as.test.integration.jpa.epcpropagation.slsbxpc.FailBecauseOfXPCNotInSFSBTestCase#testSerialization
> * org.jboss.as.test.integration.jpa.epcpropagation.unsync.TestForMixedSynchronizationTypes#testShouldGetEjbExceptionBecauseEPCIsAddedToTxAfterPc
> * org.jboss.as.test.integration.ws.authentication.EJBEndpointNoClassLevelSecurityAnnotationAuthenticationTestCase#accessHelloWithAuthenticatedUser
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months
[JBoss JIRA] (WFLY-8495) EAP TS should pass with non-"en_US.UTF-8" locale settings
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-8495?page=com.atlassian.jira.plugin.... ]
Marek Kopecký moved JBEAP-10089 to WFLY-8495:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-8495 (was: JBEAP-10089)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR15)
> EAP TS should pass with non-"en_US.UTF-8" locale settings
> ---------------------------------------------------------
>
> Key: WFLY-8495
> URL: https://issues.jboss.org/browse/WFLY-8495
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Alpha1
> Reporter: Marek Kopecký
> Assignee: Marek Kopecký
>
> EAP TS should pass with non-"en_US.UTF-8" locale settings. These tests needs to be fixed:
> * org.jboss.as.test.integration.ee.injection.resource.jndi.bad.BadResourceTestCase#testBadDU
> * org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneLongRunningThreadPool
> * org.jboss.as.test.integration.jca.workmanager.WorkManagerThreadsCheckTestCase#testOneShortRunningThreadPool
> * org.jboss.as.test.integration.jpa.epcpropagation.slsbxpc.FailBecauseOfXPCNotInSFSBTestCase#testSerialization
> * org.jboss.as.test.integration.jpa.epcpropagation.unsync.TestForMixedSynchronizationTypes#testShouldGetEjbExceptionBecauseEPCIsAddedToTxAfterPc
> * org.jboss.as.test.integration.ws.authentication.EJBEndpointNoClassLevelSecurityAnnotationAuthenticationTestCase#accessHelloWithAuthenticatedUser
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 6 months