Support security mode Message

[mconnew]

Splitting issue #8 into two. This issue will be for full Message security including signing and encrypting as the SOAP message level.

[easyest]

Core is unusable till there will be a way to consume WCF services. Therefor ASP.NET Core is unusable also. So stuck in 2019 with 2013 technology. GG.

[StephenBonikowsky]

Want to get this done for 5.0 if possible but we have a dependency on some external APIs that would have to be provided in order for us to get this working. (such as SignedXml).

[StephenBonikowsky]

Tagging @krispenner

[krispenner]

Hi @mconnew and @StephenBonikowsky, are there any updates on this task? It has been blocked for over a year so I'm just checking in again :)

Can you also confirm that this task, when or if completed, will resolve the issue @mconnew discusses with me here?

I believe usage of AsymmetricSecurityBindingElement implies full message security which we still don't have any concrete plans to be able to support.

We depend on code which isn't in .NET Core to achieve message security. There is a potential path to bring the feature, but I'll be honest it will be a while before we can consider thinking about trying to get everything lined up for that.

I assume the blocker here is due to the code that isn't yet in .NET Core? If so, any update or timeline (.NET 6, 7, ... 10) on that would be much appreciated.

[mconnew]

Sorry, no update on the timeline. One of the blockers is absence of an implementation of the STR Transform for signed XML.
There are two potential paths forward. The first is to implement the STR Transform for use with the System.Security.Cryptography.Xml.SignedXml implementation. I don't know how big of a task that is, or if it's something I'd be willing to accept into this repo. I have a pretty strong policy of not directly owning any security primitives in this repo. This is because it's a minefield of potential problems, and without a lot of eyes on an implementation and without it being used in multiple contexts, it's easy for security bugs to go uncaught. So I would need to evaluate if there's any crypto aspect to the transform. Even when there isn't directly, sometimes you can affect crypto indirectly by providing the incorrect input to something that is crypto related. The implementation in .NET Framework that WCF uses is a cheater implementation taking some shortcuts and isn't a full implementation, but I don't think we can get away with doing the same thing using the public crypto SignedXml implementation. There is an implementation which shipped with WSE3.0 but I tried for 2 days to unpick it from the rest of WSE but it had too much interdependency on other classes, but I didn't really understand what the transform does so that made it harder to work out how to prune the dependencies.
The second option is that I've been told there's a full implementation of signed XML in the new Microsoft.IdentityModel.* packages, but I don't know if it includes the STR Transform. If it does, I don't know if it's exposed in a usable way. I would need to evaluate that and potentially negotiate exposure via public api. This might be the better option long term, but it will take time and nobody else has been inclined to volunteer to dig in and work this out.

There is also another unknown, which is the encryption part. There is an implementation of xml encryption in System.Security.Cryptography.Xml.EncryptedXml which I would hope would do the job. I don't know if this has all the capabilities needed, but I have no reason to believe it doesn't. But you never know until you try to use it.

I'm sorry I don't have a better answer for you. Realistically it's really unlikely to be done for .NET 7 as other large tasks are in the pipe before that. I can't speak to priorities beyond that.

[krispenner]

Thank you very much @mconnew for the detailed and honest update.

[brianwaynerogers]

@mconnew
This is a pain point for me, b/c I have one WCF dependency where the service, which I do not control, is using Message security, so I have to still support a client running .NET Framework. I know this issue blocked, and you have recently referenced your comment above on the status, but I wanted to let you know that if you find a way to get this done, it will be appreciated, for whatever that is worth.

[dzambo2302]

@brianwaynerogers
The same situation over here.

[DonKedero]

Same situation here, using .NET 7; AsymmetricSecurityBindingElement is not present.
API (SOAP) is from the government ... so it's a bit blocking the migration from a .NET Framework 4.8 project. Looking into some creative stuff like a .NET Framework 4.8 WebApi which is called locally from .NET 7, or some namedpipes, ...

[awroggeband]

Same situation here, using .NET 7; AsymmetricSecurityBindingElement is not present. API (SOAP) is from the government ... so it's a bit blocking the migration from a .NET Framework 4.8 project. Looking into some creative stuff like a .NET Framework 4.8 WebApi which is called locally from .NET 7, or some namedpipes, ...

The workaround that I used to access the unmoveable government API is to create a .Net 4.8 self hosted service with the same API interface that receives requests from .Net 7.0 clients and proxies them to the gov't API

[delixfe]

Add to: Support for Message Security #5641