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

[Jason Greene (JIRA)]

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

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