[JBoss JIRA] (AS7-4309) EJB client API implementation is missing configuration which enables "silent auth" for cluster nodes
4:43 a.m.
Radoslav Husar created AS7-4309:
-----------------------------------
Summary: EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:55 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Darran Lofthouse commented on AS7-4309:
---------------------------------------
Looking at the title what would the benefit be of adding configuration to enable silent
authentication for cluster nodes? Once you move into clustered deployments I would expect
multiple remote machines to be involved which would mean silent authentication is not an
option anyway.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:11 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Radoslav Husar commented on AS7-4309:
-------------------------------------
The EJB client and a cluster node might be collocated.
To be honest though, I don't like the default silent auth for EJB/JMS clients at all.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:39 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Darran Lofthouse commented on AS7-4309:
---------------------------------------
There is not default silent auth for JMS client but we are reviewing disabling it by
default for EJB clients - we just need to verify if there is a quickstart impact if we do
that.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:41 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Radoslav Husar commented on AS7-4309:
-------------------------------------
Darran, do you have a jira for that already (?) because I am in the middle of filing one
:-)
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
6:47 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Darran Lofthouse commented on AS7-4309:
---------------------------------------
Go ahead an create one - the first steps to make it possible to disable server side are in
but the default config still needs a re-review.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
7:46 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Radoslav Husar commented on AS7-4309:
-------------------------------------
Created AS7-4310.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:46 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
jaikiran pai commented on AS7-4309:
-----------------------------------
{quote}
Looking at the title what would the benefit be of adding configuration to enable silent
authentication for cluster nodes? Once you move into clustered deployments I would expect
multiple remote machines to be involved which would mean silent authentication is not an
option anyway.
{quote}
Technically, multiple nodes on the same system (a typical dev env) can be involved in the
cluster too.
{quote}
but we are reviewing disabling it by default for EJB clients - we just need to verify if
there is a quickstart impact if we do that.
{quote}
It will definitely have an impact of the quickstart (atleast the ejb-remote one). I am in
favour of removing the silent auth *by default* too. However, IIRC, Stuart had introduced
this to be the default for some specific reason. I'll point him to this JIRA and see
if he has any objections to removing silent auth by default for EJB clients.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:04 p.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas commented on AS7-4309:
-------------------------------------
The main reason was to allow developers to get started with remote EJB's quickly,
without having to add users and configure security.
I think it could be a usability issue if developers have to setup security before they can
get started.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:34 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Darran Lofthouse commented on AS7-4309:
---------------------------------------
Ok I think lets keep this open for a little to consider further and maybe we can discuss a
little further.
When deploying an EJB it is down to the developer / deployer to decide if the EJB is
secured - AS7 is now secured by default so this current setting offers a reasonable
compromise of allowing unsecured deployments without making them accessible remotely
unsecured.
The bigger issue we have run into is that once the developer / depoyer enables security on
the EJBs they don't want the local mechanism to be used at all for even local calls as
they need true authentication to pick up the users roles for the authorization checks.
The setting could either be globally disabled on the remoting connection (server side) -
the issue is this is shared by multiple services so what makes sense for one may not make
sense for the others.
Clients can also control which mechanisms they will use so may still be the better place
to fine control this.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
1:35 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Stuart Douglas commented on AS7-4309:
-------------------------------------
I have seen some issues on the forum where silent auth has actually caused problems, so
its a +1 from me for disabling it.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_need_triage
Fix For: 7.1.2.Final-redhat1
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
4:34 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Darran Lofthouse commented on AS7-4309:
---------------------------------------
I am also +1 for disabling for the EJB calls due to the confusion when it silently kicks
in - however the main point that needs to be considered is the quickstarts they are
intended to work out of the box so any default changes would also need to be reflected
there that is actually the one reason I haven't already gone ahead and switched this
off.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_need_triage
Fix For: 7.1.2.Final-redhat1
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
11:30 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Jason Greene commented on AS7-4309:
-----------------------------------
I believe the majority of users don't use ejb security, so disabling silent auth would
be problematic for our most common case. Further the usability problems in the forums
primarily affect those with custom login modules, which is even a smaller group of users.
After discussing with Darran I think we agreed that the real issue is authorization
problems which are caused by a hardcoded restriction that we have which makes you have to
use the local$ user. The plan is to remove the local$ user restriction and introduce a
configuration for local auth (AS7-4887). By default a client can pass in any username, and
it will be accepted. A user can decide to restrict this to a certain user by editing the
xml. They can also remove it entirely and disable local auth. This should solve the
usability problems with those that are using role based authentication and custom modules.
Once Darran has made that change, we need to make a small change to ejb-client to remove
the hardcoded local$, although that's acceptable as a default.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_need_triage
Fix For: 7.1.2.Final-redhat1
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:13 p.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
jaikiran pai commented on AS7-4309:
-----------------------------------
{quote}
The plan is to remove the local$ user restriction and introduce a configuration for local
auth (AS7-4887)
{quote}
For reference, the JIRA is AS7-4487
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_need_triage
Fix For: 7.1.2.Final-redhat1
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
2:28 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
jaikiran pai resolved AS7-4309.
-------------------------------
Resolution: Done
Resolving this. See
https://issues.jboss.org/browse/AS7-4310?focusedCommentId=12690504&pa...
for the details.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Labels: eap6_need_triage
Fix For: 7.1.2.Final (EAP)
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:24 a.m.
[
https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.s...
]
Radoslav Husar closed AS7-4309.
-------------------------------
I am happy with the fix now, closing.
EJB client API implementation is missing configuration which enables
"silent auth" for cluster nodes
----------------------------------------------------------------------------------------------------
Key: AS7-4309
URL: https://issues.jboss.org/browse/AS7-4309
Project: Application Server 7
Issue Type: Bug
Components: EJB, Security
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: jaikiran pai
Fix For: 7.1.2.Final (EAP)
rhusar:
{quote} No authentication mechanism is specified in the test and the remoting connector
has a security realm set-up (by default) but I am invoking SLSB with no problem.{quote}
{noformat}
11:31:12,630 INFO [org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager]
(ejb-client-cluster-node-connection-creation-3-thread-2) Could not create a connection for
cluster node ClusterNode{clusterName='ejb',
nodeName='node-1',
clientMappings=[ClientMapping{sourceNetworkAddress=/0:0:0:0:0:0:0:0,
sourceNetworkMaskBits=0, destinationAddress='127.0.0.1',
destinationPort=4547}], resolvedDestination=[Destination address=127.0.0.1, destination
port=4547]} in cluster ejb: java.lang.RuntimeException: javax.security.sasl.SaslException:
Authentication failed: all available authentication mechanisms failed
at org.jboss.ejb.client.remoting.IoFutureHelper.get(IoFutureHelper.java:91)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:91)
at
org.jboss.ejb.client.ClusterContext$EJBReceiverAssociationTask.run(ClusterContext.java:333)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: javax.security.sasl.SaslException: Authentication failed: all available
authentication mechanisms failed
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:365)
at
org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:214)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at
org.xnio.channels.TranslatingSuspendableChannel.handleReadable(TranslatingSuspendableChannel.java:189)
at
org.xnio.channels.TranslatingSuspendableChannel$1.handleEvent(TranslatingSuspendableChannel.java:103)
at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:72)
at org.xnio.nio.NioHandle.run(NioHandle.java:90)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:184)
at ...asynchronous invocation...(Unknown Source)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:270)
at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
at
org.jboss.ejb.client.remoting.RemotingConnectionClusterNodeManager.getEJBReceiver(RemotingConnectionClusterNodeManager.java:89)
... 7 more
{noformat}
jpai:
{quote}
The reason why the invocation to the bean works is because the client is being run from
the same machine as the server. As a result the "silent auth" mechanism as
explained "Local clients" section of this doc [1] comes into picture. The EJB
client API by default has this mechanism enabled for connections it creates.
Now the reason why you see that stacktrace which indicates a failure to create an auto
connection to a node in the cluster is because the EJB client API implementation is
missing this piece of configuration which enables "silent auth" for cluster
nodes. We need to fix that to make it consistent with how we handle non-cluster node
connection creation.
[1] https://community.jboss.org/wiki/AS710Beta1-SecurityEnabledByDefault
{quote}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
5163
days inactive
5220
days old
15 comments
5 participants
participants (5)
-
Darran Lofthouse (JIRA) -
jaikiran pai (JIRA)
-
Jason Greene (JIRA)
-
Radoslav Husar (JIRA)
-
Stuart Douglas (JIRA)