EJB call across two servers gives XA error presumably due to security

[devu...@rediffmail.com]

Hi,

I have a situation where I'm making a remote EJB call to a stateless session bean on a different box. Both boxes have WAS 6.1 installed and the EJB's have the transaction attribute "Required".
EJB 1 on server 1 writes something to the database and then callse EJB2 on server 2. EJB2 on server 2 responds to the call and writes something to the same database using a different datasource.
The problem occurs when EJB1 on server 1 returns the method at the point it does the commit. I get a XA error.
*Imp: I have security turned on in server 2 and in this situation the call fails. If I turn off administrative security on server 2 altogether, the call succeeds*.
I read a post and tried to disable the protocol security on the transaction service on server 1 but it does not work. Any ideas? Given below is the entire stack trace
{code}
RegisteredRes E WTRN0046E: An attempt by the transaction manager to call prepare on a transactional resource has resulted in an error. The error code was XAER_RMERR. The exception stack trace follows: javax.transaction.xa.XAException
at com.ibm.ws.Transaction.JTS.CORBAResourceWrapper.processCORBASystemException(CORBAResourceWrapper.java:678)
at com.ibm.ws.Transaction.JTS.WSCoordinatorWrapper.prepare(WSCoordinatorWrapper.java:218)
at com.ibm.ws.Transaction.JTA.RegisteredResources.prepareResource(RegisteredResources.java:1410)
at com.ibm.ws.Transaction.JTA.RegisteredResources.distributePrepare(RegisteredResources.java:1726)
at com.ibm.ws.Transaction.JTA.TransactionImpl.prepareResources(TransactionImpl.java:2091)
at com.ibm.ws.Transaction.JTA.TransactionImpl.stage1CommitProcessing(TransactionImpl.java:1652)
at com.ibm.ws.Transaction.JTA.TransactionImpl.processCommit(TransactionImpl.java:1608)
at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java:1543)
at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java:240)
at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java:164)
at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:782)
at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:206)
at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:581)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:4311)
at dk.pbs.bs.clients.EJSLocal0SLManagerBean_367672ae.saveAgreement(EJSLocal0SLManagerBean_367672ae.java)
at dk.pbs.test.TestServlet.doGet(TestServlet.java:38)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:743)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1076)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:550)
at com.ibm.ws.wswebcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:486)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:90)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:744)
at com.ibm.ws.wswebcontainer.WebContainer.handleRequest(WebContainer.java:1455)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:115)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:458)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:387)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.ready(HttpInboundLink.java:267)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.sendToDiscriminators(NewConnectionInitialReadCallback.java:214)
at com.ibm.ws.tcp.channel.impl.NewConnectionInitialReadCallback.complete(NewConnectionInitialReadCallback.java:113)
at com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:165)
at com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
at com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:136)
at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:195)
at com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:743)
at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:873)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1473)

[6/12/09 17:23:39:625 IST] 0000002b RegisteredRes E WTRN0086I: XAException encountered during prepare phase for transaction {tranid}. Local resources follow.
[6/12/09 17:23:39:625 IST] 0000002b RegisteredRes E WTRN0089I: XATransactionWrapper@ 18821882 XAResource: com.ibm.ws.rsadapter.spi.WSRdbXaResourceImpl@187a187a enlisted: true mcWrapper.hashCode()393090926: Vote: commit.
{code}

[devu...@rediffmail.com]

Hi,

Wanted to post an update to this. It works if I disable Transaction security on both servers.

Can anyone point me to any resource which gives an exhaustive overview of WAS security features and their applicabilty to avoid specific vulnerabilites?
For example, I have solved this problem by disabling the "Transaction security" but I'm wondering why its there in the first place and what are the compromises I'm making by disabling it.

Thanks,

Devu.

[mani_k...@yahoo.com]

You can refer WAS security hand book @
http://www.redbooks.ibm.com/abstracts/sg246316.html

Thanks,
Mani

[LEMI...@uk.ibm.com]

Hi.

As you may have guessed this is 'as designed'. When you enable security on an application server the transaction service will automatically try and authenticate any transactional (JTS in this case) calls. There are two solutions to this:

1) Secure both app servers. This is the most ideal one
2) Disable transaction security on the secure server, not the insecure server

From a vulnerability point of view if you choose option 2 as opposed to option 1 you are allowing attackers to mess around with your distributed transactions.

Cheers, Matt.