ESB 4.12 is not passing/using client basic authentication header for http gateway

[david.adams]

My configuration is similar to that shown in the Boss dropping responses from web service thread.

When you call an http gateway from a jQuery client on a different machine using an ajax call with GET, the authentication is stripped from the request before it gets to the MessageComposer. 

The request fails with a SecurityServicesException stating that the "Service blah has been configured for security but no AuthenticationRequest could be located in the Message Context. ..."  It appears that the authentication was stripped by the container and not used to create the principals prior to the request being passed to the MessageContext object.  No Authentication information could be found in the request when it reached the MessageContext.

It also fails when you make the same call from a non-browser client and build the http request and stuff in the authentication.

Now, if you make the same http call from the address field on the browser:

• the JBoss ESB Server requests the credentials
• you are presented with the basic login form on the browser
• you enter the credentials
• walla - everything works just fine

Why is basic authentication stripped from the request when it comes via JQuery ajax or a client application?

Example ajax call: (Not perfect, but you get the idea, just look at any tutorial on how to do it.)

$.ajax({

   type:'GET',

   dataType: 'text',

   contentType:'text/plain;charset=utf-8',

   url: [esb gateway address goes here],

   beforeSend: function(xhr) {

         xhr.setRequestHeader("Authorization", en_auth);

   },

   success: success,

   error: this.getErrorHandler(error)

});

...

BTW:  You also cannot POST, and the POST content does not get put into the message either.

Oh, and just one more thing.  It works just fine if you run the client and esb http gateway all on the same server.

I discovered this because I needed to separate out services to a different machine.

(jbossesb-server-4.10 has the same behavior)

[tcunning]

David,

Can you upload a small reproducible test case?  It sounds like you have one already - you can attach it as a tar.gz or .zip to this thread.

I took a quick look through the JIRAs on httpgateway and couldn't find anything there, but it'd really help if I had your full test case.

--Tom

[mageshbk]

It is strange that it works from a browser rather than the ajax client. Could you post a TRACE server.log of both the browser based request and the failed ajax request? Please make sure you enable TRACE on the jboss.web component.

regards,

Magesh

[david.adams]

Tom,

Sorry it has taken me so long to get back to you.  Unfortunately, I cannot provide example code.  I'll try and build some sample code, but the key here is separate servers.  I'm sure you would have the same issue that I've found. 

I've been using ESB since 2007 to wrap 3rd party software applications and make them available via ESB.  Things have been working well until this problem came up. 

I can describe my simple deployment.

  A MySQL database server with JUDDI, user, and data database.

  An ESB 4.12 server "A"  Microsoft Server 2008 R2, Java 7u51, everything is 64bit Database Realm.

  An ESB 4.12 server "B" Microsoft Server 2008 R2, Java 7u51, everything is 64bit   Database Realm.

  Both ESB Services run under the same windows service account.

All services use the security Database realm and basic authentication.

Two services:  For simplicity, lets name them

1) Router

2) Converter

Initial configuration that failed:

  Server A contains a war file to provide an interface for users wishing to select and configure the processes that will be run.

  Server B contains the http gateway for the "Router" Service.  The gateway is a simple router to select which service to run.  The router is not the ESB router because it was built when we were running Java 7 and ESB 4.9 which didn't support Drools with Java7. (Yes, I understand 4.12 fixed that issue)  So, it creates a Service object and uses the Invoker to send an async message to the Converter on Server B.  You should note that no exceptions are thrown while using the Invoker.

  Both servers have a custom Realm for security that is tied to a database.

  In this configuration, a javascript client could not directly call the HttpGateway and pass credentials as that failed.

  So, since the javascript app came from Server A, I built a proxy servlet on server A to make the call to the http gateway. The proxy gets called and tries to call the HttpGateway.  That fails with a 500 error if I remember correctly.

  What did work was calling the proxy directly from the browser on a remote client by entering its URL.  It asked for credentials and that worked, the credentials passed, and the service ran.

Final configuration.

  Same as the first except move the HTTP Gateway to ESB Server A.

  This situation worked.  The service complained about the credentials being passed and then checked them for itself and ran the service.

I've had this running for the last month.

Moving on to a new most likely related issue:

I've now deployed this to our production server environment.

The call to the HTTPGateway works, the service executes, but I am now getting an Unresponsive EPR JMSEpr for both the HTTPGateway service name and the selected service on service B.  So, eventually, the HTTPGateway returns a 500 because the "Router" service never returned.

After having spent 6 business days trying to figure this out, I'm pretty worn/stressed out.

So, on the production deployment:

The httpgateway is called.

The security check passes

the service is started

The first action (system print) dumps the message

The second action correctly determines which service to call and then gets the correct information from JUDDI

At this point, I see an EPR Helper message and then Unresponsive EPR JMSEpr (with the correct JUDDI info)

At some point, I also see an UnresponsiveEPR JMSEpr for the service with the gateway.  (I configured it with both an HTTP Gateway and a JMS ESB queue.

I'm not sure why it is calling the JMS Queue on this service. There is no need and none of my code initiated it.

Eventually, an exception is thrown about no response for the Router service, so the gateway returns a 500 to the client.

The ESB, as it should, continues to try and call the service on Server  B.

That all tells me that the httpgateway router is actually getting the message in to the local JMS handler because it then tries to resend up to ten times.

So, why is ServerB not responding.  BTW. The logs on server B do not print out anything.  It is not being called.

All I get is UnresponsiveEPR JMSEpr for the correct address.

And no, I have checked the JUDDI DB and all services registered from each ESB server are correct.  There are no duplicates.

Other steps taken:

* I had the IT folks open all ports on both machines in case a port was being blocked.

* I removed all the security from server B, so no credentials were required to call the "Converter" service.

* I rolled both Server A and B back to ESB 4.10.  Same failure.

* tried Java 7U45 both 64 and 32bit

* I tried reconfiguring the providers

I finally had to move the services on Server B to Server A. and I took server B offline.  That works just fine.  Everything runs on the same server.

The only issue is that I need to be able to deploy the services that were on Server B across many servers to handle the workload.  Again, they run third-party software that processes data.  Each service can take tens of minutes to execute.

I'm not too happy with ESB at this point.

It appears to me that JMS is not working at all between the machines, but I'm not getting any exceptions anywhere except the UnresponsiveEPR...

I know that deploying services to different machines and deploying the same service on multiple machines should work. That I why I have been using ESB.  I have not required that until now.  I tested it way back in ESB 4.6 across three machines.  It worked just fine (no security).  It should work today, but does not.

Any ideas?

This should be a very basic situation for ESB.

But, I suspect it is a JMS failure, so my next step is to reconfigure a different JMS.  What could block JMS from going between machines on port 1099?

I would suspect that it is a Java 7U51 problem, but I'm running that on both system. As I mentioned above, I've ruled that out already.

David

9:21pm

Ok, so this second issue that I raised was due to failure to execute "trust but verify" on my part.  I trusted IT to open the ports for JBoss.  They confirmed the ports were open between the machines.  When I finally checked them a little while ago, I found the firewall settings were not allowing JBoss ESB Servers to talk with each other!  Once I opened the ports things worked. 

This does not remove or answer the initial posting though.  That is still an issue.  I'll try and build some example code shortly and post it.

[tcunning]

David,

If you can get us some sample code, we can definitely take a look.