WS-SecureConversation & MTOM Policy cannot be satisfied

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

WS-SecureConversation & MTOM Policy cannot be satisfied

pat7
Hi,
I want to implement a file transfer via Soap. I receive a wsdl and generate my classes via jaxb. I use Apache cxf 3.1.7 with Spring Boot to configure the cxf via java.

The policies (MTOM & WS-Conv.) references to all my methods from the endpoint. The client has to include in his request a security context token (SCT) to fulfil the policy(WS-Conv.). The server side authenticate the client with the SCT and according to the definition the SCT is not encrypting messages. (only to identify the client).
Furthermore, I do not cache the SCT, but I stored it in my database and want to compare it with a simple callback handler. Honestly, I don’t know if this works with a SCT and Apache CXF.

If I disable my WS-SecureConversation policy, my MTOM policy works, which I do not understand. Otherwise, if I enable all policies and send a request to the endpoint like the following one, I receive some errors.

Request
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
 <soap:Header>
<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
       <wsc:SecurityContextToken xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">
<wsc:Identifier xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">test:f33ba228-dfb6-45ff-ac3a-47ec391ccf7c</wsc:Identifier>
               </wsc:SecurityContextToken>
        </wsse:Security>
 </soap:Header>
        <soap:Body>
        </soap:Body>
</soap:Envelope>
End Request

With the above request I receive the following error message:

These policy alternatives can not be satisfied:
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}SecureConversationToken: No SecureConversation token found in message.
{http://www.w3.org/2007/08/soap12-mtom-policy}MTOM
        at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
        at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:102)
        at org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:44)
        at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:308)
        at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
...

Does anybody know why I am getting these errors? Thx in advance.
Regards,
Patrick

Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

coheigea
Administrator
I suggest using a debugger + putting a breakpoint here to find out why a
token wasn't retrieved from the list of security results:

https://github.com/apache/cxf/blob/master/rt/ws/security/src/main/java/org/apache/cxf/ws/security/policy/interceptors/SecureConversationInInterceptor.java#L457

Colm.

On Tue, May 16, 2017 at 9:43 AM, pat7 <[hidden email]> wrote:

> Hi,
> I want to implement a file transfer via Soap. I receive a wsdl and generate
> my classes via jaxb. I use Apache cxf 3.1.7 with Spring Boot to configure
> the cxf via java.
>
> The policies (MTOM & WS-Conv.) references to all my methods from the
> endpoint. The client has to include in his request a security context token
> (SCT) to fulfil the policy(WS-Conv.). The server side authenticate the
> client with the SCT and according to the definition the SCT is not
> encrypting messages. (only to identify the client).
> Furthermore, I do not cache the SCT, but I stored it in my database and
> want
> to compare it with a simple callback handler. Honestly, I don’t know if
> this
> works with a SCT and Apache CXF.
>
> If I disable my WS-SecureConversation policy, my MTOM policy works, which I
> do not understand. Otherwise, if I enable all policies and send a request
> to
> the endpoint like the following one, I receive some errors.
>
> *Request*
> <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
>  <soap:Header>
> <wsse:Security
> xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-
> 200401-wss-wssecurity-secext-1.0.xsd">
>        <wsc:SecurityContextToken
> xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">
> <wsc:Identifier
> xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">
> test:f33ba228-dfb6-45ff-ac3a-47ec391ccf7c</wsc:Identifier>
>                </wsc:SecurityContextToken>
>         </wsse:Security>
>  </soap:Header>
>         <soap:Body>
>         </soap:Body>
> </soap:Envelope>
> *End Request*
>
> With the above request I receive the following error message:
>
> These policy alternatives can not be satisfied:
> {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}
> SecureConversationToken:
> No SecureConversation token found in message.
> {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM
>         at
> org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(
> AssertionInfoMap.java:179)
>         at
> org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(
> PolicyVerificationInInterceptor.java:102)
>         at
> org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(
> AbstractPolicyInterceptor.java:44)
>         at
> org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(
> PhaseInterceptorChain.java:308)
>         at
> org.apache.cxf.transport.ChainInitiationObserver.onMessage(
> ChainInitiationObserver.java:121)
> ...
>
> Does anybody know why I am getting these errors? Thx in advance.
> Regards,
> Patrick
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.
> com/WS-SecureConversation-MTOM-Policy-cannot-be-satisfied-tp5780524.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

pat7
Hi, thx for replay.

I did a break point there, but I can see the soap request in the variable message - contents. Both are in the contents, the header with sct and the body.

Furthermore, I did some break points later and in other classes (NegotiationUtils.class) I can see every time my security header, but I receive for the boolean variable foundSCT always false.

Unfortunately, I did not find my message.

Here, are some contents of my debugged variables:

foundSCT = false
aim - table = "[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}HttpsToken=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}HttpsToken:true], null, null, {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportToken=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportToken:true], null, {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}TransportBinding:true], null, {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM=[{http://www.w3.org/2007/08/soap12-mtom-policy}MTOM:false, {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM:false, {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM:false, {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM:false]]"  ...all hashmaps

NegotiationUtils.class:

results - first - actionResults = "{1024=[{security-context-token=<wsc:SecurityContextToken xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">
                        <wsc:Identifier>test:f2a96bfc-ea8e-4246-8670-9a557140d6f7</wsc:Identifier>
                </wsc:SecurityContextToken>, validated-token=false, action=1024, id=, secret=null, token-element=[wsc:SecurityContextToken: null]}]}"

