Rampart
  1. Rampart
  2. RAMPART-277

Rampart ignores token inclusion settings when using the asymmetric security binding

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.5
    • Fix Version/s: 1.5.1
    • Component/s: rampart-core
    • Labels:
      None

      Description

      Consider the abbhreviated policy below. It defines x509 tokens for the initiator and recipient: the initiator's token must be included in all messages from the initiator to the recepient, and the recipient's token must not be included at all.

      <wsp:Policy wsu:Id="servicePolicy">
        <sp:AsymmetricBinding>
          <sp:InitiatorToken>
            <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/AlwaysToRecipient"/>
          </sp:InitiatorToken>
          <sp:RecipientToken>
            <sp:X509Token sp:IncludeToken="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy/IncludeToken/Never"/>
          </sp:RecipientToken>
      </wsp:Policy>
      

      When Rampart is used as both the client and server for a web service using this policy, the client's certificate is correctly included as a binary security token in the request. However, the response message from the server to the client also includes this as a binary security token when reference which token was used to encrypt the encrypted symmetric key. This is incorrect as the token was marked as only to be included in messages from the initiator to the recipient.

      The problem is that the asymmetric security binding uses RampartUtil.setKeyIdentifierType() to determine what type of key references should be used. As present it will always include a binary security token unless the token inclusion parameter is set to never - i.e. it does not take into account whether we are the initiator or not, and so doesn't handle the alwaysToInitiator and alwaysToRecipient inclusion modes.

      1. RAMPART-277.patch
        5 kB
        Thilina Buddhika
      2. tokenReference.patch
        4 kB
        Dave Bryant

        Activity

        Hide
        Dave Bryant added a comment -

        Attaching a patch that determines what type of token reference using the token inclusion parameter, and knowledge of whether we are the initiator or recipient of the message.

        Show
        Dave Bryant added a comment - Attaching a patch that determines what type of token reference using the token inclusion parameter, and knowledge of whether we are the initiator or recipient of the message.
        Hide
        Thilina Buddhika added a comment -

        Hi Dave,

        I found some conflicts when applying this patch to current trunk. So I manually merged the changes and recreated the patch(RAMPART-277) out of your patch.

        I verified the patch and it solves the aforementioned issue.

        Thanks,
        Thilina

        Show
        Thilina Buddhika added a comment - Hi Dave, I found some conflicts when applying this patch to current trunk. So I manually merged the changes and recreated the patch( RAMPART-277 ) out of your patch. I verified the patch and it solves the aforementioned issue. Thanks, Thilina
        Hide
        S.Uthaiyashankar added a comment -

        Applied the patch in revision 1051777.

        Thank you Dave and Thilina for the patch.

        Show
        S.Uthaiyashankar added a comment - Applied the patch in revision 1051777. Thank you Dave and Thilina for the patch.

          People

          • Assignee:
            S.Uthaiyashankar
            Reporter:
            Dave Bryant
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development