What is the correct way to authenticate an Axis2 (Version 1.4) Client at a http proxy server that requires NTLM authentication?
I'm using the following code to provide the proxy credentials, but the authentication still fails (see details at the end):
Options options = serviceStub._getServiceClient().getOptions();
options.setProperty(HTTPConstants.CHUNKED, false);
options.setProperty(HTTPConstants.PROTOCOL_VERSION, HTTPConstants.HEADER_PROTOCOL_10);
ProxyProperties proxyProperties = new ProxyProperties();
proxyProperties.setProxyName("123.123.123.123");
proxyProperties.setProxyPort(8080);
proxyProperties.setUserName("myUser#www.example.org");
proxyProperties.setPassWord("1234");
proxyProperties.setDomain("");
options.setProperty(HTTPConstants.PROXY, proxyProperties);
With exactly the same credentials, a webbrowser, such as Firefox is able to get trough the proxy, so I assume, the proxy server is correctly set up. With the Axis2 client however, the authentication failes (HTTP status code is "407 Proxy Authentication Required").
Further details:
I compared the network traffic from firefox and my client using a network sniffer. The main difference seems to be, that the axis2 client is sending an empty response for the ntlm challenge.
Has anyone successfully authenticated at a http proxy server using NTLM? Can you give me a code example?
I was unable to resolve this problem (with Axis 2). Don't want to blame this on Axis2 tough. Maybe I did something wrong but couldn't figure it out, even after many hours of trying, debugging and reading the docs.
But when I was running out of options I had to look out for other options. This other option came in the form of alternative SOAP-Frameworks. There exist quite a few SOAP frameworks for java. I know about Axis2, CXF and JAX-WS.
Instead of Axis2 I use now JAX-WS. Replacing the frameworks was a straight forward process. A nice side effect of the replacement was, that I got rid of the huge dependency tree, Axis2 comes with. JAX-WS is part of J6EE so there wasn't any need to import other dependencies.
At this time I did the replacement only on the client side. The server still uses Axis2. This combination works great so far, but I still plan to eventually replace Axis2 on the server side too.
All in all: If you do not use a special feature of Axis2, I think, JAX-WS is the better option.
Related
I am working on integrating a SOAP service provided by european VAT validation service VIES.
the SOAP service is hosted at following links
https://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl
http://ec.europa.eu/taxation_customs/vies/checkVatService.wsdl
I think both of them leads to pretty much same site with one being http and other https
(please let me know if there is a difference).
so I integrated the wsdl into our spring boot application and it worked fine when I tried in in my local host which was http. but as soon as I hosted it in to our live server which is https it started giving error reply.
I searched for possible reasons why it isn't working and ended up with the conclusion that the SOAP services provided by VTES works only in http sites.(let me know if I am wrong)
but when I searched for more solutions I found more sites that provide https secured REST application that uses same SOAP service (https://vatlayer.com/) . We tried to reason with our client to purchase one of those since they only allow a limited number of free VAT validations, but they are not happy with that,
but it got me thinking since they can built a https secured REST API with this thing it means I can do that to. so I searched for a solution but couldn't find any, can anyone please give a insight into it about how it is done.
Thanks and regards.
If you are calling the link from the web browser(client side) and if your live web application runs on HTTPS, then you should also call the SOAP service with HTTPS or otherwise the browser will see it as violating the Same Origin Policy and will block your request.
I'm implementing a Client Web Service and I need to convert code from Apache Axis2 with Apache CXF.
Below is the code in Apache Axis2 which needs to be converted to CXF way of authentication:
_service = "http://mysite.custhelp.com/cgi-bin/myinterface.cfg/services/soap";
org.apache.axis2.client.ServiceClient serviceClient = ((org.apache.axis2.client.Stub)_service)._getServiceClient();
serviceClient.addHeader(createSecurityHeader("Username", "Password"));
Where createSecurityHeader will create be responsible for authenticating and providing a response in form of securityHeader.
Any help will be appreciated.
Thanks,
Jineet
I know it's probably too late to be able to help you, Jineet, but answering this question for the benefit of others who might have struggled like you and me trying to migrate from Axis to CXF.
You need to do both the steps described as the top 2 solutions of this stackoverflow question: Java Web Service client basic authentication
As per my understanding and experience, the first approach (BindingProvider) is required for authentication at SOAP protocol level to work. The second one (Authenticator) is required for authorization to access the SOAP service endpoint URL (HTTP/s level).
After making both these changes, my migration was successful.
I'm trying to use HTTPS in Java EE, for my own login directives and transfering information via a secure protocol. This should be trivial, but I'm having trouble finding a tutorial/guide to do it.
Currently, I'm using Netbeans for all my J2EE work, which uses Glassfish 4.1.1, along with JDK and JRE at the 1.8 version.
I'm basically looking for a comprehensive guide or a quick resume on how to implement HTTPS on a Servlet, so when I access to that servlet (mydomain/#/myServlet) the protocol gets set to HTTPS, uses my own created certificate (I also need help with that), so it encrypts the GET/POST requests, in order to make it unable to read the info (or at least make it a non-trivial thing).
Knowing a list of TO-DO things could be enough; if I know what I have to do, I can look for the information in a proper way. But now, I really don't find anything easy to understand.
Anyone can help? Thank you!
Your server will have a port for HTTP communication and other for HTTPS communication. So if you will communicate on HTTPS port the communication will be on HTTPS. So see your server configuration and check the HTTPS port and use that port in the URL.
I am trying to set up an STS test scenario with an STS service, a webservices and a client. The Secure Token Service is from the Identity Server of WSO2 and runs at endpoint
https://[domain]:9443/services/wso2carbon-sts/
the webservice and client are written in java with Netbeans. I run the client and get:
WST0017:Could not obtain STS metadata. MEX call to STS https://[domain]:9443/services/wso2carbon-sts/mex failed.
What is the endpoint of the MEX service of the Secure Token Service in WSO2?
MEX is a protocol that is supposed to help automatically identify the details of the web-service being called. These non-obvious errors tend to happen when the calling library needs the WSDL but is provided with the URL to the endpoint instead. As a result it tries to use MEX to find the WSDL, but since the server does not implement MEX this fails and returns these non-obvious errors.
In practice the fix is almost always to provide the URL to the WSDL (which contains the details of the end point URL) rather than directly to the endpoint. I don't know enough about WSO2, but commonly the WSDL is exposed by appending ?wsdl or similar to the end point URL.
I spent many days and nights trying to find a proper Java framework that could connect to Microsoft Dynamics CRM which uses Negotiate/NTLM authentication. I tried all existing suggestions on Stackoverflow and other resources with JAX-WS, Axis2, CXF with various HTTP protocol handlers. No one of them worked as expected. The best approach currently is Axis2/commons-httpclient-3.1, where I can trace at least all three phases with NTLM digest, however the target IIS still refuses the authentication with 401 Unauthorized. Apache CXF — both with a built-in Java6 NTLM support and jCIFS, which some people suggested as a remedy, didn't work either as the former fails on the second 401 response (while it should have been send the third request, according to the protocol) and the latter one attempts to read the response code from an empty input stream and fails.
So, the question is whether anybody has succeeded to master an NTLM-protected SOAP web service from the Java 6 platform?
I was hoping somebody else would chime in, as my knowledge of this area is several years old now and perhaps not the best advice - in particular, I've only worked with commons-httpclient 3 and none of the newer packages that promise to do NTLM/NTLMv2 correctly.
As you've probably noticed, commons-httpclient 3's NTLM authentication code supports only NTLM, not the newer NTLMv2 protocol. My solution to this problem was to use commons-httpclient 3 and replace the NTLM authentication code with an NTLMv2 capable solution. Fortunately, the NTLMv2 specification is published by Microsoft. It's honestly not terrible difficult to implement but of course it's now something you have to maintain yourself which may not be desirable for a number of reasons.
I forgot so say that I did find a solution myself. The clue is to replace the standard Java protocol stack with Jespa+jCIFS and make some minor patch to work it with JAX-WS.