Debugging "None of the policy alternatives can be satisfied" WS-SecPol error

[Glen Mazza]

Hello, I'm trying to create a CXF client accessing a Metro web service that requires (via WS-SecurityPolicy statements) Username/Password Tokens--this[1] web service, in particular.  Configuring the SOAP client with this cxf.xml:

<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jaxws="http://cxf.apache.org/jaxws"
    xsi:schemaLocation="http://www.springframework.org/schema/beans 
    http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
    http://cxf.apache.org/jaxws 
    http://cxf.apache.org/schemas/jaxws.xsd">

<jaxws:client name="{http://www.example.org/contract/DoubleIt}DoubleItService" createdFromAPI="true">
    <jaxws:properties>
        <entry key="ws-security.username" value="alice"/>
        <entry key="ws-security.password" value="clarinet"/>        
    </jaxws:properties>
</jaxws:client>
</beans>

Is returning this error:
[INFO] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException: None of the policy alternatives can be satisfied.
[INFO] at org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
[INFO] at $Proxy38.doubleIt(Unknown Source)
[INFO] at com.mycompany.webservice.client.WSClient.doubleIt(WSClient.java:18)
[INFO] at com.mycompany.webservice.client.WSClient.main(WSClient.java:11)

Can anyone can see what the problem might be?  If not, prior to tracing into the CXF source code, is there any other troubleshooting I can or should do in order to determine the problem?

Thanks,
Glen

[1] http://www.jroller.com/gmazza/entry/implementing_ws_security_using_usernametokens#MetroUT2-4

[dkulp]

Hate to ask the obvious, but did you yank out the Metro specific policies from
the wsdl?  Example: the ValidatorConfiguration policy and CallbackHandler and
such?

Not sure if upping logging levels will help.   I've started going through and
tried to make it output better error messages that provide more details when
policies cannot be met, but apparently this error message got through.    It
definitely needs some work to make sure it will track what policies could not
be satisfied to make the error message a bit better.

Dan


On Tue July 7 2009 11:38:41 pm Glen Mazza wrote:

> Hello, I'm trying to create a CXF client accessing a Metro web service that
> requires (via WS-SecurityPolicy statements) Username/Password
> Tokens--this[1] web service, in particular.  Configuring the SOAP client
> with this cxf.xml:
>
> <beans xmlns="http://www.springframework.org/schema/beans"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xmlns:jaxws="http://cxf.apache.org/jaxws"
>     xsi:schemaLocation="http://www.springframework.org/schema/beans
>     http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
>     http://cxf.apache.org/jaxws
>     http://cxf.apache.org/schemas/jaxws.xsd">
>
> <jaxws:client
> name="{http://www.example.org/contract/DoubleIt}DoubleItService"
> createdFromAPI="true">
>     <jaxws:properties>
>         <entry key="ws-security.username" value="alice"/>
>         <entry key="ws-security.password" value="clarinet"/>
>     </jaxws:properties>
> </jaxws:client>
> </beans>
>
> Is returning this error:
> [INFO] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException:
> None of the policy alternatives can be satisfied.
> [INFO] at
> org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
> [INFO] at $Proxy38.doubleIt(Unknown Source)
> [INFO] at
> com.mycompany.webservice.client.WSClient.doubleIt(WSClient.java:18)
> [INFO] at com.mycompany.webservice.client.WSClient.main(WSClient.java:11)
>
> Can anyone can see what the problem might be?  If not, prior to tracing
> into the CXF source code, is there any other troubleshooting I can or
> should do in order to determine the problem?
>
> Thanks,
> Glen
>
> [1]
> http://www.jroller.com/gmazza/entry/implementing_ws_security_using_username
>tokens#MetroUT2-4

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

[Glen Mazza]

No, actually I intentionally did not yank those, because they're in a different namespace that presumably CXF should ignore, right?  I come from the Apache FOP environment where formatting commands of an unknown namespace are just ignored--they are assumed to be specialized proprietary commands for other competitor processors to FOP.  (OTOH, perhaps it should fail with an error or give a warning if it can't process a particular namespace...that might help save some people who misspell a WS-SecPol or other official namespace and hence have their Policy elements skipped by CXF without realizing it.)

But to test, I did just yank the ValidatorConfiguration from the local WSDL file that the SOAP client reads via the DoubleItService.java class and got the same error message.  (The Callback handler you see for the client-side config in the Metro example was never present in the CXF client code--it just has access to the service WSDL.)  mvn exec:exec with the -X option and using a logging.properties file didn't provide any more useful information.

I'll start debugging without the Metro-specific elements to see if I can find anything else.

Thanks,
Glen

dkulp wrote:

