Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0 M2
    • Fix Version/s: 1.0 M3
    • Component/s: Security
    • Labels:
      None
    • Environment:
      windows xp, tomcat

      Description

      I am having a problem getting an npe as referenced in another thread (which was getting really long).
      it looks like it happens in DefaulttimestampValidator.java, at line 41

      Date expired = parseDate(utcRequest.getExpired());

      while trying to verifyInboundMessage.

      This happens when my security policy inbound is:

      <xwss:SecurityConfiguration dumpMessages="true" xmlns:xwss="http://java.sun.com/xml/ns/xwss/config">
      <xwss:Timestamp timeout="120"/>
      <xwss:RequireUsernameToken passwordDigestRequired="false" nonceRequired="true"/>
      </xwss:SecurityConfiguration>

      and outbound is

      <xwss:SecurityConfiguration dumpMessages="true" xmlns:xwss="http://java.sun.com/xml/ns/xwss/config">
      <xwss:Timestamp timeout="120"/>
      <xwss:UsernameToken digestPassword="false" useNonce="true"/>
      </xwss:SecurityConfiguration>If I change useNonce to false, it works.

      I can see in the console that the timestamp for nonce only has created, not expired

      <wsse:UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="XWSSGID-1159216970175594217203">
      <wsse:Username>Bert</wsse:Username>
      <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">****</wsse:Password>
      <wsse:Nonce EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0#Base64Binary">lNS7NMI3OJWQ8WtjNiB0AuFS</wsse:Nonce>
      <wsu:Created>2006-09-25T20:42:50Z</wsu:Created>
      </wsse:UsernameToken>

      Jira opened as recommended by Arjen.
      Thanks.

        Activity

        Hide
        farrellr rich farrell added a comment -

        Since the expired attribute for the token is optional, is there any chance
        you can do in a near term nightly build to not throw an exception if it is not there. I realize that there might be more to do (to put the expired information if it should be there) but it would help me make progress in testing security other than plain text and password, and seems like it should work that way anyway.
        Thanks for your help.

        Also, I think this should have been under security rathre than core, but I don't think I can move it once I've put it here.

        Show
        farrellr rich farrell added a comment - Since the expired attribute for the token is optional, is there any chance you can do in a near term nightly build to not throw an exception if it is not there. I realize that there might be more to do (to put the expired information if it should be there) but it would help me make progress in testing security other than plain text and password, and seems like it should work that way anyway. Thanks for your help. Also, I think this should have been under security rathre than core, but I don't think I can move it once I've put it here.

          People

          • Assignee:
            arjen.poutsma Arjen Poutsma
            Reporter:
            farrellr rich farrell
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: