Rampart
  1. Rampart
  2. RAMPART-357

Timestamp verification handled at two locations in different ways

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Currently, when verifying timestamp, 'Expired' is verified in WSS4J level if timestampStrict enabled.
      'Created' is verified in PolicyBasedResultsValidator.

      timestampMaxSkew is taken into consideration only when verifying 'Created' in timestamp inside PolicyBasedResultsValidator.

      IMO, both 'Expired' and 'Created' should be verified in PolicyBasedResultsValidator in a consistent way, taking timestampMaxSkew into consideration in both the occasions.

      Hence the proposed solution is like below:
      -Disable timestampStrict in WSConfig by default through Rampart.
      -Verify both 'Expired' and 'Created' in PolicyBasedResultsValidator.
      -Allow to enable verification at WSS4J level through rampart config, if someone needs it.

      1. rampart_patch_trunk_v2.patch
        11 kB
        Hasini Gunasinghe
      2. rampart_357.patch
        9 kB
        Hasini Gunasinghe
      3. rampart_357_trunk.patch
        11 kB
        Amila Jayasekara

        Activity

        Hide
        Hasini Gunasinghe added a comment -

        Please verify and apply from modules/rampart-core level as appropriate.

        Show
        Hasini Gunasinghe added a comment - Please verify and apply from modules/rampart-core level as appropriate.
        Hide
        Hasini Gunasinghe added a comment -

        FYI..

        This was a real user requirement where he has written a custom PolicyValidator and wanted to handle time stamp verification in a consistent manner in that custom PolicyValidator.

        When future messages are sent, the verification in his PolicyValidator is hit. But when expired messages are sent, exception thrown in WSS4J level and there was no way to get the control of error handling to custom PolicyValidator.

        Hence the solution in this patch is proposed.

        Thanks,
        Hasini.

        Show
        Hasini Gunasinghe added a comment - FYI.. This was a real user requirement where he has written a custom PolicyValidator and wanted to handle time stamp verification in a consistent manner in that custom PolicyValidator. When future messages are sent, the verification in his PolicyValidator is hit. But when expired messages are sent, exception thrown in WSS4J level and there was no way to get the control of error handling to custom PolicyValidator. Hence the solution in this patch is proposed. Thanks, Hasini.
        Hide
        Amila Jayasekara added a comment -

        Hi Hasini,

        I slightly modified your patch so that it suits to current Rampart Trunk (after wss4j migration). Please review this.

        Thanks
        AmilaJ

        Show
        Amila Jayasekara added a comment - Hi Hasini, I slightly modified your patch so that it suits to current Rampart Trunk (after wss4j migration). Please review this. Thanks AmilaJ
        Hide
        Hasini Gunasinghe added a comment -

        Hi AmilaJ,

        Thanks for modifying it to suit the latest trunk. I did some minor changes and attaching the updated version.

        Thanks,
        Hasini.

        Show
        Hasini Gunasinghe added a comment - Hi AmilaJ, Thanks for modifying it to suit the latest trunk. I did some minor changes and attaching the updated version. Thanks, Hasini.
        Hide
        Amila Jayasekara added a comment -

        Patch is applied to trunk in revision 1243894. Therefore resolving this issue.

        Thanks Hasini for the contribution.

        Note: When applying this to 1.6 branch we can directly use rampart_357.patch file.

        Thanks
        AmilaJ

        Show
        Amila Jayasekara added a comment - Patch is applied to trunk in revision 1243894. Therefore resolving this issue. Thanks Hasini for the contribution. Note: When applying this to 1.6 branch we can directly use rampart_357.patch file. Thanks AmilaJ
        Hide
        Hudson added a comment -

        Integrated in Rampart #758 (See https://builds.apache.org/job/Rampart/758/)
        Fixing issue RAMPART-357. Applying the patch provided (Revision 1243894)

        Result = SUCCESS
        amilaj :
        Files :

        • /axis/axis2/java/rampart/trunk/modules/rampart-core/src/main/java/org/apache/rampart/PolicyBasedResultsValidator.java
        • /axis/axis2/java/rampart/trunk/modules/rampart-core/src/main/java/org/apache/rampart/RampartMessageData.java
        • /axis/axis2/java/rampart/trunk/modules/rampart-core/src/main/java/org/apache/rampart/policy/builders/RampartConfigBuilder.java
        • /axis/axis2/java/rampart/trunk/modules/rampart-core/src/main/java/org/apache/rampart/policy/model/RampartConfig.java
        Show
        Hudson added a comment - Integrated in Rampart #758 (See https://builds.apache.org/job/Rampart/758/ ) Fixing issue RAMPART-357 . Applying the patch provided (Revision 1243894) Result = SUCCESS amilaj : Files : /axis/axis2/java/rampart/trunk/modules/rampart-core/src/main/java/org/apache/rampart/PolicyBasedResultsValidator.java /axis/axis2/java/rampart/trunk/modules/rampart-core/src/main/java/org/apache/rampart/RampartMessageData.java /axis/axis2/java/rampart/trunk/modules/rampart-core/src/main/java/org/apache/rampart/policy/builders/RampartConfigBuilder.java /axis/axis2/java/rampart/trunk/modules/rampart-core/src/main/java/org/apache/rampart/policy/model/RampartConfig.java
        Hide
        Hasini Gunasinghe added a comment -

        Thanks AmilaJ for applying the patch.
        I have written a small KB around this : http://hasini-gunasinghe.blogspot.com/2012/02/timestamp-in-ws-security-to-mitigate.html

        Show
        Hasini Gunasinghe added a comment - Thanks AmilaJ for applying the patch. I have written a small KB around this : http://hasini-gunasinghe.blogspot.com/2012/02/timestamp-in-ws-security-to-mitigate.html

          People

          • Assignee:
            Unassigned
            Reporter:
            Hasini Gunasinghe
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development