Uploaded image for project: 'CXF'
  1. CXF
  2. CXF-5975

SecurityToken::isExpired: add clock skew option

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.7.10, 2.7.12
    • Fix Version/s: 2.7.13, 3.0.2
    • Component/s: None
    • Labels:
      None
    • Estimated Complexity:
      Unknown

      Description

      We notice race conditions with some of our clients when CXF verifies if SecurityTokens cached locally are still valid or expired. One reason could be clock desynchronization, another reason is that while the token was still valid at the moment of request construction, it isn't when the SOAP message arrives on the server (1s difference suffices).

      Is it possible to add a clock skew option to org.apache.cxf.ws.security.tokenstore.SecurityToken.isExpired() or org.apache.cxf.ws.security.trust.STSClient to compensate clock differences between client and server.

      Our current workaround is to subclass the STSClient class.

      public class STSClockSkewClient extends STSClient {
      
          private static final int CLOCK_SKEW = 15 * 1000 /* 15s */;
      
          public STSClockSkewClient(Bus b) {
              super(b);
          }
      
          @Override
          protected SecurityToken createSecurityToken(Element el, byte[] requestorEntropy) throws WSSecurityException {
              SecurityToken securityToken = super.createSecurityToken(el, requestorEntropy);
              Date expires = securityToken.getExpires();
              if (expires != null) {
                  securityToken.setExpires(new Date(expires.getTime() - CLOCK_SKEW));
              }
              return securityToken;
          }
      
      }
      

      A possible workaround is to handle this in the STS and set Lifetime>Expires in the RSTR response not equal but some time before the end of the SAML token, but most of the times the STS clients have no control over the STS service and cannot ask the service provider to make this change.

        Attachments

          Activity

            People

            • Assignee:
              coheigea Colm O hEigeartaigh
              Reporter:
              wsalembi Willem Salembier
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: