• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Liutauras Vilda
  • Ron McLeod
Sheriffs:
  • Jeanne Boyarsky
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Scott Selikoff
  • Tim Holloway
  • Piet Souris
  • Mikalai Zaikin
  • Frits Walraven
Bartenders:
  • Stephan van Hulst
  • Carey Brown

Help needed to call a web service after TAM authentication - (401)Unauthorized

 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
We have a requirement to call a web service running on another websphere 6.1.
Our application runs on a different websphere 6.1 unix box. Between these two boxes, TAM authentication layer exists.
So my application being the client, I am trying to invoke a web service running on another machine.
All my client stubs are generated using Axis.

The web service that we are going to consume is https based web service.
Initially i had a problem in SSL handshake between websphere servers which I resolved successfully by adding the certificates in truststore.

Now to invoke the web service I am using a code as following:
Sample1InterfaceService service = new Sample1InterfaceServiceLocator();
Sample1Interface stub = service.getSample1();
(Sample1SoapBindingStub)stub)._setProperty(javax.xml.rpc.Stub.USERNAME_PROPERTY, domain + "\\" + username);
((Sample1SoapBindingStub)stub)._setProperty(javax.xml.rpc.Stub.PASSWORD_PROPERTY, password);
stub.getGreeting(someinput);

But i constantly get Axisfault error as (401)Unauthorized.
Basically TAM is blocking my requests as it is unable to authenticate (my user credentials are correct.. i have verified it many times. When i call the web service end point url on IE, it prompts for user id/password. On entering the credentials, it shows that web service is running. This also means TAM authenticated successfully and allowed me to pass through. So my credentials are correct).

I was going through this forum and many others and tried to apply various solutions that were proposed.
1) Send the web service endpoint URL as "http://username:password@websericeurl"
2) (Sample1SoapBindingStub)stub).setUsername(domain + "\\" + username);
(Sample1SoapBindingStub)stub).setPassword(password);

I tried the above options, by running a stand alone java program. But I am still getting the same error.
Any ideas what could be the problem?

My Axisfault error is as follows -
Exception in thread "main" AxisFault
faultCode: {http://xml.apache.org/axis/}HTTP
faultSubcode:
faultString: (401)Unauthorized
faultActor:
faultNode:
faultDetail:
{}:return code: 401
 
Nischit Shetty
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi - I also tried using JAX-WS.
Generated all JAX-WS stubs.

I am trying to perform the TAM authentication using the following code
Sample1Interface port = service.getSample1SOAP();
BindingProvider theBindingProvider = (BindingProvider)port ;
Map<String, Object> theRequestContext = theBindingProvider.getRequestContext();
theRequestContext.put("javax.xml.ws.security.auth.username", domain + "\\" + user");
theRequestContext.put("javax.xml.ws.security.auth.password", password);
port.getGreeting(someinput);

I am getting the following exception. Any clue?

Exception in thread "P=95493:O=0:CT" javax.xml.ws.WebServiceException: java.lang.StringIndexOutOfBoundsException
at org.apache.axis2.jaxws.ExceptionFactory.createWebServiceException(ExceptionFactory.java:175)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:70)
at org.apache.axis2.jaxws.ExceptionFactory.makeWebServiceException(ExceptionFactory.java:128)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:559)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.doInvoke(AxisInvocationController.java:118)
at org.apache.axis2.jaxws.core.controller.impl.InvocationControllerImpl.invoke(InvocationControllerImpl.java:82)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invokeSEIMethod(JAXWSProxyHandler.java:295)
at org.apache.axis2.jaxws.client.proxy.JAXWSProxyHandler.invoke(JAXWSProxyHandler.java:158)
at $Proxy25.getGreeting(Unknown Source)
...
Caused by: java.lang.StringIndexOutOfBoundsException
at java.lang.StringBuffer.substring(StringBuffer.java:779)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.receiveSOAPResponse(SOAPOverHTTPSender.java:991)
at com.ibm.ws.websvcs.transport.http.SOAPOverHTTPSender.send(SOAPOverHTTPSender.java:458)
at com.ibm.ws.websvcs.transport.http.HTTPTransportSender.invoke(HTTPTransportSender.java:320)
at org.apache.axis2.engine.AxisEngine.send(AxisEngine.java:446)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:401)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:228)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:163)
at org.apache.axis2.jaxws.core.controller.impl.AxisInvocationController.execute(AxisInvocationController.java:554)
... 6 more
 
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
For your original post:

 
Nischit Shetty
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

H Paul wrote:For your original post:



Thanks. But Sample1SoapBindingStub internallt extends javax.xml.rpc.Stub. So it doesnt make a difference.
Anyways I tried giving as you mentioned. It didnt work either. Any other solution?
 
H Paul
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. Code-wise: That's all there is on the CLIENT side




2. For your 2ND post, I'm curious why

Exception in thread "P=95493:O=0:CT" javax.xml.ws.WebServiceException: java.lang.StringIndexOutOfBoundsException

What relationship with username+password setting???

3. Either Client did not send to the Server Username+Password
OR the Server did not configure correctly to reconize the username+ password.

- Use SOAP ui to see if the Client indeed send to the server Username+Password

- Check the server setting again.
 
Ranch Hand
Posts: 2198
1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi!
I don't know the cause for your problems, but I would proceed as follows:
1. Using soapUI, I would issue a request from the client computer.
This is to learn what a working request looks like.
2. Using TCPmon, WireShark, Membrane or some other tool, examine the requests from the client.
3. Manipulate the client code until the requests look like the requests from soapUI.
Best wishes!
 
Nischit Shetty
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Ivan Krizsan wrote:Hi!
I don't know the cause for your problems, but I would proceed as follows:
1. Using soapUI, I would issue a request from the client computer.
This is to learn what a working request looks like.
2. Using TCPmon, WireShark, Membrane or some other tool, examine the requests from the client.
3. Manipulate the client code until the requests look like the requests from soapUI.
Best wishes!



Thanks.
I have tried many of these options.
Using SOAP UI, I tried placing the request. Also provided the auth information and submitted. But TAM rejects the request outright.
I then went back to my application and opened the axis log statements to DEBUG. Observered the outgoing SOAP request. It looks as follows.

Request Header
------------------
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.4
Host: {webservicehosturl}:{portnumber}
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: {webserviceNamespace}/{operationname}
Content-Length: 408
Authorization: Basic {encrypetedcredentials}

SOAP Message
-----------------
<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<objtyp xmlns="{namespace}">
<id xmlns="">XXXXXXXX</id>
<idCategory xmlns="">YYYYYYYY</idCategory>
</objtyp>
</soapenv:Body>
</soapenv:Envelope>

On reviewing the above, i can easily see that axis is sending basic authentication information which TAM is rejecting.

I then launched the SOA client on Firefox.
Cut pasted the header information in header section and soap information as request message. TAM again rejected the request.
In the same firefox browser, I opened a seperate tab, and I called the webservice endpoint url alone. TAM prompted for user id /password. I entered valid information, after which it showed the webservice is running. I then went back to the tab which conatins the SOA client. submitted the request again, this time it went through and got successful response.
This time the SOA client was able to place request because firefox had stored a authenticated cookie within itself. I then manually deleted that cookie.
Now I used the SOA client to resubmit the same request. It failed!!!
So overall I believe there is something basic I am missing here.
Do I have to perform a valid authentication and then place a webservice request? I am not sure why this TAM is rejecting my request, when authorization information is being sent in the request header.
Any help please.
 
H Paul
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
1. IF the server side is "configured correctly" for basic auth,

then if the client does not send the user/password
OR if the client does send the incorrect user/password

then the server will return to client send back 401 Error: Unauthorized.

Even if the server did not the return the AxisFault to the client,
the server must have logged the error some where in the server side log.

2. Have you looked into the server's log? to see what type of error/exception.

SystemOut
SystemErr
ffdc log folder
 
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is the problem with the authentication or is the problem with the web service or is the problem with the network communication?

I would make sure that the web service is working without the authentication part or the network part. Run a local client on the same node as the service. If this work, then try to call the web service from the remote node without authentication. If this works, then your problem is located in the authentication. If it doesn't work, then you have a problem with the web service.
 
Nischit Shetty
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

H Paul wrote:1. IF the server side is "configured correctly" for basic auth,

then if the client does not send the user/password
OR if the client does send the incorrect user/password

then the server will return to client send back 401 Error: Unauthorized.

Even if the server did not the return the AxisFault to the client,
the server must have logged the error some where in the server side log.

2. Have you looked into the server's log? to see what type of error/exception.

SystemOut
SystemErr
ffdc log folder



The authentication is being performed by the TAM authentication layer. The webservice provider as such do not perform any authentication. Whenever we make a call, the flow is something like Client call -> TAM authentication layer -> Web service provider/implementation.

There is no chance that the client is sending incorrect user id/password.
Today I found that Axis internally uses Httpsender to include the credentials into the request header.
I added the source code and tried debgugging to verify if AXIS is missing to send the credentials. I verified that it is clearly sending the credential information.
Since the authentication is performed by TAM, I have to request the team (supporting that layer) and let me know what could be the problem. Let me have a look.

But what puzzles me is, the following scenario -
- On firefox SOA client, you might have observed a small button "Use authentication". If I enter the credentials, it automatically adds a element to request header as "Authorization: Basic {encryptedcredentials}". Once I cut paste the SOAP a valid message, I get a TAM authentication failure error.
- If I open the webservice end point URL on a seperate tab of firefox, it prompts for user id/password. On entering the credentials, I get a page saying the web service is up and running.
If I then open the SOA client on firefox, it is able to get successful response from the webservice.
- If I go back to SOA client, and now invoke the same web service with the same SOAP message, I am getting the correct response.
- If I manually remove the authenticated cookie and then place the request from SOA client, it fails again.

This means the request header element "Authorization: Basic {encryptedcredentials}" added by SOA client is basically serving no purpose. Only when my request is associated with a valid authenticated cookie, the TAM layer allows to pass through (I am not sure if my assumption is correct or not).
In the same sense, even AXIS sends the request header element "Authorization: Basic {encryptedcredentials}". If I take into consideration the above scenario, I think TAM is rejecting the request, because of no authenticated cookie associated with it, then I dont think my current logic will go through.

Later I tried writing a servlet which can successfully perform TAM authentication. My objective was to check if I am get successful TAM authentcation, would it possible for me to include the cookie in my webservice request. The code looked as follows

HttpClient client = new HttpClient();
List<String> authPrefs = new ArrayList<String>(1);
authPrefs.add(AuthPolicy.BASIC);
// This will exclude the NTLM authentication scheme
client.getParams().setParameter(AuthPolicy.AUTH_SCHEME_PRIORITY, authPrefs);

// pass our credentials to HttpClient, they will only be used for
// authenticating to servers with realm "realm" on the host
// "www.verisign.com", to authenticate against an arbitrary realm
// or host change the appropriate argument to null.
client.getState().setCredentials(
new AuthScope(webserviceendpointurl, "realm"),
new UsernamePasswordCredentials(domain + "\\" + username, password)
);

// create a GET method that reads a file over HTTPS,
// we're assuming that this file requires basic
// authentication using the realm above.
GetMethod get = new GetMethod(
webserviceendpointurl);

// Tell the GET method to automatically handle authentication. The
// method will use any appropriate credentials to handle basic
// authentication requests. Setting this value to false will cause
// any request for authentication to return with a status of 401.
// It will then be up to the client to handle the authentication.
get.setDoAuthentication( true );

try {
// execute the GET
int status = client.executeMethod( get );

// print the status and response
System.out.println(status + "\n" +
get.getResponseBodyAsString());

} finally {
// release any connection resources used by the method
get.releaseConnection();
}


The above servlet failed to authenticate with TAM. I am not sure what else I am missing here?
Any other suggestion are welcome. Is the above code valid for TAM authentication? Is there a alternative approach?
 
Nischit Shetty
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Jimmy Clark wrote:Is the problem with the authentication or is the problem with the web service or is the problem with the network communication?

