[jboss-jira] [JBoss JIRA] (AS7-4309) EJB client API implementation is missing configuration which enables "silent auth" for cluster nodes

Darran Lofthouse (JIRA) jira-events at lists.jboss.org
Thu Mar 29 05:34:47 EDT 2012


    [ https://issues.jboss.org/browse/AS7-4309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680247#comment-12680247 ] 

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

        


More information about the jboss-jira mailing list