wsit
  1. wsit
  2. WSIT-1640

Metro modifies SAML assertion before appending it to ActAs element in RequestSecurityToken message

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2
    • Fix Version/s: None
    • Component/s: trust
    • Labels:
      None
    • Environment:

      Latest Metro promoted build 2.1 b25 running on Glassfish 3.1

      Description

      AD FS 2.0 STS
      .NET service client
      Java Metro service (TierOneService)
      Java Metro service (TierTwoService)
      Glassfish 3.1 with latest Metro promoted b25

      SOAP 1.2 across the board

      Currently the client can get a token, call the TierOneService and the TierOneService can read the token and create an RST with ActAs. When metro adds the token to the ActAs element in the RST the assertion is modified which then breaks the digest validation of the canonicalized assertion.

      I do the following to repro:

      Make a call from my client to reproduce the scenario
      Collect the full RST that AD FS 2.0 receives on the wire
      Collect the value that AD FS 2.0 does digest validation on
      Verified that on .NET that this value fails digest validation
      Verified that on Java that this value fails digest validation

      So in my test both Java and .NET agree that the SHA1 digest of the attached canonicalized value is:
      "HKGhKOF0Eq8T2ZBYi27bY3QxNtU="
      While it should be:
      "YjnmL0e/NNthHQTVcr4DZuFbfXA="

      Knowing this I looked more at canonicalization. I grabbed the full assertion from the RST received on the wire at AD FS 2.0 (full-actas-rst-received-on-wire-on-adfs2.xml). I then removed the signature element (assertion-received-by-adfs2-pre-canonicalization.xml). I then canonicalized the contents of this file and computed a SHA1 hash on both platforms. Both yield:
      "HKGhKOF0Eq8T2ZBYi27bY3QxNtU="
      Again, while it should be:
      "YjnmL0e/NNthHQTVcr4DZuFbfXA="

      After discussing this with Jiandong on email he asserted that:
      "Ok. Look like the SAML assertion is changed (white space removed) when attached to RST. Can you file a bug and we will look into it as soon as possible.

      Thanks!

      Jiandong"

        Activity

        Hide
        Martin Matula added a comment -

        Assigning to Jiandong.

        Show
        Martin Matula added a comment - Assigning to Jiandong.
        Hide
        gchoi added a comment -

        Is this issue get fixed now?

        Show
        gchoi added a comment - Is this issue get fixed now?
        Hide
        bshrom added a comment -

        This bug is caused by the way JAXB handles xsd:any DOM content ( see notes on related bug: http://java.net/jira/browse/JAXB-758 )

        The same problem exists with OnBehalfOf when SAML Assertion in included.

        When incoming SAML Assertion is submitted to OnBehalfOf and uses following format <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion", assertion is modified before it goes on the wire as: <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion".

        I will file a separate bug for OnBehalfOf if necessary.

        Show
        bshrom added a comment - This bug is caused by the way JAXB handles xsd:any DOM content ( see notes on related bug: http://java.net/jira/browse/JAXB-758 ) The same problem exists with OnBehalfOf when SAML Assertion in included. When incoming SAML Assertion is submitted to OnBehalfOf and uses following format <Assertion xmlns="urn:oasis:names:tc:SAML:2.0:assertion", assertion is modified before it goes on the wire as: <saml2:Assertion xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion". I will file a separate bug for OnBehalfOf if necessary.
        Hide
        cistox added a comment -

        It is incredible the JAXB 758 bug is still there. The way xsd:Any is handled is wrong. There is no reason to add namespaces from the outer envelope (e.g. WS-Transfer scaffolding) on the xsd:Any content.

        Primary European projects are suffering of these bugs, it is very bad that such fixes are not applied due to dependancies from other bugged projects...
        I am curious to know one of these projects that is relying on such JAXB bugs for its functions. It's a crazy situation.

        XML is a nice thing but it's happen is going to be used on real business scenarios... thus digital signatures and other most serious dependancies have to be supported...

        Show
        cistox added a comment - It is incredible the JAXB 758 bug is still there. The way xsd:Any is handled is wrong. There is no reason to add namespaces from the outer envelope (e.g. WS-Transfer scaffolding) on the xsd:Any content. Primary European projects are suffering of these bugs, it is very bad that such fixes are not applied due to dependancies from other bugged projects... I am curious to know one of these projects that is relying on such JAXB bugs for its functions. It's a crazy situation. XML is a nice thing but it's happen is going to be used on real business scenarios... thus digital signatures and other most serious dependancies have to be supported...
        Hide
        Nithya Ramakrishnan added a comment -

        We tried to recreate the issue using a metro sample (ws-trust/delegate) using the Assertion (generated by ADFS) attached in issue 1631.
        We could not observe the namespaces being modified by Metro. We are trying to analyze this further.

        Show
        Nithya Ramakrishnan added a comment - We tried to recreate the issue using a metro sample (ws-trust/delegate) using the Assertion (generated by ADFS) attached in issue 1631. We could not observe the namespaces being modified by Metro. We are trying to analyze this further.
        Hide
        Nithya Ramakrishnan added a comment -

        Also, from a sample JAXB Marshal/Unmarshal test code, it does not appear to be an error in the way JAXB marshalling is done. Needs further investigation

        Show
        Nithya Ramakrishnan added a comment - Also, from a sample JAXB Marshal/Unmarshal test code, it does not appear to be an error in the way JAXB marshalling is done. Needs further investigation
        Hide
        dkulp added a comment -

        Might be related to http://java.net/jira/browse/JAXB-909

        CXF is seeing the same issue with whitespace being removed for DOM content.

        Show
        dkulp added a comment - Might be related to http://java.net/jira/browse/JAXB-909 CXF is seeing the same issue with whitespace being removed for DOM content.
        Hide
        symonchang added a comment -

        This is a jaxb issue, instead of WSIT issue.

        Show
        symonchang added a comment - This is a jaxb issue, instead of WSIT issue.

          People

          • Assignee:
            symonchang
            Reporter:
            jollerbarn
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 6 hours
              6h
              Remaining:
              Remaining Estimate - 6 hours
              6h
              Logged:
              Time Spent - Not Specified
              Not Specified