Hey Colm,
If I'm interpreting your suggestion correctly, I initially thought something
similar.
However, the latest version of the WS-SecurityPolicy 1.3 specification [1],
which Apache CXF references [2], states the cardinality of each of the four
asymmetric binding tokens is effectively one. For example, an InitiatorToken
or an InitiatorSignatureToken and an InitiatorEncryptionToken must be
specified, and the mandatory child Policy element(s) must include at least
one token assertion.
Nevertheless, I deployed a service with the below asymmetric binding to see
what would happen. The similar thought I had before initiating this thread
consisted of the below binding without the SignedParts element. You may
already be aware, but note empty SignedParts and EncryptedParts elements are
not options to render the other tokens not applicable, since default
behavior would then apply.
<wsp:All>
<wssp:AsymmetricBinding>
<wsp:Policy>
<wssp:InitiatorSignatureToken>
<wsp:Policy>
<wssp:X509Token
IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
<wsp:Policy>
<wssp:SignedParts>
<wssp:Body/>
</wssp:SignedParts>
</wsp:Policy>
</wssp:X509Token>
</wsp:Policy>
</wssp:InitiatorSignatureToken>
<wssp:InitiatorEncryptionToken>
<wsp:Policy>
<wssp:X509Token
IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
<wsp:Policy/>
</wssp:X509Token>
</wsp:Policy>
</wssp:InitiatorEncryptionToken>
<wssp:RecipientToken>
<wsp:Policy>
<wssp:X509Token
IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
<wsp:Policy/>
</wssp:X509Token>
</wsp:Policy>
</wssp:RecipientToken>
<wssp:AlgorithmSuite>
<wsp:Policy>
<wssp:Basic256/>
</wsp:Policy>
</wssp:AlgorithmSuite>
</wsp:Policy>
</wssp:AsymmetricBinding>
</wsp:All>
A request with a signed body produced the following exception during
outbound processing. These are Red Hat bits, so the line numbers may not
align with the community source.
Caused by: org.apache.cxf.ws.policy.PolicyException: No configured signature
username detected
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.policyNotAsserted(AbstractBindingBuilder.java:315)
[cxf-rt-ws-security-2.7.7.redhat-1.jar:2.7.7.redhat-1]
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AbstractBindingBuilder.getSignatureBuilder(AbstractBindingBuilder.java:1831)
[cxf-rt-ws-security-2.7.7.redhat-1.jar:2.7.7.redhat-1]
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignature(AsymmetricBindingHandler.java:508)
[cxf-rt-ws-security-2.7.7.redhat-1.jar:2.7.7.redhat-1]
at
org.apache.cxf.ws.security.wss4j.policyhandlers.AsymmetricBindingHandler.doSignBeforeEncrypt(AsymmetricBindingHandler.java:158)
[cxf-rt-ws-security-2.7.7.redhat-1.jar:2.7.7.redhat-1]
The conclusion I'm inclined to draw is a policy expression compliant with
the WS-SecurityPolicy specification
doesn't exist for this use case without support for an unbound X509Token
assertion.
Thank you for the discussion.
[1] -
http://docs.oasis-open.org/ws-sx/ws-securitypolicy/v1.3/errata01/os/ws-securitypolicy-1.3-errata01-os-complete.html
[2] - http://cxf.apache.org/docs/ws-securitypolicy.html
--
View this message in context:
http://cxf.547215.n5.nabble.com/WS-Policy-Expressions-for-X-509-Token-Assertions-tp5742248p5742384.html
Sent from the cxf-user mailing list archive at Nabble.com.