In the NegotiationUtils.class on line 233 cxf want to restore a token from a tokenstore, but I did not use a tokenstore in my project. The result from the command on line 233 is null. I think here is my mistake, but is the reason for that error that I did not use a tokenstore?

Regards,
Patrick
Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

coheigea
Administrator
Normally with WS-SecureConversation, the STS is co-located with the
endpoint. So when the endpoint gets the client request with the
SecurityContextToken, it can retrieve the original cached token that was
issued by the STS.

In your case you said you weren't using a cache. How is the
SecurityContextToken being issued?

Colm.

On Wed, May 24, 2017 at 4:57 PM, pat7 <[hidden email]> wrote:

> Hi, thx for replay.
>
> I did a break point there, but I can see the soap request in the variable
> message - contents. Both are in the contents, the header with sct and the
> body.
>
> Furthermore, I did some break points later and in other classes
> (NegotiationUtils.class) I can see every time my security header, but I
> receive for the boolean variable foundSCT always false.
>
> Unfortunately, I did not find my message.
>
> Here, are some contents of my debugged variables:
>
> foundSCT = false
> aim - table =
> "[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}
> HttpsToken=[{http://schemas.xmlsoap.org/ws/2005/07/
> securitypolicy}HttpsToken:true],
> null, null,
> {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}
> TransportToken=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}
> TransportToken:true],
> null,
> {http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}
> TransportBinding=[{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}
> TransportBinding:true],
> null,
> {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM=[{
> http://www.w3.org/2007/08/soap12-mtom-policy}MTOM:false,
> {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM:false,
> {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM:false,
> {http://www.w3.org/2007/08/soap12-mtom-policy}MTOM:false]]"  ...all
> hashmaps
>
> NegotiationUtils.class:
>
> results - first - actionResults =
> "{1024=[{security-context-token=<wsc:SecurityContextToken
> xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">
>
> <wsc:Identifier>test:f2a96bfc-ea8e-4246-8670-9a557140d6f7</wsc:Identifier>
>                 </wsc:SecurityContextToken>, validated-token=false,
> action=1024, id=,
> secret=null, token-element=[wsc:SecurityContextToken: null]}]}"
>
> In the NegotiationUtils.class on line 233 cxf want to restore a token from
> a
> tokenstore, but I did not use a tokenstore in my project. The result from
> the command on line 233 is null. I think here is my mistake, but is the
> reason for that error that I did not use a tokenstore?
>
> Regards,
> Patrick
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.
> com/WS-SecureConversation-MTOM-Policy-cannot-be-
> satisfied-tp5780524p5780663.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

pat7
I just wrote a method with an random generator to issue the secuirty context token. After that I stored the token in a database and then I compare the received sctoken from the client with the token in the database via a callbackhandler.

I think that does not make sense or it is wrong to use a policy with a supporting token "secureconversation" without a tokenstore. Am I right?

In my opinion, I have two options.

1) Apply a STS, which uses all functionalities of the apache cxf to use a policy with WS-SecureConversation
2) Remove the policy of WS-SecureConversation.
I do not prefer option two.

Regards,
Patrick
Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

coheigea
Administrator
If you use WS-SecureConversation with CXF it sets up a co-located STS (with
the endpoint) automatically for you. Your client can invoke on the
endpoint/STS first to get a SecurityContextToken before then invoking on
the endpoint with the token.

Colm.

On Thu, May 25, 2017 at 10:52 AM, pat7 <[hidden email]> wrote:

> I just wrote a method with an random generator to issue the secuirty
> context
> token. After that I stored the token in a database and then I compare the
> received sctoken from the client with the token in the database via a
> callbackhandler.
>
> I think that does not make sense or it is wrong to use a policy with a
> supporting token "secureconversation" without a tokenstore. Am I right?
>
> In my opinion, I have two options.
>
> 1) Apply a STS, which uses all functionalities of the apache cxf to use a
> policy with WS-SecureConversation
> 2) Remove the policy of WS-SecureConversation.
> I do not prefer option two.
>
> Regards,
> Patrick
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.
> com/WS-SecureConversation-MTOM-Policy-cannot-be-
> satisfied-tp5780524p5780686.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

