Skip to main content

Accessing .Net Web Service with security with NetBeans 6.9.1 and Metro 2.0

4 replies [Last post]
swpalmer
Offline
Joined: 2003-06-10

I'm trying to integrate some things with our local install of TargetProcess (see target.process.com) which provides Web Services, apparently done with .Net .

I'm using NetBeans 6.9.1 an Metro 2.0.

I thought it would be a simple matter of importing the WSDL and calling the service using the generated classes... but it fails. I believe the issue is security-related ( the error messages are not much help).

SEVERE: SAAJ0435: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security is not a standard Code value
Exception in thread "main" javax.xml.ws.WebServiceException: com.sun.xml.messaging.saaj.SOAPExceptionImpl: {http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Security is not a standard Code value

using the non 1.2 implementation of the service interface just yields:
Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: Security requirements are not satisfied because the security header is not present in the incoming message.

I think I just need to fill things in with a username and password somewhere, but I can't find where to put that. When I consumed my own web services (with a Java server) I saw the security section in the NetBeans config and I could specify a class to handle the callbacks for username and password. With this service all that is missing.

NB 6.9.1 when I select "Edit Web Service Attributes" on the quality of service tab there is no reference to anything security related - I can't enter any sort of credentials anywhere.

How do I get the username info into the request? I suppose I have to edit some XML by hand.. though I'm worried that if I refresh the web service definition I might lose something if I do that.
Any help is appreciated.

FYI.. The examples provided by TargetProcess use XFire, but I would rather not pull in another library for this.
http://www.targetprocess.com/support/Web_services_api/Web_services_java....
http://www.targetprocess.com/support/Web_services_api.aspx

Thanks

Scott

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
swpalmer
Offline
Joined: 2003-06-10

Hmm.. are the two people in the world that actually know this stuff on vacation, or did they simply leave Sun after the Oracle takeover :-) ?

Glen Mazza

In the security section of my blog articles
(http://www.jroller.com/gmazza/entry/blog_article_index), articles #3
(especially) and #5 might be of help for you.

Glen

metro-3 wrote:
>
> Hmm.. are the two people in the world that actually know this stuff on
> vacation, or did they simply leave Sun after the Oracle takeover :-) ?
>

--
View this message in context: http://metro.1045641.n5.nabble.com/Accessing-Net-Web-Service-with-securi...
Sent from the Metro - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net

swpalmer
Offline
Joined: 2003-06-10

Thank you very much for trying to help...

I've been reading the blog posts you mention - however they all seem to require me to change things on the server side and the client side. I have no access to the server side and, as stated above, when I "Edit Web Service Attributes" there is NO security section under Quality Of Service. It seems there should be, as the error response from the server indicates that the security header is missing from the request. But I have no way of getting NetBeans to generate the proper headers.

The WSDL provided by the server does not have a Policy section like your examples. I think that is causing the generated client-side wsdl to contain the wrong information in it's Policy section.

But, I think, this should have all been worked out when the URL to the server's WSDL was used to generate the Java web client.

So I modified the client-side xml (wsdl) by hand to set up username/password callbackhandler in the policy.. but it is never called and I still get the message that the security header is missing.

On a whim I added KeyStore and TrustStore sections to the policy on the client-side by editing the xml directly as well, but still no security headers...

The documentation on TargetProcess.com state:
"TargetProcess web services claim to conform to the WSI Basic Profile version 1.1. TargetProcess web services use WS-Security specification for authenticating the client using a UsernameToken security token."

I would have thought that was simple enough that NetBeans would have imported the WSDL and done the right thing. But something clearly isn't right from metro's point of view if it isn't even trying to put a security header on the requests.

Scott

Glen Mazza

You don't have to change the server side, you can discard what it is telling
you there. But you may need to create a web service stub using the
service's WSDL so you can subsequently create the client with the policy
statements that you need.

Also make sure you're using Metro and not just the JAX-WS RI--I believe
policy statements are ignored with the latter.

Dennis Sosnoski's article might also help you:
http://www.ibm.com/developerworks/java/library/j-jws10.html

Glen

metro-3 wrote:
>
> Thank you very much for trying to help...
>
> I've been reading the blog posts you mention - however they all seem to
> requirte me to change things on the server side and the client side. I
> have no access to the server side and, as stated above, when I "Edit Web
> Service Attributes" there is NO security section under Quality Of Service.
> It seems there should be, as the error response from the server indicates
> that the security header is missing from the request. But I have no way
> of getting NetBeans to generate the proper headers.
>
> The WSDL provided by the server does not have a Policy section like your
> examples. I think that is causing the generated client-side wsdl to
> contain the wrong information in it's Policy section.
>
> But, I think, this should have all been worked out when the URL to the
> server's WSDL was used to generate the Java web client.
>
> So I modified the client-side xml (wsdl) by hand to set up
> username/password callbackhandler in the policy.. but it is never called
> and I still get the message that the security header is missing.
>
> On a whim I added KeyStore and TrustStore sections to the policy on the
> client-side by editing the xml directly as well, but still no security
> headers...
>
> The documentation on TargetProcess.com state:
> "TargetProcess web services claim to conform to the WSI Basic Profile
> version 1.1. TargetProcess web services use WS-Security specification for
> authenticating the client using a UsernameToken security token."
>
> I would have thought that was simple enough that NetBeans would have
> imported the WSDL and done the right thing. But something clearly isn't
> right from metro's point of view if it isn't even trying to put a security
> header on the requests.
>
> Scott
>

--
View this message in context: http://metro.1045641.n5.nabble.com/Accessing-Net-Web-Service-with-securi...
Sent from the Metro - Users mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@metro.dev.java.net
For additional commands, e-mail: users-help@metro.dev.java.net