Rampart
  1. Rampart
  2. RAMPART-90

Rampart must respond using the applicable WS-Policy even when returning a fault

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.4
    • Component/s: rampart-core
    • Labels:
      None

      Description

      Ref: http://mail-archives.apache.org/mod_mbox/ws-synapse-dev/200709.mbox/%3c12889206.post@talk.nabble.com%3e

      When the CallbackHandler fails, the response to a timestamped request is inconsistent:

      <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
      <soapenv:Body>
      <soapenv:Fault>
      <faultcode>soapenv:Server</faultcode>
      <faultstring>The security token could not be authenticated or
      authorized</faultstring>
      <detail/>
      </soapenv:Fault>
      </soapenv:Body>
      </soapenv:Envelope>

        Activity

        Asankha C. Perera created issue -
        Hide
        Nandana Mihindukulasooriya added a comment -

        This is because rampart currently doesn't secure the messages coming through OutFaultFlow and InFaultFlow. Currently axis2 doesn't have a security phase in the OutFaultFlow. Security Phase has to introduced in to <phaseOrder type="OutFaultFlow">. Rampart handlers have to registered in the InFaultFlow and OutFaultFlow.

        Proposed Fix :

        Service level errors will be secured using the effective policy of the message ( in the OutFaultFlow ) and will be validated for effective policy in the ( in the InFaultFlow ).
        Protocol errors ( errors while processing the security header ) will not be secured using the security policy and not validated in the client side.

        How security is validated in the InFaultFlow

        Fault messages will be checked for security fault codes ( Errors while processing security header should be reported with correct fault codes as defined in the WSS 1.0 sections 6, Error Handling , we currently doesn't report security errors using these fault codes).
        If a security fault code is not found in the fault message, it is assumed that it is a service level error and validated for effective service policy.

        Show
        Nandana Mihindukulasooriya added a comment - This is because rampart currently doesn't secure the messages coming through OutFaultFlow and InFaultFlow. Currently axis2 doesn't have a security phase in the OutFaultFlow. Security Phase has to introduced in to <phaseOrder type="OutFaultFlow">. Rampart handlers have to registered in the InFaultFlow and OutFaultFlow. Proposed Fix : Service level errors will be secured using the effective policy of the message ( in the OutFaultFlow ) and will be validated for effective policy in the ( in the InFaultFlow ). Protocol errors ( errors while processing the security header ) will not be secured using the security policy and not validated in the client side. How security is validated in the InFaultFlow Fault messages will be checked for security fault codes ( Errors while processing security header should be reported with correct fault codes as defined in the WSS 1.0 sections 6, Error Handling , we currently doesn't report security errors using these fault codes). If a security fault code is not found in the fault message, it is assumed that it is a service level error and validated for effective service policy.
        Nandana Mihindukulasooriya made changes -
        Field Original Value New Value
        Assignee Nandana Mihindukulasooriya [ nandana.cse ]
        Hide
        Nandana Mihindukulasooriya added a comment -

        Fixed in revision 610736. We have to add the security phase to in the axis2.xml to use Rampart from now on. Will include a note about this in the READ_ME file.

        Show
        Nandana Mihindukulasooriya added a comment - Fixed in revision 610736. We have to add the security phase to in the axis2.xml to use Rampart from now on. Will include a note about this in the READ_ME file.
        Nandana Mihindukulasooriya made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Nandana Mihindukulasooriya added a comment -

        Set Fix version to 1.4.

        Show
        Nandana Mihindukulasooriya added a comment - Set Fix version to 1.4.
        Nandana Mihindukulasooriya made changes -
        Fix Version/s 1.4 [ 12313141 ]

          People

          • Assignee:
            Nandana Mihindukulasooriya
            Reporter:
            Asankha C. Perera
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development