pat7
Ok, honestly then I do not understand where I have a mistake.

I use the following policy for WS-SecureConversation:

<wsp:Policy xmlns:wssp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
               wsu:Id="AuthSecurityPolicy">
      <wsp:ExactlyOne>
         <wsp:All>
           
            <wssp:TransportBinding>
               <wsp:Policy>
                  <wssp:TransportToken>
                     <wsp:Policy>
                        <wssp:HttpsToken RequireClientCertificate="false">
                        </wssp:HttpsToken>
                     </wsp:Policy>
                  </wssp:TransportToken>
               </wsp:Policy>
            </wssp:TransportBinding>
           
            <wssp:SupportingTokens>
               <wsp:Policy>
                  <wssp:SecureConversationToken wssp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                     <wssp:Issuer>
                        <wsa:Address>https://localhost:8443/soap-own/SecurityTokenService-2.6.0.1.0</wsa:Address>
                     </wssp:Issuer>
                  </wssp:SecureConversationToken>
               </wsp:Policy>
            </wssp:SupportingTokens> 
         </wsp:All>
      </wsp:ExactlyOne>
   </wsp:Policy>

Furthermore I send a request from a java client with the following code:

JaxWsProxyFactoryBean jaxWsproxyFactory = new JaxWsProxyFactoryBean();
                jaxWsproxyFactory.setServiceClass(TransferServicePortType.class);
                jaxWsproxyFactory.setAddress("https://localhost:8443/soap-own/TransferService-2.6.0.1.0?wsdl");
               
                Map<String,Object> props = new HashMap<String, Object>();
                props.put("mtom-enabled", Boolean.TRUE);
                jaxWsproxyFactory.setProperties(props);
               
                TransferServicePortType client = (TransferServicePortType) jaxWsproxyFactory.create();
               
                Client clientNew = ClientProxy.getClient(client);
                clientNew.getRequestContext().put("ws-security.username.sct", "anna");
                clientNew.getRequestContext().put("ws-security.password.sct", "anna123");
               
                /*SOAPFactory sf = SOAPFactory.newInstance();
                SOAPElement sequenceElement = sf.createElement(new QName("http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd","wsse:Security"));
                SOAPElement identifierElement = sf.createElement(new QName("http://schemas.xmlsoap.org/ws/2005/02/sc","wsc:SecurityContextToken"));
                SOAPElement messageNumberElement = sf.createElement(new QName("http://schemas.xmlsoap.org/ws/2005/02/sc","wsc:Identifier"));
               
                messageNumberElement.addTextNode("test:bdaa9e53-3685-4b81-9b9c-9f7f4a0c0d99");
                identifierElement.addChildElement(messageNumberElement);
                sequenceElement.addChildElement(identifierElement);
               
                SoapHeader tokenHeader = new SoapHeader(new QName("http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd","wsse:Security"), sequenceElement);
                List<Header> headersList = new ArrayList<Header>();
                headersList.add(tokenHeader);
                clientNew.getRequestContext().put(Header.HEADER_LIST, headersList);*/
               
                CTListShipments request = new CTListShipments();
               
                QName qualifiedName = new QName("http://www.test.net/namespace/nachrichten", "ConsumerID");
                JAXBElement<String> ConsumerID = new JAXBElement<>(qualifiedName,String.class,null,"VR-8889991");
               
                QName qualifiedName1 = new QName("http://www.test.net/namespace/transfer", "KategorieDerLieferung");
                JAXBElement<String> KategorieDerLieferung = new JAXBElement<>(qualifiedName1,String.class,null,"130");
               
                request.setConsumerID(ConsumerID);
                request.setKategorieDerLieferung(KategorieDerLieferung);
               
                client.listShipments(request);

