CXF
  1. CXF
  2. CXF-1636

Have WSS4J in/out interceptors require nonces and timestamps when using UsernameTokens?

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.4.7, 2.5.3, 2.6
    • Component/s: WS-* Components
    • Labels:
      None

      Description

      Our WSS4J In/Out interceptors[1][2] do not appear to be requiring UsernameTokens to have timestamps and nonces. From [3], lines 176-190, these are used to prevent replay attacks (i.e., an intruder just copying the entire soap header, encrypted or not, and reusing it for another request).

      To fix this problem, this blog sample[4] created a separate interceptor that will reject any UsernameToken that does not have both a timestamp and a nonce. Perhaps we should update our WSS4J in/out interceptors to require both of these, so external users don't need to do this.

      A question though-I'm unsure where the nonce-checking is being done-our WSS4J interceptors seem to be ignoring them, but perhaps WSS4J is doing the checking/validation that they are not being used more then once.

      Glen

      [1] http://tinyurl.com/4cgg9b
      [2] http://tinyurl.com/48h6an
      [3] http://tinyurl.com/65n78j
      [4] http://depressedprogrammer.wordpress.com/2007/07/31/cxf-ws-security-using-jsr-181-interceptor-annotations-xfire-migration/

      1. cxf-1636.patch
        27 kB
        Colm O hEigeartaigh

        Activity

        Hide
        Colm O hEigeartaigh added a comment -

        > To fix this problem, this blog sample[4] created a separate interceptor that will reject any UsernameToken that does not have both a timestamp and a > nonce. Perhaps we should update our WSS4J in/out interceptors to require both of these, so external users don't need to do this.

        -1 to this. Both the nonce and created elements are optional as per the specification (albeit "recommended"), I don't think we should be forcing this behaviour on the average user.

        > but perhaps WSS4J is doing the checking/validation that they are not being used more then once.

        Unfortunately, nonce caching isn't implemented (yet) in WSS4J. Feel free to raise an enhancement request in the WSS4J JIRA tho

        Show
        Colm O hEigeartaigh added a comment - > To fix this problem, this blog sample [4] created a separate interceptor that will reject any UsernameToken that does not have both a timestamp and a > nonce. Perhaps we should update our WSS4J in/out interceptors to require both of these, so external users don't need to do this. -1 to this. Both the nonce and created elements are optional as per the specification (albeit "recommended"), I don't think we should be forcing this behaviour on the average user. > but perhaps WSS4J is doing the checking/validation that they are not being used more then once. Unfortunately, nonce caching isn't implemented (yet) in WSS4J. Feel free to raise an enhancement request in the WSS4J JIRA tho
        Hide
        Glen Mazza added a comment -

        >> but perhaps WSS4J is doing the checking/validation that they are not being used more then once.
        >Unfortunately, nonce caching isn't implemented (yet) in WSS4J. Feel free to raise an enhancement request in the WSS4J JIRA tho

        Hmm. Is nonce caching the responsibility of WSS4J or that of the web services stack (Axis, CXF, etc.) using it?

        Show
        Glen Mazza added a comment - >> but perhaps WSS4J is doing the checking/validation that they are not being used more then once. >Unfortunately, nonce caching isn't implemented (yet) in WSS4J. Feel free to raise an enhancement request in the WSS4J JIRA tho Hmm. Is nonce caching the responsibility of WSS4J or that of the web services stack (Axis, CXF, etc.) using it?
        Hide
        Glen Mazza added a comment -

        > -1 to this. Both the nonce and created elements are optional as per the specification (albeit "recommended"),
        > I don't think we should be forcing this behaviour on the average user.

        Colm, are you a CXF committer? I did not find you on the list.

        Show
        Glen Mazza added a comment - > -1 to this. Both the nonce and created elements are optional as per the specification (albeit "recommended"), > I don't think we should be forcing this behaviour on the average user. Colm, are you a CXF committer? I did not find you on the list.
        Hide
        Colm O hEigeartaigh added a comment -

        > Hmm. Is nonce caching the responsibility of WSS4J or that of the web services stack (Axis, CXF, etc.) using it?

        Good point. I guess the implementation should be done in CXF, with some "common" code put into the WSHandler class in WSS4J.

        > Colm, are you a CXF committer?

        No.

        Show
        Colm O hEigeartaigh added a comment - > Hmm. Is nonce caching the responsibility of WSS4J or that of the web services stack (Axis, CXF, etc.) using it? Good point. I guess the implementation should be done in CXF, with some "common" code put into the WSHandler class in WSS4J. > Colm, are you a CXF committer? No.
        Hide
        Colm O hEigeartaigh added a comment -

        See attached for a proposed patch for this issue.

        Basically, WSS4J 1.6.5 defines a ReplayCache interface, and ships with a HashSet based implementation. This interface is used to cache UsernameToken nonces, and also a combination of Timestamp Created Strings with message Signatures. No caching is done by default in WSS4J.

        I've decided to use a ReplayCache implementation based on EhCache in CXF. It is simple to use and Apache licensed. It uses a default configuration which holds 50000 Elements in memory for 60 minutes, and will overflow to disk. This can be changed by specifying another configuration file. Even though the eh-cache is specified as a compile time dependency in the security module, it can be excluded and CXF falls back to using the HashSet implementation in WSS4J.

        There are four configuration values available:
        a) A boolean switch to cache nonces. By default, it's true for a recipient, and false for an initiator. If set to false, no caching is done, if set to true, caching is enabled for both recipients and initiators.
        b) Ditto for caching Timestamp Created Strings.
        c) A tag that is used to store/retrieve a ReplayCache instance for nonces.
        d) Ditto for Timestamps.

        What I am thinking of doing is to disable replay caching altogether for 2.5.x and 2.4.x, for backwards compatibility, but to merge this patch so that someone can enable it if they want. On trunk I will preserve the behaviour defined above. The user could always disable caching, if they didn't want to use ehcache, or plug in their own ReplayCache implementation based on something else.

        Thoughts?

        Colm.

        Show
        Colm O hEigeartaigh added a comment - See attached for a proposed patch for this issue. Basically, WSS4J 1.6.5 defines a ReplayCache interface, and ships with a HashSet based implementation. This interface is used to cache UsernameToken nonces, and also a combination of Timestamp Created Strings with message Signatures. No caching is done by default in WSS4J. I've decided to use a ReplayCache implementation based on EhCache in CXF. It is simple to use and Apache licensed. It uses a default configuration which holds 50000 Elements in memory for 60 minutes, and will overflow to disk. This can be changed by specifying another configuration file. Even though the eh-cache is specified as a compile time dependency in the security module, it can be excluded and CXF falls back to using the HashSet implementation in WSS4J. There are four configuration values available: a) A boolean switch to cache nonces. By default, it's true for a recipient, and false for an initiator. If set to false, no caching is done, if set to true, caching is enabled for both recipients and initiators. b) Ditto for caching Timestamp Created Strings. c) A tag that is used to store/retrieve a ReplayCache instance for nonces. d) Ditto for Timestamps. What I am thinking of doing is to disable replay caching altogether for 2.5.x and 2.4.x, for backwards compatibility, but to merge this patch so that someone can enable it if they want. On trunk I will preserve the behaviour defined above. The user could always disable caching, if they didn't want to use ehcache, or plug in their own ReplayCache implementation based on something else. Thoughts? Colm.
        Hide
        Daniel Kulp added a comment -

        Two comments:

        1) On 2.5.x/2.4.x, I'd also switch to <scope>provided</scope><optional>true</optional> so users won't have that dependency unexpectedly added.

        2) Is the file in src/main/resources/ehcache.xml normal? That would go into the root of the ws-security jar which seems "strange" and problematic. Is this another log4j.properties type thing that the first jar on the classpath "wins"? Is there a better place to put that? (I'm not familiar enough with ehcache)

        Other than that, looks good to me.

        Show
        Daniel Kulp added a comment - Two comments: 1) On 2.5.x/2.4.x, I'd also switch to <scope>provided</scope><optional>true</optional> so users won't have that dependency unexpectedly added. 2) Is the file in src/main/resources/ehcache.xml normal? That would go into the root of the ws-security jar which seems "strange" and problematic. Is this another log4j.properties type thing that the first jar on the classpath "wins"? Is there a better place to put that? (I'm not familiar enough with ehcache) Other than that, looks good to me.
        Hide
        Glen Mazza added a comment -

        Colm, one concern I have (but may be misunderstanding) is the caching setting: "By default, it's true for a recipient, and false for an initiator. If set to false, no caching is done, if set to true, caching is enabled for both recipients and initiators." There is still a way to explicitly set that value that causes it to act as the default, right? I.e., we're not having a situation where if you omit a value, condition "A" exists, set it to "true', condition "B", and false, condition "C"--there is a way to programatically set condition "A" other than by omitting the value, correct?

        Also, is there a use case for caching on the client side?

        Show
        Glen Mazza added a comment - Colm, one concern I have (but may be misunderstanding) is the caching setting: "By default, it's true for a recipient, and false for an initiator. If set to false, no caching is done, if set to true, caching is enabled for both recipients and initiators." There is still a way to explicitly set that value that causes it to act as the default, right? I.e., we're not having a situation where if you omit a value, condition "A" exists, set it to "true', condition "B", and false, condition "C"--there is a way to programatically set condition "A" other than by omitting the value, correct? Also, is there a use case for caching on the client side?
        Hide
        Glen Mazza added a comment -

        quote: "What I am thinking of doing is to disable replay caching altogether for 2.5.x and 2.4.x, for backwards compatibility, but to merge this patch so that someone can enable it if they want."

        As not caching can be considered a security problem (and hence more important than backward compatibility), if you wish I think it would be acceptable to activate it by default with a note in the release notes of this change for 2.4/2.5. (If it breaks anything users can subsequently disable it.) This is not a regular security hole because for years now we've already documented that we haven't implemented nonce support yet (first paragraph under UsernameToken here: https://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-ConfiguringWSSecurityActions).

        Show
        Glen Mazza added a comment - quote: "What I am thinking of doing is to disable replay caching altogether for 2.5.x and 2.4.x, for backwards compatibility, but to merge this patch so that someone can enable it if they want." As not caching can be considered a security problem (and hence more important than backward compatibility), if you wish I think it would be acceptable to activate it by default with a note in the release notes of this change for 2.4/2.5. (If it breaks anything users can subsequently disable it.) This is not a regular security hole because for years now we've already documented that we haven't implemented nonce support yet (first paragraph under UsernameToken here: https://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-ConfiguringWSSecurityActions ).
        Hide
        Colm O hEigeartaigh added a comment - - edited

        Thanks for the comments!

        > On 2.5.x/2.4.x, I'd also switch to <scope>provided</scope><optional>true</optional> so users won't have
        > that dependency unexpectedly added.

        Agreed.

        > Is the file in src/main/resources/ehcache.xml normal?

        According to http://www.ehcache.org/documentation/user-guide/configuration:

        "Ehcache looks for a file called ehcache.xml in the top level of the classpath. Failing that it looks for ehcache-failsafe.xml in the classpath. ehcache-failsafe.xml is packaged in the Ehcache jar and should always be found."

        What I could do is to rename that file to ehcache-failsafe.xml. The problem with this though is that a warning will be logged for anything downstream from the security module that doesn't explicitly specify an ehcache.xml file. Is this acceptable? I could update all systests + demos to include the file.

        > There is still a way to explicitly set that value that causes it to act as the default, right?

        Good point Glen. I could change the boolean properties so that in addition to true/false you can specify "RecipientOnly"?

        > Also, is there a use case for caching on the client side?

        Probably not a common use-case for caching UsernameToken nonces - that's why I want to disable it by default. It can be enabled by setting the property to true. I don't see a use-case for providing an "InitiatorOnly" configuration option.

        > if you wish I think it would be acceptable to activate it by default with a note in the release notes of
        > this change for 2.4/2.5.

        I'm a bit nervous about this suggestion, as it's introducing a new dependency and changed behaviour on a minor upgrade.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - - edited Thanks for the comments! > On 2.5.x/2.4.x, I'd also switch to <scope>provided</scope><optional>true</optional> so users won't have > that dependency unexpectedly added. Agreed. > Is the file in src/main/resources/ehcache.xml normal? According to http://www.ehcache.org/documentation/user-guide/configuration: "Ehcache looks for a file called ehcache.xml in the top level of the classpath. Failing that it looks for ehcache-failsafe.xml in the classpath. ehcache-failsafe.xml is packaged in the Ehcache jar and should always be found." What I could do is to rename that file to ehcache-failsafe.xml. The problem with this though is that a warning will be logged for anything downstream from the security module that doesn't explicitly specify an ehcache.xml file. Is this acceptable? I could update all systests + demos to include the file. > There is still a way to explicitly set that value that causes it to act as the default, right? Good point Glen. I could change the boolean properties so that in addition to true/false you can specify "RecipientOnly"? > Also, is there a use case for caching on the client side? Probably not a common use-case for caching UsernameToken nonces - that's why I want to disable it by default. It can be enabled by setting the property to true. I don't see a use-case for providing an "InitiatorOnly" configuration option. > if you wish I think it would be acceptable to activate it by default with a note in the release notes of > this change for 2.4/2.5. I'm a bit nervous about this suggestion, as it's introducing a new dependency and changed behaviour on a minor upgrade. Colm.
        Hide
        Glen Mazza added a comment -

        >> There is still a way to explicitly set that value that causes it to act as the default, right?

        >Good point Glen. I could change the boolean properties so that in addition to true/false you can specify "RecipientOnly"?

        That would be fine, as long as there are three explicit settings, whatever they are called.

        But this raises another question: Why is there just one setting in one config file that controls both the client and the service caching? I would think the client would have its own configuration file (say cxf.xml) where it dictates whether or not it wants its nonces/timestamps cached client-side (a boolean setting defaulting to "false"), and the service configuration file (say cxf-servlet.xml) would have the same configuration option (same boolean except default to true, at least for CXF 2.6->). It seems strange to have the service-side config file determine whether or not the client will be caching its nonces/timestamps on its own end (that's what the client config file is for), and in the normally separated architecture between the client and web service provider, I can't see how that would work.

        Actually, I may have misunderstood your design here. Is it the case that caching is indeed configured independently in two separate XML file locations, one for the client and one for the service, with the same setting except that it's false by default for the former and true by default for the latter (CXF 2.6 onwards)? If that's the case, you won't need a RecipientOnly setting as that would just confuse things, i.e., give the false impression that the server-side config file somehow controls caching on the client-side as well. In that case, true/false values alone in both files would work.

        Show
        Glen Mazza added a comment - >> There is still a way to explicitly set that value that causes it to act as the default, right? >Good point Glen. I could change the boolean properties so that in addition to true/false you can specify "RecipientOnly"? That would be fine, as long as there are three explicit settings, whatever they are called. But this raises another question: Why is there just one setting in one config file that controls both the client and the service caching? I would think the client would have its own configuration file (say cxf.xml) where it dictates whether or not it wants its nonces/timestamps cached client-side (a boolean setting defaulting to "false"), and the service configuration file (say cxf-servlet.xml) would have the same configuration option (same boolean except default to true, at least for CXF 2.6->). It seems strange to have the service-side config file determine whether or not the client will be caching its nonces/timestamps on its own end (that's what the client config file is for), and in the normally separated architecture between the client and web service provider, I can't see how that would work. Actually, I may have misunderstood your design here. Is it the case that caching is indeed configured independently in two separate XML file locations, one for the client and one for the service, with the same setting except that it's false by default for the former and true by default for the latter (CXF 2.6 onwards)? If that's the case, you won't need a RecipientOnly setting as that would just confuse things, i.e., give the false impression that the server-side config file somehow controls caching on the client-side as well. In that case, true/false values alone in both files would work.
        Hide
        Colm O hEigeartaigh added a comment -

        > Actually, I may have misunderstood your design here. Is it the case that caching is indeed configured
        > independently in two separate XML file locations, one for the client and one for the service, with the same
        > setting except that it's false by default for the former and true by default for the latter (CXF 2.6
        > onwards)?

        Yep correct.

        > If that's the case, you won't need a RecipientOnly setting as that would just confuse things, i.e., give
        > the false impression that the server-side config file somehow controls caching on the client-side as well.
        > In that case, true/false values alone in both files would work.

        Ok, so you're happy with the original design? If not specified, it's false for client and true for recipient. Setting it to false disables it altogether, setting it to true enables it for both message initiator and recipient.

        Colm.

        Show
        Colm O hEigeartaigh added a comment - > Actually, I may have misunderstood your design here. Is it the case that caching is indeed configured > independently in two separate XML file locations, one for the client and one for the service, with the same > setting except that it's false by default for the former and true by default for the latter (CXF 2.6 > onwards)? Yep correct. > If that's the case, you won't need a RecipientOnly setting as that would just confuse things, i.e., give > the false impression that the server-side config file somehow controls caching on the client-side as well. > In that case, true/false values alone in both files would work. Ok, so you're happy with the original design? If not specified, it's false for client and true for recipient. Setting it to false disables it altogether, setting it to true enables it for both message initiator and recipient. Colm.
        Hide
        Glen Mazza added a comment -

        > Ok, so you're happy with the original design? If not specified, it's false for client and true for recipient. Setting it to false disables it altogether, setting it to true enables it for both message initiator and recipient.

        Yes, sounds good, go to town.

        Show
        Glen Mazza added a comment - > Ok, so you're happy with the original design? If not specified, it's false for client and true for recipient. Setting it to false disables it altogether, setting it to true enables it for both message initiator and recipient. Yes, sounds good, go to town.
        Hide
        Daniel Kulp added a comment -

        Keep in mind that a Server can also be a client. For example, if a request comes into a service, but you have that service set to validate (or transform) a SAML token via and STS, that service will act as a client to talk to the STS. Both would likely be in the same bus and possibly on the same config settings. Not a huge deal though. The defaults are good.

        Colm, that page states: "CacheManager default constructor or factory method is called" Is there a way to setup ehcache using a non default constructor or similar where we can specify the ehcache.xml file to use? Maybe via a configuration property?

        Show
        Daniel Kulp added a comment - Keep in mind that a Server can also be a client. For example, if a request comes into a service, but you have that service set to validate (or transform) a SAML token via and STS, that service will act as a client to talk to the STS. Both would likely be in the same bus and possibly on the same config settings. Not a huge deal though. The defaults are good. Colm, that page states: "CacheManager default constructor or factory method is called" Is there a way to setup ehcache using a non default constructor or similar where we can specify the ehcache.xml file to use? Maybe via a configuration property?
        Hide
        Colm O hEigeartaigh added a comment -

        Yep:

        http://ehcache.org/apidocs/net/sf/ehcache/CacheManager.html#create%28java.net.URL%29

        I could add a new property to SecurityConstants to specify the ehcache configuration file. If it is not specified I could default to using a cxf-ehcache.xml in the rt-security jar?

        Colm.

        Show
        Colm O hEigeartaigh added a comment - Yep: http://ehcache.org/apidocs/net/sf/ehcache/CacheManager.html#create%28java.net.URL%29 I could add a new property to SecurityConstants to specify the ehcache configuration file. If it is not specified I could default to using a cxf-ehcache.xml in the rt-security jar? Colm.
        Hide
        Daniel Kulp added a comment -


        Yea. I think that's better. I hate having behavior change just depending on where on the classpath a jar is.

        Show
        Daniel Kulp added a comment - Yea. I think that's better. I hate having behavior change just depending on where on the classpath a jar is.

          People

          • Assignee:
            Colm O hEigeartaigh
            Reporter:
            Glen Mazza
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development