Add System.Security.Cryptography.Xml.SignedXml class

[ghost]

Execution plan

Goal: Provide APIs fully compatible with full/Desktop .NET Framework (no changes as part of this work - straight port only)

Plan:

• 1. Add the source code on GH sanitized, with licenses, etc. (it won't build)
• 2. Make the source code build (still excluded from overall repo build)
• 3. Remove Desktop registry-compat code paths
  • Remove methods that have [RegistryPermission] (Utils and SignedXml classes) along with any owned methods
  • Address any other registry-related compile errors such as those using Registry, RegistryPermission, RegistryKey, etc (delete code as necessary)
• 4. Add tests (We have to agree on expected code coverage and how much of the spec we have to cover)
  • Compare test results between Desktop and .NET Core implementations
• 5. Make it part of overall repo build & ship it!

Code changes rules: Only code changes absolutely necessary to make it build and compatible with (full) .NET Framework are allowed, no additional bug fixes or changing architecture - such PRs will be rejected now.
Changes like that can be considered after the initial port is done, when we have a good test bed and when we are able to validate such change.

If larger code/architecture changes are needed from some reason, we should discuss them first here, before doing the work / submitting PR.

If you work on some parts of the plan, please say so in the discussion to avoid duplicated work. We (@steveharter @karelz) will co-assign the issue to you.

---

Original

The class to digitally sign XML needs to be added.

[rschiefer]

As referenced by Tratcher, this is a blocker for adding support for WsFederation/ADFS in ASP.NET 5. We use ADFS extensively for many enterprise ASP.NET 4 applications. We are very interested in migrating to ASP.NET 5 and using WsFederation.

[bartonjs]

@rschiefer @Tratcher Well, it's... complicated.

• ADFS doesn't use System.Security.Cryptography.Xml.SignedXml; but instead its own implementation.
  • (That's largely from dusting off mental cobwebs and remembering back to being on that team for version 1 of ADFS)
• System.IdentityModel definitely doesn't use System.Security.Cryptography.Xml
  • (That's 'cuz their source code on referencesource says so 😄)
• People don't really like System.Security.Cryptography.Xml.SignedXml because it's based on XmlDocument, which leads to some perf issues.
  • The ADFS version was based on XmlReader, IIRC.
• So, likely what people want is CoreFX to create a new implementation of SignedXml.
• But a new version of SignedXml won't compatible with the old version of SignedXml
• So some people might want us to keep the old version, too.
• So in all, people really want two versions.
• Except they don't want the old version.
• Except for when they do.

So we're left with the conundrum of:

• We can port that class that no one really wants
• Or, we can stop and design a brand new thing that probably no one will use, since they can't be compatible with anything else
• Or, to use the most effort and still not benefit anyone, do both 😄.

@terrajobst - fyi

[bartonjs]

Apparently I was a bit rambly this morning. Sorry :).

We've definitely identified that there's work to be done here, but we don't think the right answer is to bring forward the existing System.Security.Cryptography.Xml code. Instead, this represents the item on our backlog to engineer a general-purposed implementation for XmlDSig which is fast and not tied to legacy object models (e.g. XmlDocument).

That effort isn't something that we're expecting to do for .NET Core 1.0, simply because we're focused on other things.

But, letting us know that you're impacted by the missing functionality does help with ongoing prioritization.

[AndersAbel]

I'm looking at creating an ASP.NET Core SAML2 Middleware, based on https://github.com/KentorIT/authservices. Without a SignedXml port it won't be able to run on the Core framework.

I definitely do agree that not carrying over the existing one is a good idea. Would it be possible to do anything based on an XmlReader API? That way both XDocument and XmlDocument can be supported. Also providing an implementation of the enveloped reader used in System.IdentityModel would be nice (if it was improved to support XML files with whitespace...)

[bartonjs]

@AndersAbel XmlReader is where I'd start, yeah (unless the XML guys tell me there's something better).

Since XmlReader what the System.IdentityModel variant is based on, it should be doable :).

[AndersAbel]

@bartonjs The System.IdentityModel variant is quite limited though in what transforms it can handle. For SAML2/WS-Fed work it wouldn't be a problem, but as a general API it must be considered how to deal with non-enveloped signatures and xml containing nested signatures (such as a signed saml response containing signed assertions). Also I think that the System.IdentityModel.EnvelopedSignatureReader is copying the data when doing the validation. There's a lot of fun to be done there. If I had the time I'd love to work on it.

[Icestorm0141]

I appreciate the rambling @bartonjs, helps to see whats going on behind the scenes.

Currently my company is impacted by this. We have some legacy code that we're trying to port over to .NET Core that generates signed XML license files and without this set of classes we're stuck. We're open to diverging from XML files as the base for the licenses but as of this moment we haven't found a good solution that fits our needs.

Looking forward to seeing this get added in the future.

[sandersaares]

I can attest that this (and also the slightly related XML Encryption) is relevant for us. The existing form in .NET Framework would be just fine - no need for innovation here, from my perspective. Copy & paste implementation would be very welcome!

Is there currently any workaround available?

[af0l]

Would like to know what @sandersaares asked, too. There's no built in way to sign xml in the CoreFX now?

[bartonjs]

@sandersaares / @af0l : There is not, for .NET Core 1.0, any inbuilt implementation of SignedXml/XmlDSig.

Based off of comments here (and others) we'll probably just bring over the old API, but we didn't have time to make it happen for 1.0.

[af0l]

Thank you @bartonjs, that must be the reason I could not get our project to work on Core. :) It's also a great shame, because I'd love to move ahead and can't until it's done. We have to report all payments to our tax authority using signed xml's, so it's a showstopper really.

[emailtowalter]

Any progress on this? I am stuck with the SAML token validation which requires this feature. Thanks

[af0l]

Yeah, would liek to know that too. We ended up extracting the features needing the signature and putting them into a separate web API solution...

[john182]

Already have idea on which version will be implemented or solution