• 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 ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
  • Piet Souris
  • Himai Minh

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

Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
Ranch Hand
Posts: 2198
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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!
Screaming fools! It's nothing more than a tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
    Bookmark Topic Watch Topic
  • New Topic