« Return to Thread: Debugging "None of the policy alternatives can be satisfied" WS-SecPol error
Re: Debugging "None of the policy alternatives can be satisfied" WS-SecPol error
by Sergey Beryozkin-2
::
Rate this Message:
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
> 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
« Return to Thread: Debugging "None of the policy alternatives can be satisfied" WS-SecPol error
| Free embeddable forum powered by Nabble | Forum Help |
