Jonathan Barbero
Jonathan Barbero

Reputation: 2554

JAX-WS IBM client consuming .Net WS with Active Directory authentication (NTLM)

I want to consume .Net WS from IBM WebSphere.

I created a WS-client with JAX-WS IBM implementation that consumes a .Net WS on IIS. The client is on SUSE and the authentication is by NTLM with Windows Server 2003 Active Directory.

If I use other implemetation of JAX-WS than IBM I loose the console administration and the automatic annotation reading, plus to loose support from IBM.

Questions

I don´t get why inside of RAD it didn´t work, is the same program that works from command line.

How do you make JAX-WS IBM implementation authenticate with NTLMv2 protocol support with specific credentials? (java.net.Authenticator provides you with this, and it should be called ... it does not)

Is the any way to make IBM JAX-WS implemetation to use another HTTP client than the standard one?

Even the IBM JVM implementation provides NTLM auth (this is the reason why the command line and the direct HttpConnection executions works) so I don´t get why they don´t use it for the IBM WS stack.

Plus points

Is there any good way to provide bidirectional ability to consume WS with the ActiveDirectory authentication?

Comment

Spring WS uses HttpClient 4.X that supports NTLMv2 auth, but I need a JAX-WS implementation and it should be the IBM one. The IBM JAX-WS only seems to support Basic AUTH. I don´t get how the Microsoft WS interop is not important for IBM.

References

Authenticator conf:

http://docs.oracle.com/javase/6/docs/api/java/net/Authenticator.html#setDefault%28java.net.Authenticator%29

https://stackoverflow.com/a/5994706/14811

Thanks in advance!

Upvotes: 5

Views: 3218

Answers (2)

Jonathan Barbero
Jonathan Barbero

Reputation: 2554

Finally, this is what I did.

I create the JAXB objects with the RAD plugin to create a JAX-WS client. I use the generated DTOs as the messages that I pass to the Spring WS library. Spring WS 2.1 comes with Http Client 4.2 that brings NTLMv2 support.

I created an small library to make this process easier, but the procedure idea is:

  1. Generate the JAX-WS client with RAD
  2. Create a class that implements the service interface generated by RAD
  3. For each interface method:
  4. 3.1 Inject the interface method's parameters to the JAXB object
  5. 3.2 Pass this object to the WebServiceTemplate (Spring object) web service call.
  6. 3.3 Cast the call response to the JAXB method response object
  7. 3.4 Return the inner value of the response object

So, what you finally do is reuse the object generation for a JAX-WS client to wrap the service method's parameters into the object that Spring WS needs to make the call.

For NTLM authentication set NTCredentials to the WebServiceTemplate sender.

Axis2 1.7 will have support for NTLMv2 with updated version of the HttpClient 4.2.X, but there is no release date yet.

See:

  • WebServiceTemplate WS call

http://static.springsource.org/spring-ws/sites/2.0/apidocs/org/springframework/ws/client/core/WebServiceTemplate.html#marshalSendAndReceive%28java.lang.Object%29

  • WebServiceTemplate sender

http://static.springsource.org/spring-ws/sites/2.0/apidocs/org/springframework/ws/client/support/WebServiceAccessor.html#getMessageSenders%28%29

  • NTCredentials

http://hc.apache.org/httpcomponents-client-ga/httpclient/apidocs/org/apache/http/auth/NTCredentials.html


Update: I tested Axis 1.7 and the NTLM auth works well.

Upvotes: 2

Martin Lansche
Martin Lansche

Reputation: 29

You are moving from NTLM (1994?) to NTLMv2 (1999) instead of Kerberos based technology (introduced in Windows 2000) because NTLMv2 is more secure???

In terms of interop with Microsoft, modern systems would use WS-Security Kerberos between the JAX-WS client and the .NET service. This has been tested.

What you are trying to do (replace the Authenticator used by the process) is applicable to a standalone Java application, but does not fit into the Java Enterprise model where the Java process hosts multiple "applications" each with their own "authentication" requirements, never mind the internal requirements imposed by the WebSphere Server processes talking to each other (App Server to App Server, Node Agent to App Server, App Server to LDAP, etc.....)

Upvotes: 2

Related Questions