[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1067:
-------------------------------------------
One other issue here: at present there is no easy way to pass objects to JGroups protocol layers for use in configuration. Traditionally, JGroups protocol layers are configured by passing string based properties to the protocol, and those properties are then used to configure the protocol instances. This puts limitations on our ability to configure protocol stacks with existing object-based information. The issue https://issues.jboss.org/browse/WFLY-7882 will address this limitation.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1067 at 1/16/17 5:04 PM:
--------------------------------------------------------------------
Add to this the need to secure probe.sh via a passcode so that non-authorized users cannot probe a cluster which has probe operations restricted to authorized users. When running probe in authorised mode, the passcode is set in the configuration of the transport on the server(s) with the property diagnostics_passcode..
configuration: JGroups probe authentication
--------------------------------------------------------
The TP layer on a server (i.e. UDP/TCP) can make use of probe in an authenticated mode by configuring it with a probe passcode. This passcode could be provisoned by (i) providing a security-realm attribute for the UDP/TCP layer and then (ii) obtaining the passcode from the specified security realm as a configured <secret-key/>
was (Author: rachmato):
Add to this the need to secure probe.sh via a passcode so that non-authorized users cannot probe a cluster which has been secured with a probe passcode. The passcode is set in the configuration of the transport with the property diagnostics_passcode..
configuration: probe
--------------------------
The TP layer requires a passcode (or secret key) to configure the use of the DiagnosticsHandler in authenticated mode: in this mode, only users who configure their probe client with the same passcode can have their probe requests processed by the server. This passcode could be configured by providing a security-realm attribute for the UDP/TCP layer and then obtaining the passcode from the security realm as a configured <secret-key/>
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1067 at 1/16/17 4:52 PM:
--------------------------------------------------------------------
Add to this the need to secure probe.sh via a passcode so that non-authorized users cannot probe a cluster which has been secured with a probe passcode. The passcode is set in the configuration of the transport with the property diagnostics_passcode..
configuration: probe
--------------------------
The TP layer requires a passcode (or secret key) to configure the use of the DiagnosticsHandler in authenticated mode: in this mode, only users who configure their probe client with the same passcode can have their probe requests processed by the server. This passcode could be configured by providing a security-realm attribute for the UDP/TCP layer and then obtaining the passcode from the security realm as a configured <secret-key/>
was (Author: rachmato):
Add to this the need to secure probe.sh via a passcode so that non-authorized users cannot probe a cluster which has been secured with a probe passcode. The passcode is set in the configuration of the transport with the property diagnostics_passcode..
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1067 at 1/16/17 4:15 PM:
--------------------------------------------------------------------
Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm
There are two issues:
- configuration of SASL/ENCRYPT via existing security realm XML elements
- accessing the configured security realm data from the associated services for injection into ENCRYPT
existing security realm configuration
---------------------------------------------
Relevant to this discussion, the security realm contains the following XML configuration elements:
{code:xml}
<server-identities>
<ssl/>
<secret/>
</server-identities>
<authentication>
<users/>
<local/>
<ldap/>
<properties/>
<jaas/>
<truststore/>
</authentication>
<authorization>
<properties/>
</authorization>
{code}
where::
- the <ssl/> element is designed for setting up key material for an SSLContext for incoming remote connections
- the <truststore/> element is designed for setting up key material for SSL two way authentication
- the <secret/> element is designed for setting up access to a simple secret key / passcode
configuration: JGroups SASL layer
--------------------------------------------
The existing SASL integration (in JDG) makes use of the configuration in <authorization/>.
The JGroups SASL layer supports these mechanisms:
||SASL mechanism employed || SecurityRealm mechanism used || CallbackHandler available ||
| PLAIN | PLAIN | PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler|
| DIGEST_MD5 | DIGEST | PropertiesCallbackHandler, UserDomainCallbackHandler |
| GSSAPI | PLAIN | (see above)|
|EXTERNAL | CLIENT_CERT | ClientCertCallbackHandler|
where:
- mechanism determines the way in which user data is handled/encoded between client and server
- callback handler determines how the user data is actually obtained
So, for example:
- if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the <properties/> or <users/> elements with user information
- if we want to use the PLAIN mechanism, we should populate the <properties/>, <ldap/>, <jaas/> or <users/> elements with user information
In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs.
configuration: JGroups ENCRYPT layer
--------------------------------------------------
The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use:
- symmetric encryption: a keystore for storing a single secret key
- asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment)
As we need a keystore for ENCRYPT usage, should we:
- reuse the <ssl> element for this purpose?
- create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. <cluster-ssl>
reuse <ssl/> option
------------------------
If we did reuse the <ssl/> element, we would need to cater to the situation where:
- need to provide SSL two way authentication for incoming connections (using both the <ssl/> and the <truststore/> elements) and
- need to use the <ssl/> keystore to additionally store secret keys, public keys and private keys for ENCRYPT
This could be achieved by:
- sharing a single <ssl/> element between the incoming connections requiring SSL and JGroups peers joining a group
- always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the <ssl/> element for both cases
Some small problems:
1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the <ssl/> attribute provider="JCEKS".
2. The other problem here is that access to the service representing the keystore is not intended for public consumption.
The <ssl/> element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do.
use <cluster-ssl/> option
-------------------------------
If we create a new element of <server-identities/> to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT.
Reuse of the <ssl/> element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity.
was (Author: rachmato):
Based on the previous comments, using SASL for authentication and ENCRYPT for encryption for EAP is a minimal solution for integration of JGroups security with the securty realm
There are two issues:
- configuration of SASL/ENCRYPT via existing security realm XML elements
- accessing the configured security realm data from the associated services for injection into ENCRYPT
existing security realm configuration
---------------------------------------------
Relevant to this discussion, the security realm contains the following XML configuration elements:
{code:xml}
<server-identities>
<ssl/>
<secret/>
</server-identities>
<authentication>
<users/>
<local/>
<ldap/>
<properties/>
<jaas/>
<truststore/>
</authentication>
<authorization>
<properties/>
</authorization>
{code}
where::
- the <ssl/> element is designed for setting up key material for an SSLContext for incoming remote connections
- the <truststore/> element is designed for setting up key material for SSL two way authentication
configuration: JGroups SASL layer
--------------------------------------------
The existing SASL integration (in JDG) makes use of the configuration in <authorization/>.
The JGroups SASL layer supports these mechanisms:
||SASL mechanism employed || SecurityRealm mechanism used || CallbackHandler available ||
| PLAIN | PLAIN | PropertiesCallbackHandler, UserLdapCallbackHandler, JaasCallbackHandler, UserDomainCallbackHandler|
| DIGEST_MD5 | DIGEST | PropertiesCallbackHandler, UserDomainCallbackHandler |
| GSSAPI | PLAIN | (see above)|
|EXTERNAL | CLIENT_CERT | ClientCertCallbackHandler|
where:
- mechanism determines the way in which user data is handled/encoded between client and server
- callback handler determines how the user data is actually obtained
So, for example:
- if we want to use the DIGEST_MD5 mechanism in SASL, we should populate the <properties/> or <users/> elements with user information
- if we want to use the PLAIN mechanism, we should populate the <properties/>, <ldap/>, <jaas/> or <users/> elements with user information
In other words, the JGroups SASL layer reuses the provided callback handlers provided by the SecurityRealm to support its mechanisms and their need for specific user information. So, in this case, it is possible to reuse the existing security realm XML elements and fully cover all SASL layer needs.
configuration: JGroups ENCRYPT layer
--------------------------------------------------
The ENCRYPT integration needs to provide key material for ENCRYPT depending on the mode of use:
- symmetric encryption: a keystore for storing a single secret key
- asymmetric key distribution: a keystore for storing a peer's public/private key pairs (these are auto-generated at the moment)
As we need a keystore for ENCRYPT usage, should we:
- reuse the <ssl> element for this purpose?
- create a new element which would be specific to a JGroups ENCRYPT keystore? e.g. <cluster-ssl>
reuse <ssl/> option
------------------------
If we did reuse the <ssl/> element, we would need to cater to the situation where:
- need to provide SSL two way authentication for incoming connections (using both the <ssl/> and the <truststore/> elements) and
- need to use the <ssl/> keystore to additionally store secret keys, public keys and private keys for ENCRYPT
This could be achieved by:
- sharing a single <ssl/> element between the incoming connections requiring SSL and JGroups peers joining a group
- always using one defined SecurityRealm instance for incoming connections and another SecurityRealm instance for JGroups and using the <ssl/> element for both cases
Some small problems:
1. a standard JKS keystore cannot store secret keys; so we must force the keystore type to be JCEKS, via the <ssl/> attribute provider="JCEKS".
2. The other problem here is that access to the service representing the keystore is not intended for public consumption.
The <ssl/> element generates three MSC services: SSLContextService, KeyManagerService, TrustManagerService. The KeyManagerService (resp. TrustManagerService) represent key material which the SSLContextService needs to perform the SSL authentication. The KeyManagerService (resp. TrustManagerService) is in turn backed by a FileKeyManagerService which holds the instance of the loaded keystore. Access to SecretKeys is not available through the KeyManager, despite the fact that the javadoc says that it provides one KeyManager for each type of key material (PrivateKey, SecretKey, TrustedCertificate). There do not seem to be any KeyManager implementations other than X509KeyManager. So access to the keystore would need to be via FileKeyManagerService. At present, access to the keystore in FileKeyManagerService is protected; if it were public, we could access the keystore directly and do what we need to do.
use <cluster-ssl/> option
-------------------------------
If we create a new element of <server-identities/> to represent the identity of the server withn a cluster, we could use a separately configured keystore and service which did not create the associated SSLContextService/KeyManagerService/TrustManagerService and perhaps provided a specialised service which allowed accesing the keystore in the way required by ENCRYPT.
Reuse of the <ssl/> element for clustering means no changes to the schema and less integration work; on the other hand, it sort of hides the fact that the server does have what could be considered a distinct clustered security identity.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7104) Elytron properties-realm enforces REALM_NAME comment
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-7104?page=com.atlassian.jira.plugin.... ]
Kabir Khan resolved WFLY-7104.
------------------------------
Resolution: Done
> Elytron properties-realm enforces REALM_NAME comment
> ----------------------------------------------------
>
> Key: WFLY-7104
> URL: https://issues.jboss.org/browse/WFLY-7104
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Fix For: 11.0.0.Alpha1
>
>
> Elytron enforces existence of {{"#$REALM_NAME=...$"}} comment in property file referenced from properties-realms.
> When using legacy security and this line is missing, server starts without error.
> *Expected behavior:*
> Elytron's properties-realm *doesn't require* this comment. If the comment is present, it *may* verify if its content fits the realm name.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-1067 at 1/16/17 3:54 PM:
--------------------------------------------------------------------
What follows is a proposal for integrating JGroups with Wildfly in the short term, and some comments on what to do in the longer term. These comments are based on discussions with Bela and the clustering group (all confessed security non-experts). I'd also appreciate any input from Wildfly security gurus.
issues
------
The integration of JGroups security protocols into Wildfly touches on these issues:
- the AUTH and ENCRYPT protocols are not standards-based, the implementations are old and the implementations do not make use of "modern" security mechanisms such as callbacks and SSLContexts for obtaining authentication information and setting up encrypted channels. Part of the reason for this is that they must cater to both unicast and multicast communication between peers, and so the protocols are customized to that end.
- the SASL protocol is standards-based but does not implement the standard fully; support for Quality of Protection in a multicast environment is not provided, and so is a not a complete authentication / encryption solution
- more modern forms of providing authentication and encryption, such as TLS, are not supported
- Wildfly security is being revamped by Elytron and this should be taken into account
longer term
-----------
In the longer term, deprecating AUTH and ENCRYPT for a SASL layer and a TLS layer, to come up to standard with "modern" security, might be an desirable improvement on the current situation. The SASL layer could have QoP added in the form of multicast-friendly encryption, based on the modern security mechanisms referred to earlier, in a pared down, clean implementation. These would also play well with security domains.
short term
------------
In the short term, we want to support AUTH, ENCRYPT and SASL via configuration specified in security realms. Achieving this through direct use of security realms is not easy as AUTH and ENCRYPT require access to security information in a form which is hidden by the SecurityRealm interface (e.g. ENCRYPT does its own parsing of keystores and does not make use of callbacks). SASL in its current form can be configured for authentication using the security realm interface as it is based on callbacks for authentication.
Refactoring JGroups AUTH and ENCRYPT to conform to the SecurityRealm interface is a lot of work; a much simper option is to bypass the security realm interface and read the file information from the security realm model itself (i.e. obtaining the keystore and truststore filenames themselves and using those to initialise AUTH and ENCRYPT). Tweaking of ciphers and key sizes can still be handled through properties.
Also, using an SPI for this in the short term may not be useful. The Remoting Connector uses a RemotingSecurityProvider SPI and a RealmSecurityProvider SPI provider to translate between the OptionsMap, Callbacks and SSLContext which Remoting expects and the OptionsMap, Callbacks and SSLContext which the security realm provides. This interface will probably not change as it is based on an agreed set of "modern" mechanisms. A JGroupsSecurityProvider SPI would be a bit of a mess, given what was said earlier and that fact that this may change significantly and soon.
So, the proposal is to implement the integration, specified at the user level as described in a previous post, and get the required security configuration information as described above (from the model, in the case of AUTH and ENCRYPT). And in the longer term, move to a more modern implementation as the JGroups protocols are refactored and as Elytron becomes more widely used.
Feedback appreciated.
was (Author: rachmato):
What follows is a proposal for integrating JGroups with Wildfly in the short term, and some comments on what to do in the longer term. These comments are based on discussions with Bela and the clustering group (all confessed security non-experts). I'd also appreciate any input from Wildfly security gurus.
issues
------
The integration of JGroups security protocols into Wildfly touches on these issues:
- the AUTH and ENCRYPT protocols are not standards-based, the implementations are old and the implementations do not make use of "modern" security mechanisms such as callbacks and SSLContexts for obtaining authentication information and setting up encrypted channels
- the SASL protocol is standards-based but does not implement the standard fully; support for Quality of Protection in a multicast environment is not provided, and so is a not a complete authentication / encryption solution
- more modern forms of providing authentication and encryption, such as TLS, are not supported
- Wildfly security is being revamped by Elytron and this should be taken into account
longer term
-----------
In the longer term, deprecating AUTH and ENCRYPT for a SASL layer and a TLS layer, to come up to standard with "modern" security, might be an desirable improvement on the current situation. The SASL layer could have QoP added in the form of multicast-friendly encryption, based on the modern security mechanisms referred to earlier, in a pared down, clean implementation. These would also play well with security domains.
short term
------------
In the short term, we want to support AUTH, ENCRYPT and SASL via configuration specified in security realms. Achieving this through direct use of security realms is not easy as AUTH and ENCRYPT require access to security information in a form which is hidden by the SecurityRealm interface (e.g. ENCRYPT does its own parsing of keystores and does not make use of callbacks). SASL in its current form can be configured for authentication using the security realm interface as it is based on callbacks for authentication.
Refactoring JGroups AUTH and ENCRYPT to conform to the SecurityRealm interface is a lot of work; a much simper option is to bypass the security realm interface and read the file information from the security realm model itself (i.e. obtaining the keystore and truststore filenames themselves and using those to initialise AUTH and ENCRYPT). Tweaking of ciphers and key sizes can still be handled through properties.
Also, using an SPI for this in the short term may not be useful. The Remoting Connector uses a RemotingSecurityProvider SPI and a RealmSecurityProvider SPI provider to translate between the OptionsMap, Callbacks and SSLContext which Remoting expects and the OptionsMap, Callbacks and SSLContext which the security realm provides. This interface will probably not change as it is based on an agreed set of "modern" mechanisms. A JGroupsSecurityProvider SPI would be a bit of a mess, given what was said earlier and that fact that this may change significantly and soon.
So, the proposal is to implement the integration, specified at the user level as described in a previous post, and get the required security configuration information as described above (from the model, in the case of AUTH and ENCRYPT). And in the longer term, move to a more modern implementation as the JGroups protocols are refactored and as Elytron becomes more widely used.
Feedback appreciated.
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-1067) Integrate JGroups with core AS security infrastructure
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-1067?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-1067:
-------------------------------------------
Add to this the need to secure probe.sh via a passcode so that non-authorized users cannot probe a cluster which has been secured with a probe passcode. The passcode is set in the configuration of the transport with the property diagnostics_passcode..
> Integrate JGroups with core AS security infrastructure
> ------------------------------------------------------
>
> Key: WFLY-1067
> URL: https://issues.jboss.org/browse/WFLY-1067
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering, Security
> Reporter: Brian Stansberry
> Assignee: Richard Achmatowicz
>
> Container task for better integrating JGroups security with overall AS security. The basic concept is the various security aware aspects of JGroups will expose an SPI, and the AS can create implementations of those SPIs that integrate with the AS security realms. The AS JGroups subsystem will inject the implementation into the JGroups runtime components.
> Subtasks are for the various aspects. These can be done separately but a common overall design should be created to ensure a consistent approach is taken.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz updated JGRP-2152:
--------------------------------------
Attachment: org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean2.txt
> ASYM_ENCRYPT failure on Wildfly 10.1.0
> --------------------------------------
>
> Key: JGRP-2152
> URL: https://issues.jboss.org/browse/JGRP-2152
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Matt Wringe
> Assignee: Bela Ban
> Fix For: 4.0, 3.6.13
>
> Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean2.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml
>
>
> Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken.
> I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security
> Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing.
> Note: running this on EAP fails in a similar manner.
> Eg:
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">true</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JGRP-2152) ASYM_ENCRYPT failure on Wildfly 10.1.0
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/JGRP-2152?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on JGRP-2152:
-------------------------------------------
Re-ran the Wildfly clustering testsuite with Wildfly 10.1.0.Final incorporating JGroups 3.6.12.Final and the clustering testsuite passes. Attaching the log as org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean2.txt
> ASYM_ENCRYPT failure on Wildfly 10.1.0
> --------------------------------------
>
> Key: JGRP-2152
> URL: https://issues.jboss.org/browse/JGRP-2152
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.10
> Reporter: Matt Wringe
> Assignee: Bela Ban
> Fix For: 4.0, 3.6.13
>
> Attachments: hawkular-metrics-1.log, hawkular-metrics-2.log, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output-clean.txt, org.jboss.as.test.clustering.cluster.cdi.CdiFailoverTestCase-SYNC-tcp-output.txt, standalone.xml
>
>
> Using ASYM_ENCRYPT on Wildfly 10.1.0 seems to be broken.
> I am using the parameters for ASYM_ENCRYPT specified in http://www.jgroups.org/manual/index.html#Security
> Note: running with SYM_ENCRYPT doesn't cause any issues and it works fine with my setup. Its only ASYM_ENCRYPT which is currently failing.
> Note: running this on EAP fails in a similar manner.
> Eg:
> <protocol type="ASYM_ENCRYPT">
> <property name="encrypt_entire_message">true</property>
> <property name="sym_keylength">128</property>
> <property name="sym_algorithm">AES/ECB/PKCS5Padding</property>
> <property name="asym_keylength">512</property>
> <property name="asym_algorithm">RSA</property>
> </protocol>
> If I run a single instance, then I don't see any problems appear in the logs. Its when I start a second instance that I start to see errors about unrecognised ciphers and timeouts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months