Hate to ask the obvious, but did you yank out the Metro specific policies from
the wsdl?  Example: the ValidatorConfiguration policy and CallbackHandler and
such?

Not sure if upping logging levels will help.   I've started going through and
tried to make it output better error messages that provide more details when
policies cannot be met, but apparently this error message got through.    It
definitely needs some work to make sure it will track what policies could not
be satisfied to make the error message a bit better.

Dan

[dkulp]

On Wed July 8 2009 12:39:08 am Glen Mazza wrote:
> No, actually I intentionally did not yank those, because they're in a
> different namespace that presumably CXF should ignore, right?

Not inside a policy, no.   (this is one reason why mixing policy and
configuration is such a bad idea)

If you have a policy like:

<wsp:All>
    ....
</wsp:All>

Then per the policy spec, ALL of the policy elements (that aren't
wsp:Optional=true) must be applied.   The policy spec doesn't say what the
namespaces and such of the individual policy assertion that would go into the
All are.   Other specs (and company proprietary things) dictate those.    

For example, a policy like:

<wsp:All>
    <wsaw:UsingAddressing/>
</wsp:All>

If the addressing module isn't loaded, then there wouldn't be anything
registered to handle the UsingAddressing assertion.   Should we just ignore it
and send the message out without addressing which would be against the
contract or should we fail with a "cannot implement the policy" type of
exception?

Anyway, if you want to leave them in, you should just need to add
wsp:Optional="true"  to make them optional.   Otherwise, you would need to
register stuff with the CXF Policy engine to support the Sun policy assertion
names.  

In anycase, if you have a simple test case, feel free to add it to a JIRA.  At
the very least, we should be able to make that error message a bit better to
at least specify which policy assertion is the issue.

Dan

> I come from
> the Apache FOP environment where formatting commands of an unknown
> namespace are just ignored--they are assumed to be specialized proprietary
> commands for other competitor processors to FOP.  (OTOH, perhaps it should
> fail with an error or give a warning if it can't process a particular
> namespace...that might help save some people who misspell a WS-SecPol or
> other official namespace and hence have their Policy elements skipped by
> CXF without realizing it.)
>
> But to test, I did just yank the ValidatorConfiguration from the local WSDL
> file that the SOAP client reads via the DoubleItService.java class and got
> the same error message.  (The Callback handler you see for the client-side
> config in the Metro example was never present in the CXF client code--it
> just has access to the service WSDL.)  mvn exec:exec with the -X option and
> using a logging.properties file didn't provide any more useful information.
>
> I'll start debugging without the Metro-specific elements to see if I can
> find anything else.
>
> Thanks,
> Glen
>
> dkulp wrote:
> > Hate to ask the obvious, but did you yank out the Metro specific policies
> > from
> > the wsdl?  Example: the ValidatorConfiguration policy and CallbackHandler
> > and
> > such?
> >
> > Not sure if upping logging levels will help.   I've started going through
> > and
> > tried to make it output better error messages that provide more details
> > when
> > policies cannot be met, but apparently this error message got through.
> > It
> > definitely needs some work to make sure it will track what policies could
> > not
> > be satisfied to make the error message a bit better.
> >
> > Dan

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog

[Glen Mazza]

dkulp wrote:

Then per the policy spec, ALL of the policy elements (that aren't
wsp:Optional=true) must be applied.   The policy spec doesn't say what the
namespaces and such of the individual policy assertion that would go into the
All are.   Other specs (and company proprietary things) dictate those.

OK, I see--policy elements that are of a namespace that the processor does not understand are *not* to be ignored, but an error given instead, unless wsp:Optional=true is set.

I'll plug away a little bit more at this, and if I can't get it working will supply a JIRA with a test case.

Thanks,
Glen

[Sergey Beryozkin-2]

Hi


> On Wed July 8 2009 12:39:08 am Glen Mazza wrote:
>> No, actually I intentionally did not yank those, because they're in a
>> different namespace that presumably CXF should ignore, right?

Policy directives can only be ignored by a client runtime, when it chooses between multiple alternatives or when a given policy
assertion is marked as optional. Ex :
<Policy>
  <ExactlyOnce>
       <!-- Alt 1 -->
      <All><A/><B/></All>
       <!-- Alt 2 -->
      <All><A/><B/><C/><D optional="true"/></All>
  </ExactlyOnce>
</Policy>

One client can choose alternative 1 (it has to understand A & B), another one can choose alt2 amd it may not understand D. Yet
another client can choose alt2 and do exercise D. Note that Alt2 can be repleced with Alt21 && Alt22 :

