[JBoss JIRA] (JGRP-2104) NAMING: provide logical names when IpAddressUUID is used as addresses
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2104?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-2104:
---------------------------
Description:
This is a new protocol, typically added somewhere above discovery (e.g. {{PING}}). When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used.
If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members.
{{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well.
Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs.
was:
This is a new protocol, typically added somewhere above {{NAKACK2}}. When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used.
If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members.
{{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well.
Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs.
> NAMING: provide logical names when IpAddressUUID is used as addresses
> ---------------------------------------------------------------------
>
> Key: JGRP-2104
> URL: https://issues.jboss.org/browse/JGRP-2104
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> This is a new protocol, typically added somewhere above discovery (e.g. {{PING}}). When {{TP.use_ip_addr}} is true, {{IpAddressUUID}} addresses will be used.
> If {{Discovery.max_rank_to_reply}} is less than the max rank of the cluster view, not all members will receive discovery responses. They therefore won't have a mapping between the address and the logical name for all members.
> {{NAMING}} fixes this by having the joiner multicast the address:name mapping after joining, and by everyone sending their mapping to the newly joined member as well.
> Note that this protocol is not strictly necessary; as {{IpAddressUUID}} addresses will also work without logical names mapped to them, but it improves legibility, e.g. of logs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFLY-7193) No log messages comming from Elytron - ssl context creation
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-7193?page=com.atlassian.jira.plugin.... ]
Jan Kalina reassigned WFLY-7193:
--------------------------------
Assignee: Jan Kalina
> No log messages comming from Elytron - ssl context creation
> -----------------------------------------------------------
>
> Key: WFLY-7193
> URL: https://issues.jboss.org/browse/WFLY-7193
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> Elytron is missing any log messages related to ssl context creation. These log messages should be added. See JBEAP-6041 for more details.
> Seems to me it would be useful for troubleshooting to have logged on TRACE level:
> - Keystore initialization with parameters
> - Filtering keystore initialization with parameters
> - KeyManager / TrustManager initialization with parameters
> - Client / Server SSLContext initialization with parameters
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (ELY-627) Elytron introduces SSL/TLS protocol constraints
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/ELY-627?page=com.atlassian.jira.plugin.sy... ]
Martin Choma commented on ELY-627:
----------------------------------
Also note, there should be possible to configure protocols like "openssl.TLS" introduced by https://issues.jboss.org/browse/WFCORE-1757.
> 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)
7 years, 7 months
[JBoss JIRA] (WFCORE-673) Elytron Integration with Core
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-673?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-673:
------------------------------------
Fix Version/s: 3.0.0.Alpha10
(was: 3.0.0.Alpha9)
> Elytron Integration with Core
> -----------------------------
>
> Key: WFCORE-673
> URL: https://issues.jboss.org/browse/WFCORE-673
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Blocker
> Fix For: 3.0.0.Alpha10
>
>
> This is the top level tracking task for Elytron integration within core. The tasks for the changes actually being made will either be linked or added as sub-tasks.
> In addition to this general issues that affect the Elytron integration are being labelled with 'affects_elytron' and can be queried using the following query: -
> https://issues.jboss.org/issues/?filter=12323574
> The label is a general catch-all for issues that are of interest to us but are not automatically blockers for our progress.
> The general criteria for the resolution of this issue will be: -
> - Inclusion of the Elytron Subsystem in core
> - All network entry points in core to be securable using Elytron
> - All SSL artefacts to be obtainable from Elytron.
> Note: The legacy modes will become better defined as we progress but whilst it must be possible to use Elytron it's use may still be optional to a certain degree.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFCORE-610) Integrate Elytron for management security.
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-610?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-610:
------------------------------------
Fix Version/s: 3.0.0.Alpha10
(was: 3.0.0.Alpha9)
> Integrate Elytron for management security.
> ------------------------------------------
>
> Key: WFCORE-610
> URL: https://issues.jboss.org/browse/WFCORE-610
> Project: WildFly Core
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 3.0.0.Alpha10
>
>
> This is a top level container task for the integration of Elytron for domain management security.
> Do note however that the purpose of Elytron is a single unified security solution across the whole of the application server so many tasks here will be groundwork for the remainder of the integration.
> At the moment the Elytron subsystem is being developed outside of wildfly-core, this will need to change in the future due to dependency issues (i.e. to write a subsystem you need to depend on core and core will need to include the subsystem (I think.)). However this will make it easier for now to ensure that the subsystem is 100% with no WildFly code accessing the subsystem - and also verify that we can create a distribtion with out the subsystem and still have a functional server.
> Overall if someone came up with an alternative subsystem that provided the same capabilities it should be possible to drop it in.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFCORE-363) ManagementResourceRegistration.getOverrideModel never returns null
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-363?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-363:
------------------------------------
Fix Version/s: 3.0.0.Alpha10
(was: 3.0.0.Alpha9)
> ManagementResourceRegistration.getOverrideModel never returns null
> ------------------------------------------------------------------
>
> Key: WFCORE-363
> URL: https://issues.jboss.org/browse/WFCORE-363
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha10
>
>
> ManagementResourceRegistration.getOverrideModel ends up returning the wildcard registration if there is no override registration. This isn't correct.
> The fix isn't trivial because fixing it results in nasty failures in the smoke tests. From looking at the uses of this method (which all involve a null check) I assume there are some bugs in the code that calls this method that get exposed once it does what it should.
> This bug is the cause of the initial failure of my WFLY-2880 fix.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFCORE-311) Better error message if authentication is required to connect to the master but no realm is associated on the slave
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-311?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-311:
------------------------------------
Fix Version/s: 3.0.0.Alpha10
(was: 3.0.0.Alpha9)
> Better error message if authentication is required to connect to the master but no realm is associated on the slave
> -------------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-311
> URL: https://issues.jboss.org/browse/WFCORE-311
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Environment: RH EL 6.3 - JBoss EAP 6.2
> Reporter: Riccardo Benvenuti
> Assignee: Brian Stansberry
> Priority: Minor
> Fix For: 3.0.0.Alpha10
>
>
> In JBoss 6.2 domain environment if in the host.xml file on the slave is missing the realm in the domain-controller tag as reported below
> <domain-controller>
> <remote host="10.123.137.200" port="9999"/>
> </domain-controller>
> we get the following error:
> JBoss Bootstrap Environment
> JBOSS_HOME: /opt/jboss7/jboss-eap-6.2
> JAVA: /usr/java/jdk1.7.0_51/bin/java
> JAVA_OPTS: -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 16:45:58,529 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> 16:45:58,746 INFO [org.jboss.as.process.Host Controller.status] (main) JBAS012017: Starting process 'Host Controller'
> [Host Controller] 16:45:59,735 INFO [org.jboss.modules] (main) JBoss Modules version 1.3.0.Final-redhat-2
> [Host Controller] 16:45:59,913 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA-redhat-1
> [Host Controller] 16:46:00,023 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015899: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) starting
> [Host Controller] 16:46:00,991 INFO [org.xnio] (MSC service thread 1-1) XNIO Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,010 INFO [org.xnio.nio] (MSC service thread 1-1) XNIO NIO Implementation Version 3.0.7.GA-redhat-1
> [Host Controller] 16:46:01,033 INFO [org.jboss.as] (Controller Boot Thread) JBAS010902: Creating http management service using network interface (management) port (9990) securePort (-1)
> [Host Controller] 16:46:01,045 INFO [org.jboss.remoting] (MSC service thread 1-1) JBoss Remoting version 3.2.18.GA-redhat-1
> [Host Controller] 16:46:01,173 INFO [org.jboss.as.remoting] (MSC service thread 1-1) JBAS017100: Listening on 10.123.137.201:9999
> [Host Controller] 16:46:01,857 ERROR [org.jboss.remoting.remote.connection] (Remoting "testjb7s1:MANAGEMENT" read-1) JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> [Host Controller] 16:46:01,869 ERROR [org.jboss.as.host.controller] (Controller Boot Thread) JBAS010901: Could not connect to master. Aborting. Error was: java.lang.IllegalStateException: JBAS010942: Unable to connect due to authentication failure.
> [Host Controller] 16:46:01,891 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (missing) dependents: [service jboss.server.controller.management.security_realm.ApplicationRealm]
> [Host Controller]
> [Host Controller] 16:46:01,897 INFO [org.jboss.as.controller] (MSC service thread 1-1) JBAS014774: Service status report
> [Host Controller] JBAS014775: New missing/unsatisfied dependencies:
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (missing) dependents: [service jboss.remoting.authentication_provider.management]
> [Host Controller]
> [Host Controller] 16:46:01,922 INFO [org.jboss.as.controller] (MSC service thread 1-2) JBAS014774: Service status report
> [Host Controller] JBAS014776: Newly corrected services:
> [Host Controller] service jboss.server.controller.management.security_realm.ApplicationRealm.properties_authentication (no longer required)
> [Host Controller] service jboss.server.controller.management.security_realm.ManagementRealm (no longer required)
> [Host Controller]
> [Host Controller] 16:46:01,927 INFO [org.jboss.as] (MSC service thread 1-2) JBAS015950: JBoss EAP 6.2.0.GA (AS 7.3.0.Final-redhat-14) stopped in 28ms
> 16:46:02,245 INFO [org.jboss.as.process.Host Controller.status] (reaper for Host Controller) JBAS012010: Process 'Host Controller' finished with an exit status of 99
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012016: Shutting down process controller
> 16:46:02,247 INFO [org.jboss.as.process] (Thread-8) JBAS012015: All processes finished; exiting
> Adding the realm everything works correctly
> <domain-controller>
> <remote host="10.123.137.200" port="9999" security-realm="ManagementRealm"/>
> </domain-controller>
> Maybe a warning message could be useful to find the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFCORE-13) End users can call non-published management API operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-13?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFCORE-13:
-----------------------------------
Fix Version/s: 3.0.0.Alpha10
(was: 3.0.0.Alpha9)
> End users can call non-published management API operations
> ----------------------------------------------------------
>
> Key: WFCORE-13
> URL: https://issues.jboss.org/browse/WFCORE-13
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Reporter: Ladislav Thon
> Labels: EAP
> Fix For: 3.0.0.Alpha10
>
>
> It's not possible to call "non-published" operations (those that are not visible in the resource tree, e.g. {{describe}}) via JMX, while it's entirely possible to call them via CLI (e.g. {{/subsystem=security:describe}}) and other management interfaces.
> The problem lies in the fact that {{ModelControllerMBeanHelper.invoke}} method checks {{if (!accessControl.isExecutableOperation(operationName))}} and the {{isExecutableOperation}} method assumes that the operation will be visible in the resource tree. In fact, there is a comment stating _should not happen_, but now we know that it indeed _can_ happen.
> What's more, it gives a misleading error message. The {{isExecutableOperation}} returns {{false}} for unknown operations, which results in {{Not authorized to invoke operation}} message. Which is wrong in two different ways simultaneously: 1. the problem isn't authorization, but the fact that the operation can't be found; 2. the user (e.g. in the {{SuperUser}} role) _is_ authorized.
> I'm considering this low priority, because 1. JMX is likely to be very rarely used to access the management interface, 2. hiding information isn't nearly as important as leaking them, 3. non-published operations aren't nearly as important as the published ones. It's worth a JIRA nevertheless.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months
[JBoss JIRA] (WFCORE-1282) Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1282?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1282:
-------------------------------------
Fix Version/s: 3.0.0.Alpha10
(was: 3.0.0.Alpha9)
> Unable to create HTTPS connection using *ECDH_RSA* cipher suites / kECDHr cipher string
> ---------------------------------------------------------------------------------------
>
> Key: WFCORE-1282
> URL: https://issues.jboss.org/browse/WFCORE-1282
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Affects Versions: 1.0.2.Final
> Environment: Oracle Java
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 3.0.0.Alpha10
>
> Attachments: client_debug_eap6.log, client_debug_eap7.log, server-cert-key-ec.jks, server_debug_eap6.log, server_debug_eap7.log
>
>
> User using these cipher suites / cipher name in EAP6 won't be able to use it in EAP7.
> Setting as critical as these cipher suites, are considered for strong and widely used in my opinion.
> In server log, error "no cipher suites in common" can be seen using -Djavax.net.debug=all.
> Note, that analogous configuration in EAP6 works fine.
> Issue can be seen on Oracle Java only, as on OpenJDK / IBM these suites are not provided by method getDefaultCipherSuites().
> Also is it possible to log "no cipher suites in common" and similar tls handshake errors without -Djavax.net.debug for better troubleshooting?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
7 years, 7 months