IBM Support

PK29380: SOAP_PARSER REJECTS SOAP MESSAGE WITH DFHPIEP_RC(8) PLISAXA_RC(0) IF TWO DIFFERENT SOAP NAMESPACES IN USE

A fix is available

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • The SOAP parser will reject a SOAP message if two different SOAP
    namespaces are used, at different SOAP levels.  For example,
    SOAP 1.2 in the envelope, and SOAP 1.1 in the header. These
    being different causes the parser in the provider to reject the
    request with a SOAP fault. The root of this problem is that the
    WS-Security modules on the requester always add a SOAP 1.1
    header in SecurityContext::getHeader.
    In the trace you will see the following
    PI 0C16 PISN EXIT  - SOAP_PARSER  DFHPIEP_RC(8) PLISAXA_RC(0)
    AT_OFFSET(208)
    The offset may vary.
    

Local fix

  • As a workaround the pipelines could be changed to use SOAP 1.1
    instead of SOAP 1.2.
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED: All CICS Users.                              *
    ****************************************************************
    * PROBLEM DESCRIPTION: A Web Service request sent from CICS    *
    *                      using WS-Security and SOAP 1.2          *
    *                      incorrectly contains both SOAP 1.1 and  *
    *                      SOAP 1.2 namespaces.                    *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    A requester pipeline using SOAP 1.2 and WS-Security is defined
    and installed. An INVOKE WEBSERVICE call is made. WS-Security
    was setup to just sign the message. To sign the message DFHWSSE1
    has to add the necessary elements to the SOAP Header. There
    is no header element in the message so one gets added
    automatically. This is hardcoded to be the SOAP 1.1 header.
    The XML now has the SOAP Envelope element with the SOAP 1.2
    namespace defined and the SOAP Header element with the SOAP 1.1
    namespace defined. When the XML gets parsed by the provider it
    is rejected due to conflicting namespaces.
    A subsequent problem occurs when the provider sends back the
    resulting SOAP fault message: If WS-Security is enabled to sign
    the message then DFHWSSE1 will attempt to do so even though SOAP
    faults should not be signed.
    The attempt to do the signing results in the following
    exception:
    
    "SecurityContext::signMessage - No WS-Security Header found.
     Cannot add signature details to header if not present."
    
    This new SOAP fault replaces the original SOAP fault that
    reported the namespace error.
    
    A similar problem can occur if encryption is enabled for
    WS-Security. This results in the following exception:
    
    "SecurityContext::encryptBody - no header Element".
    

Problem conclusion

  • WS-Security has been changed so that the correct SOAP namespace
    will be added if a SOAP header is created. WS-Security will no
    longer attempt to sign or encrypt a SOAP Fault.
    

Temporary fix

  • FIX AVAILABLE BY PTF ONLY
    

Comments

APAR Information

  • APAR number

    PK29380

  • Reported component name

    CICSTS 3.1 Z/OS

  • Reported component ID

    5655M1500

  • Reported release

    400

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2006-08-04

  • Closed date

    2007-05-21

  • Last modified date

    2007-06-01

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    UK25372

Modules/Macros

  •    DFHWSSE1 DFHWS002 DFHWS003 DFHWS004 DFHWS005
    DFHWS006 DFHWS007 DFHWS008 DFHWS009 DFHWS010 DFHWS011 DFHWS012
    DFHWS013 DFHWS014 DFHWS015 DFHWS016 DFHWS017 DFHWS018 DFHWS019
    DFHWS020 DFHWS021 DFHWS022 DFHWS023 DFHWS024 DFHWS025 DFHWS026
    DFHWS027 DFHWS028 DFHWS029 DFHWS030 DFHWS031 DFHWS032 DFHWS033
    DFHWS034 DFHWS035 DFHWS036 DFHWS037 DFHWS038 DFHWS039 DFHWS040
    DFHWS041 DFHWS042 DFHWS043 DFHWS044 DFHWS045 DFHWS046 DFHWS047
    DFHWS048 DFHWS049 DFHWS050 DFHWS051 DFHWS052 DFHWS053 DFHWS054
    DFHWS055 DFHWS056 DFHWS057 DFHWS058 DFHWS059 DFHWS060 DFHWS061
    DFHWS062 DFHWS063 DFHWS064 DFHWS065 DFHWS066 DFHWS067 DFHWS068
    DFHWS069 DFHWS070 DFHWS071 DFHWS072 DFHWS073 DFHWS074 DFHWS075
    DFHWS076 DFHWS077 DFHWS078 DFHWS079 DFHWS080 DFHWS081 DFHWS082
    DFHWS083 DFHWS084 DFHWS085 DFHWS086 DFHWS087 DFHWS088 DFHWS089
    DFHWS090 DFHWS091 DFHWS092 DFHWS093 DFHWS094
    

Fix information

  • Fixed component name

    CICSTS 3.1 Z/OS

  • Fixed component ID

    5655M1500

Applicable component levels

  • R40W PSY UK25372

       UP07/05/25 P F705

Fix is available

  • Select the PTF appropriate for your component level. You will be required to sign in. Distribution on physical media is not available in all countries.

[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGMGV","label":"CICS Transaction Server"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.1","Edition":"","Line of Business":{"code":"LOB35","label":"Mainframe SW"}},{"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Product":{"code":"SG19M","label":"APARs - z\/OS environment"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"3.1","Edition":"","Line of Business":{"code":"","label":""}}]

Document Information

Modified date:
01 June 2007