I enable WS-SecureConversation with the policy definition in the wsdl. On the server side I think that I do not have to do anything more. I hope, my implemented client is ok. The client works if I disable the WS-SecureConversation policy in the wsdl.

Maybe I miss something else to get the policy working.

Regards,
Patrick

Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

coheigea
Administrator
There is no bootstrap policy defined above - this is what the client uses
to talk to the STS to get the initial token. I'd encourage you to look at
the existing example test available in CXF here (SecureConversationTest):

https://github.com/apache/cxf/blob/master/systests/ws-security-examples

Colm.

On Mon, May 29, 2017 at 8:15 AM, pat7 <[hidden email]> wrote:

> Ok, honestly then I do not understand where I have a mistake.
>
> I use the following policy for WS-SecureConversation:
>
> <wsp:Policy
> xmlns:wssp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
>                wsu:Id="AuthSecurityPolicy">
>       <wsp:ExactlyOne>
>          <wsp:All>
>
>             <wssp:TransportBinding>
>                <wsp:Policy>
>                   <wssp:TransportToken>
>                      <wsp:Policy>
>                         <wssp:HttpsToken RequireClientCertificate="false">
>                         </wssp:HttpsToken>
>                      </wsp:Policy>
>                   </wssp:TransportToken>
>                </wsp:Policy>
>             </wssp:TransportBinding>
>
>             <wssp:SupportingTokens>
>                <wsp:Policy>
>                   <wssp:SecureConversationToken
> wssp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/
> IncludeToken/AlwaysToRecipient">
>                      <wssp:Issuer>
>
> <wsa:Address>https://localhost:8443/soap-own/
> SecurityTokenService-2.6.0.1.0</wsa:Address>
>                      </wssp:Issuer>
>                   </wssp:SecureConversationToken>
>                </wsp:Policy>
>             </wssp:SupportingTokens>
>          </wsp:All>
>       </wsp:ExactlyOne>
>    </wsp:Policy>
>
> Furthermore I send a request from a java client with the following code:
>
> JaxWsProxyFactoryBean jaxWsproxyFactory = new JaxWsProxyFactoryBean();
>                 jaxWsproxyFactory.setServiceClass(
> TransferServicePortType.class);
>
> jaxWsproxyFactory.setAddress("https://localhost:8443/soap-
> own/TransferService-2.6.0.1.0?wsdl");
>
>                 Map<String,Object> props = new HashMap<String, Object>();
>                 props.put("mtom-enabled", Boolean.TRUE);
>                 jaxWsproxyFactory.setProperties(props);
>
>                 TransferServicePortType client = (TransferServicePortType)
> jaxWsproxyFactory.create();
>
>                 Client clientNew = ClientProxy.getClient(client);
>                 clientNew.getRequestContext().
> put("ws-security.username.sct", "anna");
>                 clientNew.getRequestContext().
> put("ws-security.password.sct", "anna123");
>
>                 /*SOAPFactory sf = SOAPFactory.newInstance();
>                 SOAPElement sequenceElement = sf.createElement(new
> QName("http://docs.oasis-open.org/wss/2004/01/oasis-200401-
> wss-wssecurity-secext-1.0.xsd","wsse:Security"));
>                 SOAPElement identifierElement = sf.createElement(new
> QName("http://schemas.xmlsoap.org/ws/2005/02/sc","wsc:
> SecurityContextToken"));
>                 SOAPElement messageNumberElement = sf.createElement(new
> QName("http://schemas.xmlsoap.org/ws/2005/02/sc","wsc:Identifier"));
>
>
> messageNumberElement.addTextNode("test:bdaa9e53-
> 3685-4b81-9b9c-9f7f4a0c0d99");
>                 identifierElement.addChildElement(messageNumberElement);
>                 sequenceElement.addChildElement(identifierElement);
>
>                 SoapHeader tokenHeader = new SoapHeader(new
> QName("http://docs.oasis-open.org/wss/2004/01/oasis-200401-
> wss-wssecurity-secext-1.0.xsd","wsse:Security"),
> sequenceElement);
>                 List<Header> headersList = new ArrayList<Header>();
>                 headersList.add(tokenHeader);
>                 clientNew.getRequestContext().put(Header.HEADER_LIST,
> headersList);*/
>
>                 CTListShipments request = new CTListShipments();
>
>                 QName qualifiedName = new
> QName("http://www.test.net/namespace/nachrichten", "ConsumerID");
>                 JAXBElement<String> ConsumerID = new
> JAXBElement<>(qualifiedName,String.class,null,"VR-8889991");
>
>                 QName qualifiedName1 = new QName("http://www.test.net/
> namespace/transfer",
> "KategorieDerLieferung");
>                 JAXBElement<String> KategorieDerLieferung = new
> JAXBElement<>(qualifiedName1,String.class,null,"130");
>
>                 request.setConsumerID(ConsumerID);
>                 request.setKategorieDerLieferung(KategorieDerLieferung);
>
>                 client.listShipments(request);
>
> I enable WS-SecureConversation with the policy definition in the wsdl. On
> the server side I think that I do not have to do anything more. I hope, my
> implemented client is ok. The client works if I disable the
> WS-SecureConversation policy in the wsdl.
>
> Maybe I miss something else to get the policy working.
>
> Regards,
> Patrick
>
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.
> com/WS-SecureConversation-MTOM-Policy-cannot-be-
> satisfied-tp5780524p5780788.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com
Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

pat7
I can not change the policy because the policy is given. Additionally, I check again the norm, where the policy is defined.
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?
Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

Markus Schulz
In reply to this post by coheigea
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:

<wsp:Policy
      xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
      xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
      xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
      xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"
      xsi:schemaLocation="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy 
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.xsd"
      wsu:Id="BiPROAuthSecurityPolicy">
    <wsp:ExactlyOne>
      <wsp:All>
        <!--Definition des Transportbindings als HTTPS-->
        <sp:TransportBinding>
          <wsp:Policy>
            <sp:TransportToken>
              <wsp:Policy>
                <sp:HttpsToken RequireClientCertificate="false"/>
              </wsp:Policy>
            </sp:TransportToken>
          </wsp:Policy>
        </sp:TransportBinding>
        <!--Definition der Anforderung an ein SecurityContext Token-->
        <sp:SupportingTokens>
          <wsp:Policy>
            <sp:SecureConversationToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
              <sp:Issuer>
                <wsa:Address>https://example.com/SecurityTokenService</wsa:Address>
              </sp:Issuer>
            </sp:SecureConversationToken>
          </wsp:Policy>
        </sp:SupportingTokens>
<!-- ACHTUNG: diesen Teil erzwingt mein ServiceProvider, da CXF per
Default sonst WS-T 1.3 benutzen würde-->
        <sp:Trust10>
          <wsp:Policy>
            <sp:MustSupportIssuedTokens/>
          </wsp:Policy>
        </sp:Trust10>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy>

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

<wsp:Policy>
        <sp:BootstrapPolicy>
                <wsp:Policy>
                        <sp:UsernameToken
sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                                <wsp:Policy>
                                        <sp:WssUsernameToken11/>
                                </wsp:Policy>
                        </sp:UsernameToken>
                </wsp:Policy>
        </sp:BootstrapPolicy>
</wsp:Policy>

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
org.apache.cxf.ws.security.trust.STSClient:

The given client generates a "SOAPAction" (http-)header like:
WS-Trust-Namespace (Trust10, Trust13, ..)/RST/SCT
or
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...


regards,
msc
Reply | Threaded
Open this post in threaded view
|

Re: WS-SecureConversation & MTOM Policy cannot be satisfied

pat7
Hi,
thx for the detailed response and yes I implement the BIPRO Norm.
I spend the last days to get working my transfer service but I did not have success. I insert the boostrap policy into my transfer service wsdl and the policy looks following:

 <wsp:Policy
      xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
      xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
      xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing"
      xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns:wst="http://schemas.xmlsoap.org/ws/2005/02/trust"
      xsi:schemaLocation="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy 
http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/ws-securitypolicy.xsd"
      wsu:Id="AuthSecurityPolicy">
    <wsp:ExactlyOne>
      <wsp:All>
       
        <sp:TransportBinding>
          <wsp:Policy>
            <sp:TransportToken>
              <wsp:Policy>
                <sp:HttpsToken RequireClientCertificate="false"/>
              </wsp:Policy>
            </sp:TransportToken>
          </wsp:Policy>
        </sp:TransportBinding>
       
                        <sp:SupportingTokens>
                                        <wsp:Policy> 
                                                <sp:SecureConversationToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                                                  <sp:Issuer>
                                                        <wsa:Address>https://localhost:8443/TransferService-2.6.0.1.0</wsa:Address>
                                                  </sp:Issuer>
                                                  <wsp:Policy>
                                                        <sp:BootstrapPolicy>
                                                                <wsp:Policy>
                                                                        <sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                                                                                        <wsp:Policy>
                                                                                                        <sp:WssUsernameToken11/>
                                                                                        </wsp:Policy>
                                                                        </sp:UsernameToken>
                                                                </wsp:Policy>
                                                        </sp:BootstrapPolicy> 
                                                  </wsp:Policy>
                                                </sp:SecureConversationToken>
                                        </wsp:Policy>
                        </sp:SupportingTokens> 
                        <sp:Trust10>
                                <wsp:Policy>
                                        <sp:MustSupportIssuedTokens/>
                                </wsp:Policy>
                        </sp:Trust10>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy> 

Additionally, I am the STS provider because no central STS provider exits. I store all security context token in a database where I can retrieve the token easy. I implement a 260.1 STS, which can only issue tokens.
I add the bootstrap policy into sts wsdl too, for testing with soap ui.

The policy looks like the following:
<wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="BiPROAuthSecurityPolicy"> 
      <wsp:ExactlyOne>
         <wsp:All>           
            <sp:TransportBinding>
               <wsp:Policy>
                  <sp:TransportToken>
                     <wsp:Policy>
                        <sp:HttpsToken RequireClientCertificate="false"/>
                     </wsp:Policy>
                  </sp:TransportToken>
               </wsp:Policy>
            </sp:TransportBinding>           
            <sp:SupportingTokens> 
               <wsp:Policy>
                  <wsp:ExactlyOne>                     
                    <wsp:All>
                                                <sp:UsernameToken  wsu:Id="BiPROBasicToken" sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                            <wsp:Policy/>
                  </sp:UsernameToken> 
                     </wsp:All> 
                  </wsp:ExactlyOne>
               </wsp:Policy>
                           <wsp:Policy>
                                                        <sp:BootstrapPolicy>
                                                                <wsp:Policy>
                                                                        <sp:UsernameToken sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
                                                                                        <wsp:Policy>
                                                                                                        <sp:WssUsernameToken11/>
                                                                                        </wsp:Policy>
                                                                        </sp:UsernameToken>
                                                                </wsp:Policy>
                                                        </sp:BootstrapPolicy> 
                                                  </wsp:Policy>
            </sp:SupportingTokens>
         </wsp:All>
      </wsp:ExactlyOne>
   </wsp:Policy>

In soap ui I add the sct manually and generate the following request:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:tran="http://www.bipro.net/namespace/transfer" xmlns:bas="http://www.bipro.net/namespace/basis" xmlns:nac="http://www.bipro.net/namespace/nachrichten">
   <soapenv:Header>
    <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsc:SecurityContextToken xmlns:wsc="http://schemas.xmlsoap.org/ws/2005/02/sc">
                        <wsc:Identifier>test:45e9444a-ee7a-42d7-841f-66fd20d525ac</wsc:Identifier>
                </wsc:SecurityContextToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <tran:listShipments>
         <tran:Request>
           
           
            <nac:ConsumerID>VR-8889991</nac:ConsumerID>
           
           
<tran:KategorieDerLieferung></tran:KategorieDerLieferung>
           
            <tran:BestaetigeLieferungen>false</tran:BestaetigeLieferungen>
         </tran:Request>
      </tran:listShipments>
   </soapenv:Body>
</soapenv:Envelope>

Unfortunately, I receive still the same errors:

These policy alternatives can not be satisfied:
{http://schemas.xmlsoap.org/ws/2005/07/securitypolicy}SecureConversationToken: No SecureConversation token found in message.
{http://www.w3.org/2007/08/soap12-mtom-policy}MTOM
        at org.apache.cxf.ws.policy.AssertionInfoMap.checkEffectivePolicy(AssertionInfoMap.java:179)
        at org.apache.cxf.ws.policy.PolicyVerificationInInterceptor.handle(PolicyVerificationInInterceptor.java:102)
        at org.apache.cxf.ws.policy.AbstractPolicyInterceptor.handleMessage(AbstractPolicyInterceptor.java:44)


I tried the last the days to adapt policy but I did not have success. Is it possible that the problem occurs because I do not use the full functionalities from the cxf sts?

Maybe anybody know where I produce my errors.

Regards,
Patrick