<Policy>
  <ExactlyOnce>
       <!-- Alt 1 -->
      <All><A/><B/></All>
       <!-- Alt 21 -->
      <All><A/><B/><C/></All>
      <!-- Alt 22 -->
      <All><A/><B/><C/><D/></All>
  </ExactlyOnce>
</Policy>

As far as the service provider is concerned it really must to support A, B, C, D given that one of those clients will expect D be
supported, the one which chose Alt 22. Perhaps a service provider might choose to lazily initialize optional assertions but it has
to be able to meet the  policy declaration in its contract

>
> Not inside a policy, no.   (this is one reason why mixing policy and
> configuration is such a bad idea)

Agreed. If configuration does get injected inside a server policy instance then it would need to be removed at the publication time
(when we support java-first policies). For ex, an atribute like "private" can be used to mark such provate fragments.

>
> If you have a policy like:
>
> <wsp:All>
>    ....
> </wsp:All>
>
> Then per the policy spec, ALL of the policy elements (that aren't
> wsp:Optional=true) must be applied.   The policy spec doesn't say what the
> namespaces and such of the individual policy assertion that would go into the
> All are.   Other specs (and company proprietary things) dictate those.
>
> For example, a policy like:
>
> <wsp:All>
>    <wsaw:UsingAddressing/>
> </wsp:All>
>
> If the addressing module isn't loaded, then there wouldn't be anything
> registered to handle the UsingAddressing assertion.   Should we just ignore it
> and send the message out without addressing which would be against the
> contract or should we fail with a "cannot implement the policy" type of
> exception?

+1 for exception. Perhaps if it's an optional assertion then the exception can be thrown later on if this assertion is requested

cheers, Sergey

>
> Anyway, if you want to leave them in, you should just need to add
> wsp:Optional="true"  to make them optional.   Otherwise, you would need to
> register stuff with the CXF Policy engine to support the Sun policy assertion
> names.
>
> In anycase, if you have a simple test case, feel free to add it to a JIRA.  At
> the very least, we should be able to make that error message a bit better to
> at least specify which policy assertion is the issue.
>
> Dan
>
>
>
>> I come from
>> the Apache FOP environment where formatting commands of an unknown
>> namespace are just ignored--they are assumed to be specialized proprietary
>> commands for other competitor processors to FOP.  (OTOH, perhaps it should
>> fail with an error or give a warning if it can't process a particular
>> namespace...that might help save some people who misspell a WS-SecPol or
>> other official namespace and hence have their Policy elements skipped by
>> CXF without realizing it.)
>>
>> But to test, I did just yank the ValidatorConfiguration from the local WSDL
>> file that the SOAP client reads via the DoubleItService.java class and got
>> the same error message.  (The Callback handler you see for the client-side
>> config in the Metro example was never present in the CXF client code--it
>> just has access to the service WSDL.)  mvn exec:exec with the -X option and
>> using a logging.properties file didn't provide any more useful information.
>>
>> I'll start debugging without the Metro-specific elements to see if I can
>> find anything else.
>>
>> Thanks,
>> Glen
>>
>> dkulp wrote:
>> > Hate to ask the obvious, but did you yank out the Metro specific policies
>> > from
>> > the wsdl?  Example: the ValidatorConfiguration policy and CallbackHandler
>> > and
>> > such?
>> >
>> > Not sure if upping logging levels will help.   I've started going through
>> > and
>> > tried to make it output better error messages that provide more details
>> > when
>> > policies cannot be met, but apparently this error message got through.
>> > It
>> > definitely needs some work to make sure it will track what policies could
>> > not
>> > be satisfied to make the error message a bit better.
>> >
>> > Dan
>
> --
> Daniel Kulp
> dkulp@...
> http://www.dankulp.com/blog 

[Sergey Beryozkin-2]

Hi

>
>
> dkulp wrote:
>>
>> Then per the policy spec, ALL of the policy elements (that aren't
>> wsp:Optional=true) must be applied.   The policy spec doesn't say what the
>> namespaces and such of the individual policy assertion that would go into
>> the
>> All are.   Other specs (and company proprietary things) dictate those.
>
> OK, I see--policy elements that are of a namespace that the processor does
> not understand are *not* to be ignored, but an error given instead, unless
> wsp:Optional=true is set.

There's one more wrinkle in the WS-Policy spec, it's an attribute called 'ignorable'.
Note, wsp:Optional is a syntactic sugar, just so that policy authors could avoid manually typing various alternatives.
At runtime it always has to expanf into multiple alternatives on the server side  (as I noted in the prev email) and it has no
meaning for the client choosing between multiple alternatives. The client just chooses al alternative where it has to meet all the
assertions, wsp:optional must've gone by that time, as far as the client choosing an alternative is concerned.

