Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XML Signature validation is hard-coded and doesn't support all options allowed by the specification #28

Open
voidmain opened this issue Apr 22, 2019 · 0 comments

Comments

@voidmain
Copy link

I've been working with Zendesk support to test FusionAuth's upcoming SAML support with Zendesk. It looks like the signature.rb file is hard-coding the digest validation transforms rather than using what was defined in the <Reference> element.

In our case, we were sending a <Reference> like this:

<Reference URI="#_e134fef3-24eb-4a05-a500-1649f4f0f523">
  <Transforms>
    <Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
  </Transforms>
  <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
  <DigestValue>7jCUYQMfdu8fVJOTtORTjeKMqycOBE+8OTgnUEEAngw=</DigestValue>
</Reference>

From my reading of the specification and testing on other platforms, this is allowed. The specification states that 0 or more <Transform> elements can be provided and only those transforms should be used prior to digesting. This is in section 4.4.3.4 (https://www.w3.org/TR/xmldsig-core1/#sec-Transforms).

This would mean that the SAML library should only be removing the <Signature> element prior to digesting. However, the library is also canonicalizing. It also looks like the library is hard-coding an Exclusive without comments canonicalization. It should be using the canonicalization transform from the <Reference> element instead, which could be Inclusive or something else.

The code that is performing the digest check is in signature.rb in the method verify! on line 68.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant