GeeCON Prague 2014*
The moose likes Web Services and the fly likes CXF, WSDL, and SecurityPolicy problems with Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Java » Web Services
Bookmark "CXF, WSDL, and SecurityPolicy problems with "None of the policy alternatives can be satisfied."" Watch "CXF, WSDL, and SecurityPolicy problems with "None of the policy alternatives can be satisfied."" New topic
Author

CXF, WSDL, and SecurityPolicy problems with "None of the policy alternatives can be satisfied."

Tom Z. Smith
Greenhorn

Joined: Aug 17, 2011
Posts: 6
I'm trying to implement a web service using Eclipse Indigo and CXF 2.x with Java 1.6 and I keep bombing out when I try to run and test the client locally through Eclipse. In the console, I keep getting an error message about "None of the policy alternatives can be satisfied" and so far there has been absolutely nobody capable of both understanding this situation and or fixing it. I'm not even completely sure where it's coming from...

It seems the basic approach to creating a TOP-DOWN web service in Eclipse is as follows:

1.) Create a Dynamic Web Project.
2.) Import your WSDL file.
3.) Create a Web Service.
4.) Create a Client Web Service.

Basic, right? Well, it doesn't seem to properly work this way if you intend on using security features (which, duh, we all want, right?). That said, the addition of security means that one needs to use the following element inside a WSDL:



Unless I'm mistaken, this should basically imply that some form of authentication between the two consuming parties will be used, but is this even right?

We've been trying to get this implemented for the past 2 months and no matter what we tweak, change, edit, or update, it just doesn't work or seem to do a single thing and we've suspected that it has something to do with how the WSDL has been made (we've received it from a client)...

Our entire WSDL is as follows:



We've had quite the time getting this implemented due to a plethora of reasons. At first, we tried the antiquated version of AXIS and with this, we got it to work but without any kind of security. As soon as we put the security inside the WSDL, it bombed. We then tried AXIS2, but that couldn't get anything generated in the form of a stub. Finally, we tried CXF and in my opinion, this seems to get us further than both but some tiny issue is preventing us from finishing the routine and I'm thinking it's a tiny bottleneck somewhere--just don't know where it's coming from. I'm worried it has something to do with the WSDL, but who knows?

XML is definitely a foreign technology when it comes to WSDL stuff. I've learned a lot, for sure, but truly need help getting all this working. If anyone could shine some light, it would be appreciated.
Ivan Krizsan
Ranch Hand

Joined: Oct 04, 2006
Posts: 2198
    
    1
Hi!
Assuming you are familiar with the purposes of WS-Policy and WS-Security, the WSDL you have obtained specify a policy that says that a UserNameToken, with an optional password, must be used when invoking the checkMember operation.
Such a token is to be placed in a header in SOAP requests. Such a header may look something like this:

The UserNameToken type is specified by this XML schema: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd
The specification document of the WS-Security UsernameToken profile can be found here: http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0.pdf
Best wishes!


My free books and tutorials: http://www.slideshare.net/krizsan
 
GeeCON Prague 2014
 
subject: CXF, WSDL, and SecurityPolicy problems with "None of the policy alternatives can be satisfied."