[JBoss JIRA] (WFCORE-3002) (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3002?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3002:
-------------------------------------
Priority: Major (was: Blocker)
> (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3002
> URL: https://issues.jboss.org/browse/WFCORE-3002
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Josef Cacek
> Assignee: Brian Stansberry
>
> The ModelControllerClient is not able to force using SSL/TLS connection with management native interface.
> *Usecase:* As an administrator I want to be sure that a ModelControllerClient connection to management native-interface goes through a secure connection. (I.e. Client connection is only established when the server uses SSL/TLS).
> Setting a blocker priority, as this can lead to security leaks, when a client assumes the secure management connection is used and the opposite is true and such a connection can be easily eavesdropped.
> My first try was to use ModelControllerClient configuration to set SSL context:
> {code:java}
> new ModelControllerClientConfiguration.Builder().setSslContext(sslFactory.create())
> .setProtocol("remote");
> {code}
> Nevertheless such a configuration doesn't force using SSL and if the server doesn't have SSL context configured, then the created connection is a plain remoting one.
> Next try was to configure the SSL context in Elytron's {{AuthenticationContext}}:
> {code:java}
> AuthenticationContext.withSsl(MatchRule.ALL, sslContext)
> {code}
> The result was the same (i.e. plain connection was used). [~dlofthouse] commented on this on Hipchat:
> {quote}
> In terms of Elytron configuration generally the config provided is there so it can be used if it is needed rather than it forming some form of mandatory policy. So in this case I would expect you would drive that more with the protocol you specify e.g. remote+tls or remote+https
> {quote}
> Based on the comment I've used "remote+tls" protocol on the client:
> {code:java}
> ModelControllerClientConfiguration.Builder().setProtocol("remote+tls")
> {code}
> but in this case the connection fails even if the server has the sslContext configured:
> {code:xml}
> <management-interfaces>
> <native-interface sasl-authentication-factory="test-sasl-authn-factory" ssl-context="elytron-ssl-context">
> <socket-binding native="testbinding"/>
> </native-interface>
> ...
> </management-interfaces>
> {code}
> The failure:
> {noformat}
> java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ... [cropped]
> Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> ... 144 more
> Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) [jsse.jar:1.8.0_131]
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) [rt.jar:1.8.0_131]
> at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.unwrap(AbstractDelegatingSSLEngine.java:56) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.engineUnwrap(JsseSslConduitEngine.java:688) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:172) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:167) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioHandle$1.run(NioHandle.java:50) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:472) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:509) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> {noformat}
> Am I missing some piece of configuration here?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3002) (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3002?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3002:
-------------------------------------
Issue Type: Feature Request (was: Bug)
> (Elytron) ModelControllerClient connecting to management native-interface is not able to force SSL/TLS
> ------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3002
> URL: https://issues.jboss.org/browse/WFCORE-3002
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Domain Management, Security
> Reporter: Josef Cacek
> Assignee: Brian Stansberry
>
> The ModelControllerClient is not able to force using SSL/TLS connection with management native interface.
> *Usecase:* As an administrator I want to be sure that a ModelControllerClient connection to management native-interface goes through a secure connection. (I.e. Client connection is only established when the server uses SSL/TLS).
> Setting a blocker priority, as this can lead to security leaks, when a client assumes the secure management connection is used and the opposite is true and such a connection can be easily eavesdropped.
> My first try was to use ModelControllerClient configuration to set SSL context:
> {code:java}
> new ModelControllerClientConfiguration.Builder().setSslContext(sslFactory.create())
> .setProtocol("remote");
> {code}
> Nevertheless such a configuration doesn't force using SSL and if the server doesn't have SSL context configured, then the created connection is a plain remoting one.
> Next try was to configure the SSL context in Elytron's {{AuthenticationContext}}:
> {code:java}
> AuthenticationContext.withSsl(MatchRule.ALL, sslContext)
> {code}
> The result was the same (i.e. plain connection was used). [~dlofthouse] commented on this on Hipchat:
> {quote}
> In terms of Elytron configuration generally the config provided is there so it can be used if it is needed rather than it forming some form of mandatory policy. So in this case I would expect you would drive that more with the protocol you specify e.g. remote+tls or remote+https
> {quote}
> Based on the comment I've used "remote+tls" protocol on the client:
> {code:java}
> ModelControllerClientConfiguration.Builder().setProtocol("remote+tls")
> {code}
> but in this case the connection fails even if the server has the sslContext configured:
> {code:xml}
> <management-interfaces>
> <native-interface sasl-authentication-factory="test-sasl-authn-factory" ssl-context="elytron-ssl-context">
> <socket-binding native="testbinding"/>
> </native-interface>
> ...
> </management-interfaces>
> {code}
> The failure:
> {noformat}
> java.io.IOException: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ... [cropped]
> Caused by: java.net.ConnectException: WFLYPRT0053: Could not connect to remote+tls://127.0.0.1:10567. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:162) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:60) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> ... 144 more
> Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
> at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:156) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868) [jsse.jar:1.8.0_131]
> at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781) [jsse.jar:1.8.0_131]
> at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624) [rt.jar:1.8.0_131]
> at org.wildfly.security.ssl.AbstractDelegatingSSLEngine.unwrap(AbstractDelegatingSSLEngine.java:56) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.engineUnwrap(JsseSslConduitEngine.java:688) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslConduitEngine.unwrap(JsseSslConduitEngine.java:620) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ssl.JsseSslStreamSourceConduit.read(JsseSslStreamSourceConduit.java:126) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ConduitStreamSourceChannel.read(ConduitStreamSourceChannel.java:123) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.MessageReader.getMessage(MessageReader.java:131) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:172) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.remote.ClientConnectionOpenListener$Greeting.handleEvent(ClientConnectionOpenListener.java:167) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.NioHandle$1.run(NioHandle.java:50) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:592) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:472) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:545) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:509) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:497) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:194) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:118) [wildfly-cli-3.0.0.Beta26-client.jar:3.0.0.Beta26]
> {noformat}
> Am I missing some piece of configuration here?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3011) Revisit Resource Aggregation
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3011?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-3011:
----------------------------------------
Assignee: (was: Darran Lofthouse)
> Revisit Resource Aggregation
> ----------------------------
>
> Key: WFCORE-3011
> URL: https://issues.jboss.org/browse/WFCORE-3011
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Darran Lofthouse
>
> We have a number of components that can be chained together using an aggregate-* resource definition.
> Some resources may be better aggregated by defining their own dependency on an equivalent resource that should be chained first e.g. a principal-transformer could contain an attribute 'after'.
> Also where references are made to resources that are trivial to chain we could use an alternative string-list attribute definition to allow multiple references and then support chaining in order.
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-3011) Revisit Resource Aggregation
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3011?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-3011:
-------------------------------------
Fix Version/s: (was: 4.0.0.Alpha1)
> Revisit Resource Aggregation
> ----------------------------
>
> Key: WFCORE-3011
> URL: https://issues.jboss.org/browse/WFCORE-3011
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Security
> Reporter: Darran Lofthouse
>
> We have a number of components that can be chained together using an aggregate-* resource definition.
> Some resources may be better aggregated by defining their own dependency on an equivalent resource that should be chained first e.g. a principal-transformer could contain an attribute 'after'.
> Also where references are made to resources that are trivial to chain we could use an alternative string-list attribute definition to allow multiple references and then support chaining in order.
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (DROOLS-1652) Add an entry point on the kie-server to deploy a DMN files as a service
by Edson Tirelli (JIRA)
Edson Tirelli created DROOLS-1652:
-------------------------------------
Summary: Add an entry point on the kie-server to deploy a DMN files as a service
Key: DROOLS-1652
URL: https://issues.jboss.org/browse/DROOLS-1652
Project: Drools
Issue Type: Feature Request
Components: dmn engine, kie server
Affects Versions: 7.1.0.Beta3
Reporter: Edson Tirelli
Assignee: Edson Tirelli
Add an end point on the kie-server to deploy a DMN xml file directly as a service without the need for a kjar.
In other words, the end point would accept a POST with a DMN xml file as a payload, it would internally build a kjar in memory and deploy it as a kie-container.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2203) ASYM_ENCRYPT: no merge when coord is killed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2203?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2203 at 7/7/17 4:54 AM:
--------------------------------------------------------
The reason is that B as new coord creates a new shared secret and uses it to encrypt and send view \{B,C\}. However, as C doesn't yet have the new shared secret, it won't be able to install the new view.
Not getting the view change, C won't know that B is the new key server (it still thinks A is) and therefore C won't ask B for the new shared key.
Possible solutions:
* Have B encrypt and send the new view with the existing shared key, and change the shared key only after the view installation
* Notify everyone of the new key server; this would trigger key fetching from all members. Since such a notification message is sent below the reliable transmission protocols (NAKACK2, UNICAST3), we'd have to send until getting an ack from everyone (kind of like simplistic reliable transmission).
was (Author: belaban):
The reason is that B as new coord creates a new shared secret and uses it to encrypt and send view \{B,C\}. However, as C doesn't yet have the new shared secret, it won't be able to install the new view.
Not getting the view change, C won't know that B is the new key server (it still thinks A is) and therefore C won't ask B for the new shared key.
> ASYM_ENCRYPT: no merge when coord is killed
> -------------------------------------------
>
> Key: JGRP-2203
> URL: https://issues.jboss.org/browse/JGRP-2203
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: asym-encrypt.xml
>
>
> When we have \{A,B,C\} and A is killed, B and C never end up with the same view. (This works when A leaves gracefully).
> The sample config is attached as asym-encrypt.xml
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (JGRP-2203) ASYM_ENCRYPT: no merge when coord is killed
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2203?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2203:
--------------------------------
The reason is that B as new coord creates a new shared secret and uses it to encrypt and send view \{B,C\}. However, as C doesn't yet have the new shared secret, it won't be able to install the new view.
Not getting the view change, C won't know that B is the new key server (it still thinks A is) and therefore C won't ask B for the new shared key.
> ASYM_ENCRYPT: no merge when coord is killed
> -------------------------------------------
>
> Key: JGRP-2203
> URL: https://issues.jboss.org/browse/JGRP-2203
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0.5
>
> Attachments: asym-encrypt.xml
>
>
> When we have \{A,B,C\} and A is killed, B and C never end up with the same view. (This works when A leaves gracefully).
> The sample config is attached as asym-encrypt.xml
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-9055) cache-type attribute of security-domain element accepts invalid values
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-9055?page=com.atlassian.jira.plugin.... ]
Ingo Weiss updated WFLY-9055:
-----------------------------
Summary: cache-type attribute of security-domain element accepts invalid values (was: EAP 7.1 cache-type attribute of security-domain element accepts invalid values)
> cache-type attribute of security-domain element accepts invalid values
> ----------------------------------------------------------------------
>
> Key: WFLY-9055
> URL: https://issues.jboss.org/browse/WFLY-9055
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Beta1
> Reporter: Ingo Weiss
> Assignee: Ingo Weiss
> Priority: Minor
>
> What problem/issue/behavior are you having trouble with? What do you expect to see?
> It is possible to define the following without JBoss complaining:
> <subsystem xmlns="urn:jboss:domain:security:3.0">
> <security-domain name="iskv21c" cache-type="Hugo">
> [...]
> Expected behavior is that JBoss complains about invalid value "Hugo" (e.g. throws an Exception, refuses to start,..)
> According to the CLI, there are two valid options: default and infinispan
> }
> -----------------------
> [standalone@localhost:9990 /] /subsystem=security/security-domain=other:read-resource-description
> .. .. ..
> .. .. ..
> "attributes" => {"cache-type" => {
> "type" => STRING,
> "description" => "Adds a cache to speed up authentication checks. Allowed values are 'default' to use simple map as the cache and 'infinispan' to use an Infinispan cache.",
> "expressions-allowed" => true,
> "required" => false,
> "nillable" => true,
> "min-length" => 1L,
> "max-length" => 2147483647L,
> "allowed" => [
> "default",
> "infinispan"
> ],
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "no-services"
> }},
> -----------------------
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months