Rampart
  1. Rampart
  2. RAMPART-193

Missing signature in SOAP fault messages

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 1.4
    • Fix Version/s: 1.5
    • Component/s: None
    • Labels:
      None
    • Environment:
      Windows Vista
      Apache Tomcat 5.5.26
      Axis2 1.4
      Rampart 1.4
      Java JRE: 1.5.0.14

      Description

      Hi,

      I'm working with Axis2 and Rampart to create secure web services, and I have the following issue: Whenever an Axis fault is generated on the server's side,

      the SOAP fault message send back to the client is not signed. It results in an error since the client is expecting a signed SOAP enveloppe. I'm working with

      AXIS2 1.4 and Rampart 1.4. I've tried to find out in the Issue Tracking section of Rampart web site. According to the following reports

      (http://issues.apache.org/jira/browse/RAMPART-18 and http://issues.apache.org/jira/browse/RAMPART-90 ) the issue is said to have been fixed in version 1.4 of

      Rampart so I'm wondering if I'm doing something wrong or if somehow the issue persists. Any clue will be very welcome. Thanks for the help.

      This is a normal message when there is no faults:

      [INFO] Deploying module: addressing-1.4 -

      file:/C:/Data/projets/WebServices20080613/code/espaceDeTravail_20080709/essaisDeploiementWS14Client_1/ressources/modules/addressing-1.4.mar
      [INFO] Deploying module: rahas-1.4 -

      file:/C:/Data/projets/WebServices20080613/code/espaceDeTravail_20080709/essaisDeploiementWS14Client_1/ressources/modules/rahas-1.4.mar
      [INFO] Deploying module: rampart-1.4 -

      file:/C:/Data/projets/WebServices20080613/code/espaceDeTravail_20080709/essaisDeploiementWS14Client_1/ressources/modules/rampart-1.4.mar
      [INFO] Deploying module: metadataExchange - file:/C:/Data/projets/WebServices20080613/code/espaceDeTravail_20080709/essaisDeploiementWS14Client_1/lib/mex-

      1.4-impl.jar
      [INFO] Verification successful for URI "#Id-30303804"
      [INFO] Verification successful for URI "#id-20457766"
      [INFO] Verification successful for URI "#id-1412294"
      [INFO] Verification successful for URI "#Timestamp-2746929"
      Voici le resultat de l'appel:
      1721

      ==========================================================
      This is the message I'm getting when a fault is generated.
      ==========================================================

      [INFO] Deploying module: addressing-1.4 -

      file:/C:/Data/projets/WebServices20080613/code/espaceDeTravail_20080709/essaisDeploiementWS14Client_1/ressources/modules/addressing-1.4.mar
      [INFO] Deploying module: rahas-1.4 -

      file:/C:/Data/projets/WebServices20080613/code/espaceDeTravail_20080709/essaisDeploiementWS14Client_1/ressources/modules/rahas-1.4.mar
      [INFO] Deploying module: rampart-1.4 -

      file:/C:/Data/projets/WebServices20080613/code/espaceDeTravail_20080709/essaisDeploiementWS14Client_1/ressources/modules/rampart-1.4.mar
      [INFO] Deploying module: metadataExchange - file:/C:/Data/projets/WebServices20080613/code/espaceDeTravail_20080709/essaisDeploiementWS14Client_1/lib/mex-

      1.4-impl.jar
      [ERROR] Missing wsse:Security header in request
      org.apache.axis2.AxisFault: Missing wsse:Security header in request
      at org.apache.rampart.handler.RampartReceiver.setFaultCodeAndThrowAxisFault(RampartReceiver.java:172)

      ==============================================
      This is the soap enveloppe sent to the Client.
      ==============================================

      <soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
      <soapenv:Body>
      <soapenv:Fault>
      <soapenv:Code>
      <soapenv:Value>soapenv:Receiver</soapenv:Value>
      </soapenv:Code>
      <soapenv:Reason>
      <soapenv:Text xml:lang="en-US">ERREUR TEST ----- ERREUR TEST ----- ERREUR TEST</soapenv:Text>
      </soapenv:Reason>
      <soapenv:Detail/>
      </soapenv:Fault>
      </soapenv:Body>
      </soapenv:Envelope>

      ===================================================================================================================================
      This is the Policy file I'm using. Besides the locations of the Keystore, it is the same policy on both ends (service and client).
      ===================================================================================================================================

      <wsp:Policy wsu:Id="SigOnly"
      xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
      xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
      <wsp:ExactlyOne>
      <wsp:All>
      <sp:AsymmetricBinding
      xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
      <wsp:Policy>
      <sp:InitiatorToken>
      <wsp:Policy>
      <sp:X509Token

      sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient">
      <wsp:Policy>
      <sp:WssX509V3Token10 />
      </wsp:Policy>
      </sp:X509Token>
      </wsp:Policy>
      </sp:InitiatorToken>
      <sp:RecipientToken>
      <wsp:Policy>
      <sp:X509Token
      sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never">
      <wsp:Policy>
      <sp:RequireThumbprintReference />
      <sp:WssX509V3Token10 />
      </wsp:Policy>
      </sp:X509Token>
      </wsp:Policy>
      </sp:RecipientToken>
      <sp:AlgorithmSuite>
      <wsp:Policy>
      <sp:TripleDesRsa15 />
      </wsp:Policy>
      </sp:AlgorithmSuite>
      <sp:Layout>
      <wsp:Policy>
      <sp:Lax />
      </wsp:Policy>
      </sp:Layout>
      <sp:IncludeTimestamp />
      <sp:OnlySignEntireHeadersAndBody />
      </wsp:Policy>
      </sp:AsymmetricBinding>
      <sp:SignedParts
      xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
      <sp:Body />
      <sp:Header Namespace="http://www.w3.org/2005/08/addressing" />
      </sp:SignedParts>
      <!--
      <sp:EncryptedParts
      xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy">
      <sp:Body /> </sp:EncryptedParts>
      -->
      <sp:Wss11>
      <wsp:Policy>
      <sp:MustSupportRefKeyIdentifier />
      <sp:MustSupportRefIssuerSerial />
      <sp:MustSupportRefThumbprint />
      <sp:MustSupportRefEncryptedKey />
      <sp:MustSupportSignatureConfirmation />
      </wsp:Policy>
      </sp:Wss11>
      <sp:Trust10>
      <wsp:Policy>
      <sp:MustSupportIssuedTokens />
      <sp:RequireClientEntropy />
      <sp:RequireServerEntropy />
      </wsp:Policy>
      </sp:Trust10>
      <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
      <ramp:user>test</ramp:user>
      <ramp:encryptionUser>test</ramp:encryptionUser>
      <ramp:passwordCallbackClass>
      org.example.www.essaisdeploiementwebservice2.PWCBHandler
      </ramp:passwordCallbackClass>
      <ramp:signatureCrypto>
      <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
      <ramp:property
      name="org.apache.ws.security.crypto.merlin.keystore.type"> JKS</ramp:property>
      <ramp:property name="org.apache.ws.security.crypto.merlin.file"> ressources\keys\ws.jks
      </ramp:property>
      <ramp:property
      name="org.apache.ws.security.crypto.merlin.keystore.password"> changeit</ramp:property>
      </ramp:crypto>
      </ramp:signatureCrypto>
      <ramp:encryptionCypto>
      <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
      <ramp:property
      name="org.apache.ws.security.crypto.merlin.keystore.type"> JKS</ramp:property>
      <ramp:property name="org.apache.ws.security.crypto.merlin.file">ressources\keys\ws.jks
      </ramp:property>
      <ramp:property
      name="org.apache.ws.security.crypto.merlin.keystore.password"> changeit</ramp:property>
      </ramp:crypto>
      </ramp:encryptionCypto>
      </ramp:RampartConfig>
      </wsp:All>
      </wsp:ExactlyOne>
      </wsp:Policy>

      ===================================================================================
      This is the parts of axis2.xml where the security is enabled in the OutFaultFlow:
      ===================================================================================

      <phaseOrder type="OutFaultFlow">
      <!-- user can add his own phases to this area -->
      <phase name="soapmonitorPhase"/>
      <phase name="OperationOutFaultPhase"/>
      <phase name="MessageOut"/>
      <phase name="RMPhase"/>
      <phase name="PolicyDetermination"/>
      <phase name="Security"/>

      </phaseOrder>

      1. RampartMessageData.patch
        1 kB
        Bob Jacoby
      2. RampartMessageData.java
        27 kB
        Bob Jacoby
      3. RampartMessageData.class
        16 kB
        Bob Jacoby

        Activity

        Hide
        John Applebey added a comment -

        Do we have a patch for this yet?

        Show
        John Applebey added a comment - Do we have a patch for this yet?
        Hide
        Bob Jacoby added a comment -

        Unless I'm missing something this issue makes it impossible to use custom soap faults in a secured service. I'm using Axis 1.4.1 and Rampart 1.4.

        The reason the messages are not being signed appears to be due to the policy not being found during the OutFaultFlow. In tracing the flow through the RampartMessageData constructor during the OutFaultFlow, none of the attempts to load the servicePolicy from different locations results in the policy being loaded.

        Show
        Bob Jacoby added a comment - Unless I'm missing something this issue makes it impossible to use custom soap faults in a secured service. I'm using Axis 1.4.1 and Rampart 1.4. The reason the messages are not being signed appears to be due to the policy not being found during the OutFaultFlow. In tracing the flow through the RampartMessageData constructor during the OutFaultFlow, none of the attempts to load the servicePolicy from different locations results in the policy being loaded.
        Hide
        Bob Jacoby added a comment - - edited

        I implemented a workaround that seems to work for me. Basically, I defined a custom handler in the OutFaultFlow that implements the same lookup that the RampartMessageData currently performs (in case something is fixed that suddenly resolves this issue or there are other cases such that the policy will be found in the current methodology). If the policy isn't found, I then try to calculate the policies on the policy subject. I then set the policy in the message context, which RampartMessageData will then see.

        I added the handler to a custom module in a custom phase which I inserted at the beginning of the OutFaultFlow.

        ------Handler Code--------
        public InvocationResponse invoke(MessageContext messageContext) throws AxisFault {
        Policy effectivePolicy = getEffectivePolicy(messageContext);
        if (effectivePolicy != null)

        { messageContext.setProperty(RampartMessageData.KEY_RAMPART_POLICY, effectivePolicy); }

        return InvocationResponse.CONTINUE;
        }

        private Policy getEffectivePolicy(MessageContext msgCtx) {
        Policy servicePolicy = null;

        if (msgCtx.getProperty(RampartMessageData.KEY_RAMPART_POLICY) != null)

        { servicePolicy = (Policy) msgCtx.getProperty(RampartMessageData.KEY_RAMPART_POLICY); }

        if (servicePolicy == null)

        { servicePolicy = msgCtx.getEffectivePolicy(); }

        if (servicePolicy == null) {
        Parameter param = msgCtx.getParameter(RampartMessageData.KEY_RAMPART_POLICY);
        if (param != null)

        { OMElement policyElem = param.getParameterElement().getFirstElement(); servicePolicy = PolicyEngine.getPolicy(policyElem); }

        }
        if (servicePolicy == null && msgCtx.getAxisService() != null && msgCtx.getAxisService().getPolicySubject() != null) {
        Collection subjectPolicies = msgCtx.getAxisService().getPolicySubject().getAttachedPolicyComponents();
        if (subjectPolicies.size() > 0)

        { servicePolicy = PolicyUtil.getMergedPolicy(new ArrayList(subjectPolicies), msgCtx.getAxisService()); }

        }
        return servicePolicy;
        }

        Show
        Bob Jacoby added a comment - - edited I implemented a workaround that seems to work for me. Basically, I defined a custom handler in the OutFaultFlow that implements the same lookup that the RampartMessageData currently performs (in case something is fixed that suddenly resolves this issue or there are other cases such that the policy will be found in the current methodology). If the policy isn't found, I then try to calculate the policies on the policy subject. I then set the policy in the message context, which RampartMessageData will then see. I added the handler to a custom module in a custom phase which I inserted at the beginning of the OutFaultFlow. ------ Handler Code -------- public InvocationResponse invoke(MessageContext messageContext) throws AxisFault { Policy effectivePolicy = getEffectivePolicy(messageContext); if (effectivePolicy != null) { messageContext.setProperty(RampartMessageData.KEY_RAMPART_POLICY, effectivePolicy); } return InvocationResponse.CONTINUE; } private Policy getEffectivePolicy(MessageContext msgCtx) { Policy servicePolicy = null; if (msgCtx.getProperty(RampartMessageData.KEY_RAMPART_POLICY) != null) { servicePolicy = (Policy) msgCtx.getProperty(RampartMessageData.KEY_RAMPART_POLICY); } if (servicePolicy == null) { servicePolicy = msgCtx.getEffectivePolicy(); } if (servicePolicy == null) { Parameter param = msgCtx.getParameter(RampartMessageData.KEY_RAMPART_POLICY); if (param != null) { OMElement policyElem = param.getParameterElement().getFirstElement(); servicePolicy = PolicyEngine.getPolicy(policyElem); } } if (servicePolicy == null && msgCtx.getAxisService() != null && msgCtx.getAxisService().getPolicySubject() != null) { Collection subjectPolicies = msgCtx.getAxisService().getPolicySubject().getAttachedPolicyComponents(); if (subjectPolicies.size() > 0) { servicePolicy = PolicyUtil.getMergedPolicy(new ArrayList(subjectPolicies), msgCtx.getAxisService()); } } return servicePolicy; }
        Hide
        Maik Hassel added a comment -

        I ran into the same issue in a production system. It is quite surprising that this issue - while flagged in various JIRAs over the past 9 months - seems of rather low priority. After all, as Bob already stated, it makes it impossible to use custom soap faults in a secured service, which is a pretty rudimentary and necessary thing to do?

        Is there at least a quick fix or patch I can add myself to get this working?

        Show
        Maik Hassel added a comment - I ran into the same issue in a production system. It is quite surprising that this issue - while flagged in various JIRAs over the past 9 months - seems of rather low priority. After all, as Bob already stated, it makes it impossible to use custom soap faults in a secured service, which is a pretty rudimentary and necessary thing to do? Is there at least a quick fix or patch I can add myself to get this working?
        Hide
        Grégory Provost added a comment -

        Any news regarding this issue ? Is there a patch/new version available ? Regards

        Show
        Grégory Provost added a comment - Any news regarding this issue ? Is there a patch/new version available ? Regards
        Hide
        Bob Jacoby added a comment -

        Patch to add additional lookup of policy

        Show
        Bob Jacoby added a comment - Patch to add additional lookup of policy
        Hide
        Bob Jacoby added a comment -

        I just added a patch that should resolve the issue that I discussed in Oct. All it does is add the last servicePolicy lookup I listed above (from the attachedPolicyComponents) to the end of all the other lookups in the RampartMessageData constructor. I threw this patch together based on correspondence I had with Maik who implemented this change himself. I have not tested this in my environment however.

        Without stepping through the code in more detail I have a feeling this may be a fix to a symptom, but not necessarily the cure. I say this because I would think the Policy should be retrieved from one of the earlier retrieval attempts in the constructor (e.g., from MessageContext). However, this at lease resolves the issue of not getting signed faults back.

        Show
        Bob Jacoby added a comment - I just added a patch that should resolve the issue that I discussed in Oct. All it does is add the last servicePolicy lookup I listed above (from the attachedPolicyComponents) to the end of all the other lookups in the RampartMessageData constructor. I threw this patch together based on correspondence I had with Maik who implemented this change himself. I have not tested this in my environment however. Without stepping through the code in more detail I have a feeling this may be a fix to a symptom, but not necessarily the cure. I say this because I would think the Policy should be retrieved from one of the earlier retrieval attempts in the constructor (e.g., from MessageContext). However, this at lease resolves the issue of not getting signed faults back.
        Hide
        Grégory Provost added a comment -

        Thanks Bob. One more question, That would be very nice if you could attach the patched version of RAMPART-CORE ? Thanks Gregory

        Show
        Grégory Provost added a comment - Thanks Bob. One more question, That would be very nice if you could attach the patched version of RAMPART-CORE ? Thanks Gregory
        Hide
        Bob Jacoby added a comment -

        Attaching a patched version of RampartMessageData.java using patch provided earlier.

        Show
        Bob Jacoby added a comment - Attaching a patched version of RampartMessageData.java using patch provided earlier.
        Hide
        Bob Jacoby added a comment -

        Attached compiled version of RampartMessageData as generated by IBM 1.5 JDK.

        Show
        Bob Jacoby added a comment - Attached compiled version of RampartMessageData as generated by IBM 1.5 JDK.
        Hide
        Nandana Mihindukulasooriya added a comment -

        Hi,
        Will you be able to test this with Axis2 1.5 and latest Rampart trunk. Thilina has contributed test cases for negative scenarios (RAMPART-233) and now these negative scenarios are also checked in the integration tests of Rampart build.

        regards,
        Nandana

        Show
        Nandana Mihindukulasooriya added a comment - Hi, Will you be able to test this with Axis2 1.5 and latest Rampart trunk. Thilina has contributed test cases for negative scenarios ( RAMPART-233 ) and now these negative scenarios are also checked in the integration tests of Rampart build. regards, Nandana
        Hide
        Nandana Mihindukulasooriya added a comment -

        This issue is fixed in Rampart 1.5 and now Rampart integration test has tests for negative scenarios to make sure this is not broken again.

        regards,
        Nandana

        Show
        Nandana Mihindukulasooriya added a comment - This issue is fixed in Rampart 1.5 and now Rampart integration test has tests for negative scenarios to make sure this is not broken again. regards, Nandana
        Hide
        Edem Alipui added a comment -

        Thanks very much,

        I'll be looking forward for the release of rampar 1.5.

        Edem.

        On Mon, Aug 31, 2009 at 3:19 PM, Nandana Mihindukulasooriya (JIRA) <

        Show
        Edem Alipui added a comment - Thanks very much, I'll be looking forward for the release of rampar 1.5. Edem. On Mon, Aug 31, 2009 at 3:19 PM, Nandana Mihindukulasooriya (JIRA) <

          People

          • Assignee:
            Nandana Mihindukulasooriya
            Reporter:
            Edem Alipui
          • Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development