[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse moved WFLY-7076 to ELY-627:
--------------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-627 (was: WFLY-7076)
Component/s: SSL
(was: Security)
Affects Version/s: 1.1.0.Beta8
(was: 11.0.0.Alpha1)
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: ELY-627
> URL: https://issues.jboss.org/browse/ELY-627
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.1.0.Beta8
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ]
Darran Lofthouse updated ELY-627:
---------------------------------
Priority: Critical (was: Major)
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: ELY-627
> URL: https://issues.jboss.org/browse/ELY-627
> Project: WildFly Elytron
> Issue Type: Bug
> Components: SSL
> Affects Versions: 1.1.0.Beta8
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Critical
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFCORE-1788) Allow tests to retrieve IP address of node1
by Jan Martiska (JIRA)
Jan Martiska created WFCORE-1788:
------------------------------------
Summary: Allow tests to retrieve IP address of node1
Key: WFCORE-1788
URL: https://issues.jboss.org/browse/WFCORE-1788
Project: WildFly Core
Issue Type: Enhancement
Components: Test Suite
Affects Versions: 3.0.0.Alpha7
Reporter: Jan Martiska
Assignee: Jan Martiska
Currently, the {{TestSuiteEnvironment}} only allows to obtain the address of node0.
Multinode tests in the wildfly full repository which need to obtain the address of node1, do it in various non-standardized ways, it would be nice to standardize that by adding a method to obtain node1's address and refactoring the tests to use it.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (ELY-626) Adding simple-permission-mapper with some permission throws NPE
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-626?page=com.atlassian.jira.plugin.sy... ]
Jan Kalina moved WFLY-7082 to ELY-626:
--------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-626 (was: WFLY-7082)
Component/s: Permissions
(was: Security)
Affects Version/s: (was: 11.0.0.Alpha1)
> Adding simple-permission-mapper with some permission throws NPE
> ---------------------------------------------------------------
>
> Key: ELY-626
> URL: https://issues.jboss.org/browse/ELY-626
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Permissions
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> Adding simple-permission-mapper with ChangeRoleMapperPermission or RunAsPrincipalPermission throws NPE. In case when LoginPermission is used then it works correctly.
> {code}
> /subsystem=elytron/simple-permission-mapper=SomeMapper:add(permission-mappings=[{roles=[All],permissions=[{class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission"}]}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.SomeMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.SomeMapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> NPE occurs in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.permission-mapper.SomeMapper: org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.wildfly.security.permission.ByNamePermissionCollection.doAdd(ByNamePermissionCollection.java:59)
> at org.wildfly.security.permission.AbstractPermissionCollection.add(AbstractPermissionCollection.java:83)
> at java.security.Permissions.add(Permissions.java:133)
> at org.wildfly.extension.elytron.PermissionMapperDefinitions.createSimplePermissionMapper(PermissionMapperDefinitions.java:214)
> at org.wildfly.extension.elytron.PermissionMapperDefinitions.access$000(PermissionMapperDefinitions.java:67)
> at org.wildfly.extension.elytron.PermissionMapperDefinitions$2.lambda$getValueSupplier$0(PermissionMapperDefinitions.java:188)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7082) Adding simple-permission-mapper with some permission throws NPE
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7082?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-7082:
----------------------------------
Problem is missing null name check in permission - will be fixed in Elytron.
> Adding simple-permission-mapper with some permission throws NPE
> ---------------------------------------------------------------
>
> Key: WFLY-7082
> URL: https://issues.jboss.org/browse/WFLY-7082
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> Adding simple-permission-mapper with ChangeRoleMapperPermission or RunAsPrincipalPermission throws NPE. In case when LoginPermission is used then it works correctly.
> {code}
> /subsystem=elytron/simple-permission-mapper=SomeMapper:add(permission-mappings=[{roles=[All],permissions=[{class-name="org.wildfly.security.auth.permission.ChangeRoleMapperPermission"}]}])
> {
> "outcome" => "failed",
> "failure-description" => {
> "WFLYCTL0080: Failed services" => {"org.wildfly.security.permission-mapper.SomeMapper" => "org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service
> Caused by: java.lang.NullPointerException"},
> "WFLYCTL0412: Required services that are not installed:" => ["org.wildfly.security.permission-mapper.SomeMapper"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> },
> "rolled-back" => true
> }
> {code}
> NPE occurs in server log:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service org.wildfly.security.permission-mapper.SomeMapper: org.jboss.msc.service.StartException in service org.wildfly.security.permission-mapper.SomeMapper: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> 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.wildfly.security.permission.ByNamePermissionCollection.doAdd(ByNamePermissionCollection.java:59)
> at org.wildfly.security.permission.AbstractPermissionCollection.add(AbstractPermissionCollection.java:83)
> at java.security.Permissions.add(Permissions.java:133)
> at org.wildfly.extension.elytron.PermissionMapperDefinitions.createSimplePermissionMapper(PermissionMapperDefinitions.java:214)
> at org.wildfly.extension.elytron.PermissionMapperDefinitions.access$000(PermissionMapperDefinitions.java:67)
> at org.wildfly.extension.elytron.PermissionMapperDefinitions$2.lambda$getValueSupplier$0(PermissionMapperDefinitions.java:188)
> at org.wildfly.extension.elytron.TrivialService.start(TrivialService.java:53)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-7098) Double check parallel boot and ApplicationSecurityDomain definitions are compatible
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-7098?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-7098:
----------------------------------------
Parallel boot is implemented as 2 steps in the overall set of boot operation steps, with one for Stage.MODEL and one for Stage.RUNTIME. Each step submits tasks that concurrently process ops for their stage. Each task process ops for a single subsystem. The step that submits those tasks blocks and does not complete until all the tasks it has submitted complete. So, the next step in the overall set of boot operation steps does not begin executing until the parallel tasks complete.
Deployment ops execute after subsystem steps because until the subsystems have run the DUP chain is not known.
> Double check parallel boot and ApplicationSecurityDomain definitions are compatible
> -----------------------------------------------------------------------------------
>
> Key: WFLY-7098
> URL: https://issues.jboss.org/browse/WFLY-7098
> Project: WildFly
> Issue Type: Task
> Components: EJB, Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Need to check there is no option for parallel boot to start deploying deployment before the full management model has been processed to the point all known ApplicationSecurityDomain definitions are known for both EJB and Undertow.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months