So there's also wsp:ignorable. It means "ignorable for the purpose of the policy intersection". Policy intersection is about a
client stating in advance what policies have to be met and then intersecting them against those found in a retrieved service
contract doc. Ex :

Client expects (shortcut for a policy with a single alternative) :
<wsp:Policy>
  <A/>
</wsp:Policy>

Server says :

<wsp:Policy>
 <ExactlyOnce>
  <All><B/></All>
 </ExactlyOnce>
</wsp:Policy>

Even if the client understands B the intersection fails.

Ex :

Server says :

<wsp:Policy>
 <ExactlyOnce>
  <All><A><B/></All>
 </ExactlyOnce>
</wsp:Policy>

intersection fails again as the client expects B only.

Ex.

Server says :

<wsp:Policy>
 <ExactlyOnce>
  <All><A><B/></All>
  <All><A></All>
 </ExactlyOnce>
</wsp:Policy>

Client succeeds in choosing the second alternative

and finally :

Server says :

<wsp:Policy>
 <ExactlyOnce>
  <All><A><B wsp:ignorable="true"/></All>
 </ExactlyOnce>
</wsp:Policy>

intersection succeeds even if the client does not understand 'B'.
Canonical example : 'B' means that service supports cxf:HA. If the client does not know what HA means then it will still be able to
consume that service. Thus it's safe to consume the alternative. The client which knows about cxf:HA will load some client side
plugins.
Hopefully we'll support the policy intersection too at some stage...

cheers, Sergey

>
> I'll plug away a little bit more at this, and if I can't get it working will
> supply a JIRA with a test case.
>
> Thanks,
> Glen
>
>
>
> --
> View this message in context:
> http://www.nabble.com/Debugging-%22None-of-the-policy-alternatives-can-be-satisfied%22-WS-SecPol-error-tp24384805p24392744.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>

[dkulp]

BTW:  I ran into this error as well today.   The best place to put a
breakpoint is in the supportsAlternative method of PolicyEngineImpl, right at
the "return false;" line.   That will give you the qname of the policy
assertion that it doesn't know how to deal with.

Dan


On Wed July 8 2009 12:00:59 am Daniel Kulp wrote:

> Hate to ask the obvious, but did you yank out the Metro specific policies
> from the wsdl?  Example: the ValidatorConfiguration policy and
> CallbackHandler and such?
>
> Not sure if upping logging levels will help.   I've started going through
> and tried to make it output better error messages that provide more details
> when policies cannot be met, but apparently this error message got through.
>    It definitely needs some work to make sure it will track what policies
> could not be satisfied to make the error message a bit better.
>
> Dan
>
> On Tue July 7 2009 11:38:41 pm Glen Mazza wrote:
> > Hello, I'm trying to create a CXF client accessing a Metro web service
> > that requires (via WS-SecurityPolicy statements) Username/Password
> > Tokens--this[1] web service, in particular.  Configuring the SOAP client
> > with this cxf.xml:
> >
> > <beans xmlns="http://www.springframework.org/schema/beans"
> >     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> >     xmlns:jaxws="http://cxf.apache.org/jaxws"
> >     xsi:schemaLocation="http://www.springframework.org/schema/beans
> >     http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
> >     http://cxf.apache.org/jaxws
> >     http://cxf.apache.org/schemas/jaxws.xsd">
> >
> > <jaxws:client
> > name="{http://www.example.org/contract/DoubleIt}DoubleItService"
> > createdFromAPI="true">
> >     <jaxws:properties>
> >         <entry key="ws-security.username" value="alice"/>
> >         <entry key="ws-security.password" value="clarinet"/>
> >     </jaxws:properties>
> > </jaxws:client>
> > </beans>
> >
> > Is returning this error:
> > [INFO] Exception in thread "main" javax.xml.ws.soap.SOAPFaultException:
> > None of the policy alternatives can be satisfied.
> > [INFO] at
> > org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:141)
> > [INFO] at $Proxy38.doubleIt(Unknown Source)
> > [INFO] at
> > com.mycompany.webservice.client.WSClient.doubleIt(WSClient.java:18)
> > [INFO] at
> > com.mycompany.webservice.client.WSClient.main(WSClient.java:11)
> >
> > Can anyone can see what the problem might be?  If not, prior to tracing
> > into the CXF source code, is there any other troubleshooting I can or
> > should do in order to determine the problem?
> >
> > Thanks,
> > Glen
> >
> > [1]
> > http://www.jroller.com/gmazza/entry/implementing_ws_security_using_userna
> >me tokens#MetroUT2-4

--
Daniel Kulp
dkulp@...
http://www.dankulp.com/blog