You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ws.apache.org by Erik Lund Jensen <in...@erikjensen.it> on 2019/08/07 16:32:08 UTC
cxf client using StAX and ws-security policy fails in PolicyEnforcer
when processing server response
Hi
I have upgraded an old ws-security cxf client application to Java 11. It
now uses StAX and builds a policy and sets the
PolicyConstants.POLICY_OVERRIDE at the client's requestContext.
It almost works, however, when getting to processing the response from the
server then the PolicyEnforcer throws exception with no message (null).
I ran a modified version of the PolicyEnforcer, which did not throw
validation exception (inspired by issue WSS-486 with the modified
if-statements in PolicyEnforcer).
The result was that the PolicyVerificationInInterceptor then listed all the
policy alternatives that could not be satisfied:
Caused by: org.apache.cxf.ws.policy.PolicyException: These policy
alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}WssX509V3Token10
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientToken
{
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RequireThumbprintReference
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AlgorithmSuite
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TripleDes
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Layout
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Lax
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}IncludeTimestamp
{
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}OnlySignEntireHeadersAndBody
{
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignBeforeEncrypting
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
at
org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
If I remove the PolicyVerificationInInterceptor from the cxf chain then the
message is decrypted and everything looks fine.
Could it be, that the PolicyEnforcer needs to know if it runs on the
server-side or client-side and thereby be less strict at the client-side?
Best regards
Erik
Re: cxf client using StAX and ws-security policy fails in
PolicyEnforcer when processing server response
Posted by Martin Gainty <mg...@hotmail.com>.
d/l and building 3.3.2 cxf
info.picocli:picocli:jar:3.9.5 has not been downloaded from it before.
? ideas on where picocli is located ?
*thanks*
________________________________
From: Erik Lund Jensen <in...@erikjensen.it>
Sent: Wednesday, August 7, 2019 12:32 PM
To: dev@ws.apache.org <de...@ws.apache.org>
Subject: cxf client using StAX and ws-security policy fails in PolicyEnforcer when processing server response
Hi
I have upgraded an old ws-security cxf client application to Java 11. It now uses StAX and builds a policy and sets the PolicyConstants.POLICY_OVERRIDE at the client's requestContext.
It almost works, however, when getting to processing the response from the server then the PolicyEnforcer throws exception with no message (null).
I ran a modified version of the PolicyEnforcer, which did not throw validation exception (inspired by issue WSS-486 with the modified if-statements in PolicyEnforcer).
The result was that the PolicyVerificationInInterceptor then listed all the policy alternatives that could not be satisfied:
Caused by: org.apache.cxf.ws.policy.PolicyException: These policy alternatives can not be satisfied:
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}WssX509V3Token10
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientToken
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RequireThumbprintReference
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AlgorithmSuite
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TripleDes
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Layout
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Lax
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}IncludeTimestamp
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}OnlySignEntireHeadersAndBody
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignBeforeEncrypting
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
{http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
If I remove the PolicyVerificationInInterceptor from the cxf chain then the message is decrypted and everything looks fine.
Could it be, that the PolicyEnforcer needs to know if it runs on the server-side or client-side and thereby be less strict at the client-side?
Best regards
Erik
Re: cxf client using StAX and ws-security policy fails in
PolicyEnforcer when processing server response
Posted by Colm O hEigeartaigh <co...@apache.org>.
Do you have a test-case that reproduces the problem that we could look at?
You shouldn't really need to work with PolicyEnforcer itself. To answer
your question though, yes PolicyEnforcer needs to know whether it's the
initiator or not - there is a "boolean initiator" in the constructor.
Colm.
On Wed, Aug 7, 2019 at 5:48 PM Erik Lund Jensen <in...@erikjensen.it> wrote:
> Hi
>
> I have upgraded an old ws-security cxf client application to Java 11. It
> now uses StAX and builds a policy and sets the
> PolicyConstants.POLICY_OVERRIDE at the client's requestContext.
>
> It almost works, however, when getting to processing the response from the
> server then the PolicyEnforcer throws exception with no message (null).
> I ran a modified version of the PolicyEnforcer, which did not throw
> validation exception (inspired by issue WSS-486 with the modified
> if-statements in PolicyEnforcer).
> The result was that the PolicyVerificationInInterceptor then listed all
> the policy alternatives that could not be satisfied:
>
> Caused by: org.apache.cxf.ws.policy.PolicyException: These policy
> alternatives can not be satisfied:
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AsymmetricBinding
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}InitiatorToken
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}X509Token
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}WssX509V3Token10
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RecipientToken
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}RequireThumbprintReference
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}AlgorithmSuite
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}TripleDes
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Layout
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}Lax
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}IncludeTimestamp
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}OnlySignEntireHeadersAndBody
> {
> http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignBeforeEncrypting
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}SignedParts
> {http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702}EncryptedParts
> at
> org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
>
> If I remove the PolicyVerificationInInterceptor from the cxf chain then
> the message is decrypted and everything looks fine.
> Could it be, that the PolicyEnforcer needs to know if it runs on the
> server-side or client-side and thereby be less strict at the client-side?
>
> Best regards
> Erik
>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: cxf client using StAX and ws-security policy fails in
PolicyEnforcer when processing server response
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Erik,
Would it be possible instead to create a test-case that I can apply
directly to CXF?
Colm.
On Fri, Sep 13, 2019 at 9:50 AM Erik Lund Jensen <in...@erikjensen.it> wrote:
> Hi
>
> I have forked cxf and created a branch "feature/dispatcher-policy" where
> the systests/jaxws DispatcherTest class has been retrofitted to test
> POLICY_OVERRIDE with StAX.
> See
> https://github.com/ErikLundJensen/cxf
>
> The branch should NOT be merged to master as I have disabled all the other
> tests in the DispatcherTest class and I have added ws-security policy wsdl
> as well.
> Anyhow, the branch reproduce the error I see in my project.
> PolicyEnforcer rejects the server reply at the client side.
>
> The following test case has been enhanced with ws-security policy:
> testStreamSourcePAYLOAD()
>
> The error can be reproduced by running that test case.
>
> Best regards,
> Erik
>
RE: cxf client using StAX and ws-security policy fails in
PolicyEnforcer when processing server response
Posted by Erik Lund Jensen <in...@erikjensen.it>.
Hi
I have forked cxf and created a branch "feature/dispatcher-policy" where
the systests/jaxws DispatcherTest class has been retrofitted to test
POLICY_OVERRIDE with StAX.
See
https://github.com/ErikLundJensen/cxf
The branch should NOT be merged to master as I have disabled all the other
tests in the DispatcherTest class and I have added ws-security policy wsdl
as well.
Anyhow, the branch reproduce the error I see in my project.
PolicyEnforcer rejects the server reply at the client side.
The following test case has been enhanced with ws-security policy:
testStreamSourcePAYLOAD()
The error can be reproduced by running that test case.
Best regards,
Erik