I would make sure that the web service is working without the authentication part or the network part. Run a local client on the same node as the service. If this work, then try to call the web service from the remote node without authentication. If this works, then your problem is located in the authentication. If it doesn't work, then you have a problem with the web service.



Thanks H Paul and Jimmy for your response.
The webservice that I am invoking is being used by the same application which provides the webservice. Since the same application which provides the webservice is invoking it, it is not coming under TAM authentication layer (may be they are having some bypass mechanism). Since my application is external to this application (though within the same intranet), I have to go through TAM authentication layer.

Net communication is also ruled out.

Now with respect to your first question "Is the problem with the authentication", I am confused how to respond. I am sure the credentials, I am supplying is clean and it is being passed in request header. Now the question is whether TAM is reading the request header and authenticating my request? If not, then obviously TAM would reject all my requests.
I am going to verify with the team who is handling TAM authentication layer. But in between do you know of any better approach of getting authenticated with TAM?
 
H Paul
Ranch Hand
Posts: 491
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

0. Please have a look at

http://www.ibm.com/developerworks/tivoli/library/t-ssl/

Taken from the link: "This article will assist integrators and developers programming Web Services using Apache AXIS
that want to add authentication and authorization using Tivoli Access Manager.
In this article, you will reuse an existing sample SOAP/HTTP web service provided by the IBM WebSphere SDK for Web Services,
and then you will configure Tivoli Access Manager WebSEAL to make authentication and authorization on your web service.
Finally you will see how to develop a sample client passing the right parameters to access your secure web service."

It used Https (SSL) + Basic Auth as your use case.

1. The funny part (or a concidence) is that the sample code you used in the original post 1st is identical to the code used in this sample.



// The username and password used here need to be registered in WebSEAL.
But what is WebSEAL etc... Please have a look at http://www.ibm.com/developerworks/tivoli/library/t-ssl/

 
Jimmy Clark
Ranch Hand
Posts: 2187
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Since my application is external to this application (though within the same intranet), I have to go through TAM authentication layer.

Net communication is also ruled out.



If your application is communicating with a web service located on another machine, there is indeed network communication. And this should be involved in your problem-solving.


Now with respect to your first question "Is the problem with the authentication", I am confused how to respond. I am sure the credentials, I am supplying is clean and it is being passed in request header. Now the question is whether TAM is reading the request header and authenticating my request? If not, then obviously TAM would reject all my requests.

I am going to verify with the team who is handling TAM authentication layer. But in between do you know of any better approach of getting authenticated with TAM?



Sounds good. You need to verify that the TAM is correctly processing your credentials and shouldn't assume anything. If you know for a fact that the TAM implementation is working, then you can dismiss it as a cause of your problem. Until then, it is still a possible cause. Is there a way to test the TAM without calling a web service? Whoever is responsible for the TAM implementation surely has provided this service for developers.
 
Nischit Shetty
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi All - We were able to fix the issue. The issue turned out be a problem with TAM layer itself. It was configured incorrectly because of which it was only allowing browser based requests to pass through. We then switched to a different environment where TAM was better configured and it worked.

Just FYI, the following piece of AXIS code satisfies BASIC authentication for TAM -

 
Ranch Hand
Posts: 126
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Nischit Shetty wrote:Hi All - We were able to fix the issue. The issue turned out be a problem with TAM layer itself. It was configured incorrectly because of which it was only allowing browser based requests to pass through. We then switched to a different environment where TAM was better configured and it worked.

Just FYI, the following piece of AXIS code satisfies BASIC authentication for TAM -



Hello Nischit - Can you please tell me , what was changed on the TAM side ? Was the TAM configured in form based authentication mode and then it was changed to to Basic Authentication (BA) mode or http mode?

I am facing the same exact issue and not sure how to address it.
 
Ranch Hand
Posts: 296
Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

swapnil paranjape wrote:Basic Authentication (BA) mode or http mode?


What do you mean by 'http mode'? Basic authentication goes in 'http mode'.
 
Do not set lab on fire. Or this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic