cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Schulz <>
Subject Re: WS-SecureConversation & MTOM Policy cannot be satisfied
Date Thu, 01 Jun 2017 12:56:24 GMT
Am Mittwoch, 31. Mai 2017, 11:25:13 schrieb pat7:
> I can not change the policy because the policy is given. Additionally,
> I check again the norm, where the policy is defined.

you have to add the bootstrap part yourself, if your service provider 
left out this essentially needed part. 
That's often the case (looks like you are consuming a (german) BiPRO 
Service), because they copy only the original part provided by the BiPRO 
spec to their service contract.

The BiPRO Norm 260.1 (and following) defines different possible STS-
endpoint authentication mechanisms. (VDG-Ticket, UserNameToken, 
UserNameToken+OTP, X509-Certificates) and the more advanced Saml-based 
ones (260.2).

For example (i have implemented BiPRO-Consumers too):

with the given policy from your service-provider wsdl like:

        <!--Definition des Transportbindings als HTTPS-->
                <sp:HttpsToken RequireClientCertificate="false"/>
        <!--Definition der Anforderung an ein SecurityContext Token-->
<!-- ACHTUNG: diesen Teil erzwingt mein ServiceProvider, da CXF per 
Default sonst WS-T 1.3 benutzen w├╝rde-->

Then you add after the <sp:Issuer> Element:


in this case you can see my service provider uses the WssUsernameToken 
profile for authentication at the STS-Endpoint to fetch the 
SecurityToken for the business services.

There are different options to get these security-policy in your client. 
(cxf.xml, edit wsdl, java-code)
The simplest (imho) is to edit the wsdl.

> The policy says that a SCT have to be included in the request and the
> issuer is necessary because it is possible that a provider can have
> different STS.
> I try to send request from soapui and receive still the same errors.
> Is there another possibility without changing the policy?

imho with soapui you need to fetch the token yourself and insert it into 
the business service (ws-security-header) call manually. 
You could create a soap-ui testsuite with at least two steps, one for 
fetching the token from sts-endpoint and then transfer the token from 
the result into the <SecurityContextToken> identifier (ws-security 
header) of the business call.
Except soap-ui can by this time automatically generate sts-clients, but 
then it needs the same bootstrap-part in the wsdl to accomplish this.
There is only one other option, the WS-MEX (Metadata-Exchange, supported 
from cxf too), but i've never seen support for WS-MEX by a service 
provider and are not familiar with this topic.

At least, *one important note*, to the cxf

The given client generates a "SOAPAction" (http-)header like:
WS-Trust-Namespace (Trust10, Trust13, ..)/RST/SCT
WS-Trust-Namespace (Trust10, Trust13, ..)/RST/Issue

and don't take the SOAPAction header as defined in the STS-Endpoint-WSDL 
contract as defined by the BiPRO norm 260++.
<wsdl:operation name="RequestSecurityToken"><soapbind:operation 
soapAction="urn:RequestSecurityToken" style="document"/>...

Perhaps a bug in cxf or forced from WS-Trust? I'm not sure.

But in my case the sts-provider follows the BiPRO spec and i am forced 
to use a SOAPAction header value "urn:RequestSecurityToken".
I've found no other way to configure this from cxf.xml or any other way. 
I have to derive a custom class from STSClient to allow the SOAPAction 
configuration (from cxf.xml in my case).
But after this small workaround, the STS part works like a charm with 
cxf for each business service. 
There is no further interaction with STS needed, inclusive token-
lifetime checks and automatically renewing...


View raw message