Stefan Pröls created CXF-6327:
---------------------------------
Summary: Invalid Policy exception for EndorsingSupportingTokens
with more than one token assertions
Key: CXF-6327
URL: https://issues.apache.org/jira/browse/CXF-6327
Project: CXF
Issue Type: Bug
Components: WS-* Components
Affects Versions: 3.0.4
Reporter: Stefan Pröls
Parsing WS-Security Policies containing EndorsingSupportingTokens with more
than one token assertion in its nested Policy throws a
"java.lang.IllegalArgumentException: Invalid Policy".
Here is a WSDL test-case:
https://rheaavs.element44.net/AvsMpsService_R1_Variante2.wsdl
The sp:EndorsingSupportingTokens/wsp:Policy has 2 token assertions as children:
a sp:X509Token and a sp:IssuedToken. Apparently CXF doesn't like that.
If I either remove one of these token assertions or put a wsp:ExactlyOne around
them, the exception will not be thrown and the SOAP-Request will be sent but
the remote server will not accept the message and return an InvalidSecurity
SOAP-Fault. Putting an wsp:ExactlyOne/wsp:All around the 2 tokens will cause
the exception to be thrown again.
According to the specification I cannot see anything wrong with this Policy.
See
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.2/errata01/os/ws-securitypolicy-1.2-errata01-os-complete.html
Section 8.3:
<sp:EndorsingSupportingTokens xmlns:sp="..." ... >
<wsp:Policy xmlns:wsp="...">
[Token Assertion]+
<sp:AlgorithmSuite ... > ... </sp:AlgorithmSuite> ?
(
<sp:SignedParts ... > ... </sp:SignedParts> |
<sp:SignedElements ... > ... </sp:SignedElements> |
<sp:EncryptedParts ... > ... </sp:EncryptedParts> |
<sp:EncryptedElements ... > ... </sp:EncryptedElements> |
<sp:ContentEncryptedElements ... > ... </sp:ContentEncryptedElements>
) *
...
</wsp:Policy>
...
</sp:EndorsingSupportingTokens>
...
/sp:EndorsingSupportingTokens/wsp:Policy/[Token Assertion]
The policy MUST identify one or more token assertions.
This bug currently makes it impossible to access WebServices using such a
SecurityPolicy for me as I couldn't find a client-side workaround.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
