Support WS* Bindings to allow interop with federated WCF services

[sujitdmello]

Customer has a large deployment of WCF services that use WsHttpBinding & WsFederationHttpBinding. They are currently developing.NET Core based front-end Web APIs (using ASP.NET 5) that would have to consume these services. Without support for these WS-* bindings, there is no way to call these services securely using federated security. Enabling WS-* on the WCF client would enable these interop scenarios for large enterprises.

[roncain]

Thanks for the suggestion @sujitdmello . Let's use this issue to discuss it and collect other input from the community. Inviting @iamjasonp and @mconnew for their thoughts.

[popcatalin81]

My input:
WS-* is absolutely necessary for any SOAP based stack for interoperability with other WS technologies or in case of existence of an IdP (Identity Provider).

Almost any decent sized WCF based application will make use of WS-* (maybe WS-Trust being the most common). If Core WCF is reduced to a SOAP alternative to REST services with minor additions then there's no point in Core WCF at all. If Core WCF cannot be used interoperably with other WS-* stacks (IE: Full .Net WCF), then there's no point in it either.

From a security point of view Username, Certificate and Windows authentication is simply insufficient especially when considering cloud and hybrid platforms, WS-* extensions are needed for this scenario.

My 2c.

[iamjasonp]

Good feedback, @popcatalin81 and @sujitdmello - thanks!

Our first cut of the APIs in the WCF client for .NET Core was based on what was available on the API surface for Windows Store 8 apps... (maybe this list will look familiar 😃 WCF in Metro apps).

I'm of the opinion too that WS-* protocols present in WCF desktop should be supported.

WCF on the desktop supported these protocols... I've come up with a (likely incomplete) list of things that isn't supported yet in no particular order:

• Messaging - WS-Addressing 2004/08
• Security - WSS SOAP Message Security 1.0
• Security - WSS SOAP Message Security UsernameToken Profile 1.1
• Security - WSS SOAP Message Security X.509 Certificate Token Profile 1.1
• Security - WSS SOAP Message Security Kerberos Token Profile 1.1
• Security - WS-SecureConversation
• Security - WS-Trust
• Security - WS-Federation
• Reliable Messaging - WS-ReliableMessaging
• Transactions - WS-AtomicTransaction
• Transactions - WS-Coordination

So... what protocols does the community think is important to have in WCF client?

[taspeotis]

WS-Federation and WS-Trust are extremely important, and I would love to see support for WS-Federation made available in coreclr by bringing in large parts of System.IdentityModel/Windows Identity Froundation (I assume this is a precursor to WCF supporting it).

[dersteve]

We have a scenario where we would need WS-Federation and WS-Trust in a UWP context. Are there some plans to finally make this happen?

In the meantime, are there alternatives, e.g. libraries/packages that already implemented this that we could use?

[CountZachula]

Any updates on WS-* support? The information I've found is extremely sparse.

[roncain]

Apologies @CountZachula @dersteve and others on this thread -- there have been no updates on this while we've been heads down on the pending release. But we hear this request and are building out our plan for next features, so requests like yours are helping set the priorities. We're tracking them with this query.

If there are other mission critical features not yet available, please continue to open issues for them and double-check that we have triaged and understood them appropriately.

We will shortly publish an updated Supported Feature Matrix and hopefully a roadmap based on your requests.

[StrangeWill]

So does that mean we can't use anything that would require a WsHttpBinding? I'm getting a content type text/xml charset=utf-8 was not supported by service which back in .NET you were using a basic binding when you should be using WS.

[bc3tech]

Same here @StrangeWill - need wsHttpBinding for a svc i'm trying to consume in a UWP....

[StrangeWill]

@bc3tech Check out #1370, I'm consuming a service I'd need wsHttpBinding for using CustomBinding code from that issue, so far so good.

[pholly]

I need wsHttpBinding to work so I can hit a on-premise estore (http://www.nodus.com/documentation/eSSS_501_API_Developer_Guide.pdf). I tried using CustomBindings with http but it didn't work - it could be because I need provide Windows credentials.

[StrangeWill]

@pholly Have you tried setting channelFactory.Credentials and httpBindingElement.AuthenticationScheme from the code sample in #1370?

[pholly]

@StrangeWill These are the errors I'm getting so now I'm not sure if it's even rejecting it because of credentials:

An unhandled exception occurred while processing the request.

WinHttpException: The operation timed out
ProcessGetResponseWebException

HttpRequestException: An error occurred while sending the request.
ProcessGetResponseWebException

CommunicationException: An error occurred while sending the request.
ProcessGetResponseWebException

I'm not using a ChannelFactory - I used svcutil.exe to generate the client. One of the client constructors takes a Binding and an EndpointAddress so I'm using that one. Should I try to not use the generated client and use a ChannelFactory? The generated client has a way to specify credentials with this line:

client.ClientCredentials.Windows.ClientCredential = new System.Net.NetworkCredential(username, password);

If I don't use the client, what httpBindingElement.AuthenticationScheme should I use?

Really appreciate the help and if you want me to provide more info just let me know. I may be able to query this estore's database directly but if I could use the api that would be so much better.

[StrangeWill]

@pholly Ah, nah you're on the right track -- timeout exception hints that you need to increase the send/receive timeout though.

Edit: Or you don't have network connectivity to their APIs.

If it was a WS* binding error you'd be getting something completely different.

[pholly]

@StrangeWill I switched the endpoint to a network ip instead of a hostname and this is the error I get:

FaultException: The message could not be processed. 
This is most likely because the action 'http://tempuri.org/ICustomers/GetCustomerbyUsername' is
incorrect or because the message contains an invalid or expired security context token or because
there is a mismatch between bindings. 
The security context token would be invalid if the service aborted the channel due to inactivity. To
prevent the service from aborting idle sessions prematurely increase the Receive timeout on the
service endpoint's binding.

So I probably should try creating the request without the generated client?

[StrangeWill]

@pholly You should be able to take a binding that works in .NET and use a custom binding for .NET Core by using custom bindings for this purpose, there is a tool here that may put you on the right track for converting it: http://webservices20.cloudapp.net/ (it is a custom binding for .NET not .NET Core, but it helps you break down sort of how to configure a .NET Core custom binding).

Sadly I don't have a service at my disposal right now to test this against. It looks like you should be able to create a SecurityBindingElement and add it to your custom binding. Not sure why the tool isn't handling that for you though.

Something down the road of this?

var securityBindingElement = SecurityBindingElement.CreateUserNameOverTransportBindingElement();
binding.Elements.Add(securityBindingElement);

[pholly]

@StrangeWill Thanks for the suggestion. I tried using a ChannelFactory and setting the Credentials.Windows.ClientCredential on it but I got the same error so I'll try using that SecurityBindingElement.

[pholly]

I get this error when using SecurityBindingElement:

PlatformNotSupportedException: TransportSecurityBindingElement.BuildChannelFactoryCore 
is not supported.

As a workaround I am going to create an asp.net 4 api that interfaces with our estore and hit that from our asp.net core api.

[StrangeWill]

@pholly Shoot, #1257, looks like it needs to be implemented before it's supported in .NET Core, unless one of the .NET Core WCF team members want to chime in with something I'm missing to get around this. :(

[iamjasonp]

You're not missing anything - we'll get on it (#1257) shortly :)

[penev92]

Hello,

I am not sure if this is the right place to ask this, but I couldn't find a better one so here it goes:

Backstory: I have to call a 3rd-party (apparently Java) SOAP service that is using some more convoluted security than I would like. My project is on .NET Core 3.1 and is successfully calling a number of other SOAP services. I am working off of the WSDL and an example request on this one.

From what I can tell from the WSDL, the binding is using a custom security policy, which seems to reference http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702
After doing some digging I found a question on StackOverflow that is pretty similar to mine, but has no answer. The headers I need to produce (comparing these with my example request) are almost identical to the ones found at https://stackoverflow.com/questions/60675836/sign-soap-1-1-body-with-net-core-3-1 and the description there (about the AsymmetricBinding) matches what my WSDL says about the security policy.

Now I have a few questions:

1. Is this the right place for this? Issue says "WS* Bindings", soo... hopefully?
2. Am I missing any way to get the desired result (apart from writing my own custom security header), that is already available?
3. If no, am I right in assuming that System.ServiceModel.Federation package #4298 is working in the direction of implementing the missing pieces?
4. If so, is there by any chance a reasonable timeframe we can expect the necessary bits to be implemented?

Thank you.

[doorman02]

Hi, what´s the current status of supporting WsFederationHttpBinding? If it´s available are there any examples of usage?

[yogitubadzin]

Hi, any updates for this thread, @iamjasonp and @mconnew?

[mconnew]

@doorman02 , @yogitubadzin, this comment is probably the best starting point to understand the current state. We are working with some internal and external customers of WCF to get this working. As this is all new code, there are some scenarios which are taking a little bit of work to refine so we still have some bugs to shake out. I encourage you to give it a try as the sooner any bugs are reported, the sooner they can be addressed.

[yogitubadzin]

@mconnew when dou you have deadline for full release 4.8.0?

[yogitubadzin]

@mconnew Do you have any example of using certificates for WsTrustTokenParameters or related classes? We need use this now.

[mconnew]

@yogitubadzin, 4.8.0 should be going RTM at the same time as .NET 5 is released, although we're still only requiring .netstandard 2.0 so we will work on all supported versions of .NET Core and you won't need to upgrade to .NET 5 to use it.
As for how to use certificates, if you look at the sample in the linked comment, there's an issuer binding. This is the binding used to communicate with your STS (usually ADFS server but doesn't need to be) when it's getting the WS-Trust token to talk to your actual service.. So you should just be able to configure the issuer binding to use certificates and set the client certificate on your channel factory client credentials. You didn't specify if you are using certificate with transport security or if you are using TransportWithMessageCredentials. Your issuer binding might also be WSHttpBinding and not the 2007 variant. You should be able to work this out from your existing binding. If you can't, post your existing binding and I'll try my best to help you. If could be as simple as using that sample with this change:

var issuerBinding = new WS2007HttpBinding(SecurityMode.TransportWithMessageCredential);
issuerBinding.Security.Message.ClientCredentialType = MessageCredentialType.Certificate;
issuerBinding.Security.Message.EstablishSecurityContext = false;

[eiki25]

Do you have a replacement for WSTrustChannelFactory and CreateChannelWithIssuedToken method in general on ChannelFactory?
https://docs.microsoft.com/en-us/dotnet/api/system.servicemodel.security.wstrustchannelfactory?view=netframework-4.8

.NET Framework Code
var factory = new WSTrustChannelFactory( new IssuedTokenWSTrustBinding { SecurityMode = SecurityMode.TransportWithMessageCredential }, new EndpointAddress(new Uri(configuration.AdfsUrl))) { TrustVersion = TrustVersion.WSTrust13, Credentials = { UseIdentityConfiguration = true, SupportInteractive = false } }; var channel = factory.CreateChannelWithIssuedToken(securityToken);

Can CreateWsTrustRequest in WSTrustChannelSecurityTokenProvider be used? and do you have any example on how to use that class?
https://docs.microsoft.com/en-us/dotnet/api/system.servicemodel.federation.wstrustchannelsecuritytokenprovider.createwstrustrequest?view=dotnet-plat-ext-5.0

[yogitubadzin]

Hello, I missed this message as google put this to SPAM folder. Question is to me and stil open? wt., 2 lut 2021 o 17:05 Eiríkur Haraldsson ***@***.***> napisał(a):

…

Do you have a replacement for WSTrustChannelFactory and CreateChannelWithIssuedToken method in general on ChannelFactory? https://docs.microsoft.com/en-us/dotnet/api/system.servicemodel.security.wstrustchannelfactory?view=netframework-4.8 .NET Framework Code var factory = new WSTrustChannelFactory( new IssuedTokenWSTrustBinding { SecurityMode = SecurityMode.TransportWithMessageCredential }, new EndpointAddress(new Uri(configuration.AdfsUrl))) { TrustVersion = TrustVersion.WSTrust13, Credentials = { UseIdentityConfiguration = true, SupportInteractive = false } }; var channel = factory.CreateChannelWithIssuedToken(securityToken); Can CreateWsTrustRequest in WSTrustChannelSecurityTokenProvider be used? and do you have any example on how to use that class? https://docs.microsoft.com/en-us/dotnet/api/system.servicemodel.federation.wstrustchannelsecuritytokenprovider.createwstrustrequest?view=dotnet-plat-ext-5.0 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#31 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGS5DSXMZBRWBX4U4VEX6KLS5APGJANCNFSM4BETXH2Q> .

[mconnew]

See this comment for how to do this.

[tayfunuyar]

You can try this.
https://www.nuget.org/packages/WsSecurityCore/

You can get the response as XmlNodeList or Xml full string and convert to response your class use XmlSerializer.

[Mohamed-Effat]

@mconnew Do we currently have support for Security - WSS SOAP Message Security UsernameToken Profile 1.1 with PasswordText type? even if it's in the preview versions?

If so could you please provide an example on how to configure it's binding?

[tayfunuyar]

@mconnew Do we currently have support for Security - WSS SOAP Message Security UsernameToken Profile 1.1 with PasswordText type? even if it's in the preview versions?

If so could you please provide an example on how to configure it's binding?

WS Security not supported yet . You can try configure XML soap header for WsSecurity and send request .

Check this repo for example code : https://github.com/tayfunuyar/WsSecurityCore

[Mohamed-Effat]

@tayfunuyar With this Nuget package, I would still have to worry about creating the request body (envelope) and converting the response into a model class, which both are the only reason I'm considering the use of WCF

[mconnew]

We do support a subset of message security. We don't support signing or encrypting the message itself, but we do support the token authentication part of it, but we only support the UsernameToken Profile 1.0. The difference between 1.0 and 1.1 is that 1.0 doesn't really obfuscate the password and 1.1 hashes it (and specifies the hash algorithm). The reason why this couldn't be done in WCF on .NET Framework is because on the service side the authentication was being done against Windows authentication which needed the plain text password. This code base doesn't need to be concerned with server side code, so in theory it should be easy enough to add support.

But this is something you can actually do yourself. There's quite a few boiler plate classes you need to create, but nothing really very complicated. First, you need to make a class derived from ClientCredentials and override the CreateSecurityTokenManager() method. You will need to return your own implementation of SecurityTokenManager which wraps the one returned by calling base.CreateSecurityTokenManager(). When SecurityTokenManager.CreateSecurityTokenSerializer you will return your own implementation of SecurityTokenSerializer. You can skip implementing any of the reading code as it's only used on the consuming side (ie server). You implement the abstract methods. CanWriteTokenCore, you check the token type and return true is it's the username security token. You don't need to worry about writing any key identifiers or key identifier clauses, our existing implementation just throws on those methods anyway. The only thing other than CanWriteTokenCore you need to implement is WriteTokenCore. Although it's in a different class, the current implementation can be seen here. From memory (it's been a few years since I looked at the spec), the differences are some minor namespace changes, the password is a hash of the password, and there was an extra element specifying the hash algorithm being used.

You will either need to use reflection to get the username/password from the UsernameSecurityToken, or provide your own SecurityTokenProvider which returns your own implementation.

Now that I've explained how to do it yourself, I found an implementation someone else has done and published in a blog post here. I only had a cursory look, but it looks like it should work. It has more in it than you need/will work on Core, so you can strip out the unnecessary code.

[Mohamed-Effat]

@mconnew Thank you so much for the guide.
But there's something that also interest me in what you said there, we do support UsernameToken Profile 1.0 ?
Is it out of the box? I couldn't get 1.0 to work on Core except with the help of these blog posts here and here.

What It's basically is that we create a bunch of boilerplate classes as well, it's simply creating your own MessageHeader class that would become the desired header format and adding that header into the your own implementation of BeforeSendRequest method in an implementation of IClientMessageInspector that gets added by another implementation of IEndpointBehavior

It works for 1.0 in Net Core but it also requires boilerplate code, do we have an out-of-the-box solution now like some certain binder settings?

[mconnew]

You probably just want to use BasicHttpBinding with security mode TransportWithMessageCredential. Then set BasicHttpBinding.Security.Message.ClientCredentialType to BasicHttpMessageCredentialType.UserName. If you need any of the other WS-* specs like secure conversation, then you would need either WSHttpBinding or WS2007HttpBinding.

[Mohamed-Effat]

@mconnew I've tried it but it did not create a Security tag in the envelope's headers tag
I'm assuming it instead created a BASIC Http request header? I'm only assuming as the IClientMessageInspector.BeforeSendRequest Message object does not show actual headers sent in the HTTP request (?)

This is the configuration I've used
Note: The System.ServiceModel.Security nuget package version is 4.9.0-preview1.21224.1

var binding = new BasicHttpBinding(BasicHttpSecurityMode.TransportWithMessageCredential);
binding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.UserName;
var client = new MyServiceClient(binding, endpoint);
client.ClientCredentials.UserName.UserName = username;
client.ClientCredentials.UserName.Password = password;

Since the Security envelope header wasn't there, my server did not accept the request and returned a fault thus WCF threw the following exception message.

Security processor was unable to find a security header in the message. 
This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties. 
This can occur if the service is configured for security and the client is not using security.

[mconnew]

It will be there. Message inspectors don't run at the transport end of the stack where you would see the header, they run at the top where only the message body and basic headers are populated.
It's possible that the wrong security version is being used. A security header with the wrong name space is as good as no security header. Do you have an example of the expected security header? It might just need the MessageSecurityVersion to be set to something different.

[Mohamed-Effat]

This is the Expected security header tag

<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <wsse:UsernameToken wsu:Id="UsernameToken-1" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
            <wsse:Username>myUsername</wsse:Username>
            <wsse:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">myPassword</wsse:Password>
         </wsse:UsernameToken>
</wsse:Security>

I am not sure what does the header that WCF should be sending here should look like (and I'm fairly new to OASIS standards) but if it's the standard http header
key: Authentication value: Basic base64Encoded(username:password) then I'm sure my server doesn't accept that.
I can only call the server from a client, I do not have access to how it's internals work.

[mconnew]

That is exactly the header I would expect to be emitted by WCF when using BasicHttpBinding. Can you use Fiddler to capture the request headers that WCF is sending and see what security header is being sent?

[Mohamed-Effat]

@mconnew Ok, so after investigating with fiddler, something interesting showed up.
Apparently the configurations I've mentioned above here sends the credentials inside the envelope headers as a Security tag and not as a Basic HTTP header, but even though the security tag is sent in the body in the end, It does not show in the IClientMessageInspector.BeforeSendRequest, It's inserted at a later step internally I assume.

nonetheless, since the security tag is created, the server responds successfully !
and even using the generated envelope captured by fiddler in something like postman makes the server responds successfully.

But still WCF throws the exception the moment the server returns it's response, could this be an internal bug? or maybe does WCF expects a certain header in the server response?

I've thought perhaps the issue is due to the preview version so I downgraded into the stable 4.8.1 but still the same behavior occurs

The Http headers that are sent are:
Cache-Control, SOAPAction, Request-Id, Accept-Encoding, Content-Type ,Content-Length

The generated envelope header is something as follows:

   <s:Header>
      <h:MyAppHeaders xmlns:h="http://xmlns.myServer.com/apps/myApp/" xmlns="http://xmlns.myServer.com/apps/myApp/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"/>
      <o:Security s:mustUnderstand="1" xmlns:o="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
         <u:Timestamp u:Id="_0">
            <u:Created>2021-05-16T12:56:09.980Z</u:Created>
            <u:Expires>2021-05-16T13:01:09.980Z</u:Expires>
         </u:Timestamp>
         <o:UsernameToken u:Id="uuid-ba03e9f6-8cb2-435d-bf84-c90026f59a56-1">
            <o:Username>myUsername</o:Username>
            <o:Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordText">myPassword</o:Password>
         </o:UsernameToken>
      </o:Security>
   </s:Header>

[mconnew]

Oh, I think the problem is the server isn't responding with a security header. It's supposed to by the spec, but some implementations don't. There is a workaround, but I'm not going to have time to post it until Tuesday. It is mentioned elsewhere in another issue. Search for EnableUnsecuredResponse and you should find it.

[Mohamed-Effat]

@mconnew No need, You've helped me more than enough, thank you for your support on this project.

For those who look find similar issue Here's the Issue #3653 comment here that has the workaround.

So basically If one has a server that uses UsernameToken Profile 1.0 for security AND the server does not return a security header on the response, then there are two options here:

Either inject the header manually in the request and not tell binder to expect a security header in response (not specifying BasicHttpSecurityMode.TransportWithMessageCredential)

Or tell the binder to expect the header and inject an empty security header in the response in order to avoid the exception.

Both workarounds require boilerplate classes, I think I will stick to the request injection as it seem less boilerplate and more flexible workaround until the EnableUnsecureResponse binder flag is fully supported on Net Core, then I'd switch to the fully supported approach.

[sachinninawe25]

Hi Guys,
I am also facing the same issue and tried multiple work around to work but didn't succeeded.

Is there any latest release related to wshttpbinding support in .net core?

Thanks

[dev-crisloli]

@mconnew No need, You've helped me more than enough, thank you for your support on this project.

For those who look find similar issue Here's the Issue #3653 comment here that has the workaround.

So basically If one has a server that uses UsernameToken Profile 1.0 for security AND the server does not return a security header on the response, then there are two options here:

Either inject the header manually in the request and not tell binder to expect a security header in response (not specifying BasicHttpSecurityMode.TransportWithMessageCredential)

Or tell the binder to expect the header and inject an empty security header in the response in order to avoid the exception.

Both workarounds require boilerplate classes, I think I will stick to the request injection as it seem less boilerplate and more flexible workaround until the EnableUnsecureResponse binder flag is fully supported on Net Core, then I'd switch to the fully supported approach.

Hi, I dont understand this solucion inject head. Please if you can example. Mi code is Next:

                BasicHttpBinding binding = new BasicHttpBinding(BasicHttpSecurityMode.TransportWithMessageCredential);
                binding.Security.Transport.ClientCredentialType = HttpClientCredentialType.None;
                binding.Security.Transport.ProxyCredentialType = HttpProxyCredentialType.None;
                binding.Security.Message.ClientCredentialType = BasicHttpMessageCredentialType.UserName;
                binding.Security.Message.AlgorithmSuite = SecurityAlgorithmSuite.Default;
                byte[] byteArray = File.ReadAllBytes(pathFile + ".zip");
                EndpointAddress remoteAddress = new EndpointAddress("https://aa.xx.com/bb/billService?wsdl");
                ChannelFactory<Test.BillServiceChannel> factory = new ChannelFactory<Test.BillServiceChannel>(binding, remoteAddress);
                System.ServiceModel.Description.ClientCredentials loginCredentials = new System.ServiceModel.Description.ClientCredentials();
                loginCredentials.UserName.UserName = "XXXXX";
                loginCredentials.UserName.Password = "XXXX";
                factory.Endpoint.EndpointBehaviors.Clear();
                factory.Endpoint.EndpointBehaviors.Add(loginCredentials);

                var elements = factory.Endpoint.Binding.CreateBindingElements();
                var element = elements[0];
                //elements.Find<SecurityBindingElement>().EnableUnsecuredResponse = true;

                factory.Endpoint.Binding = new CustomBinding(elements);
                Test.BillServiceChannel channel = factory.CreateChannel();

                Test.sendBillRequest a = new Test.sendBillRequest(pathFile+ ".zip", byteArray);
                var responseMessage = channel.sendBill(a);

elements.Find().EnableUnsecuredResponse = true; not found .Net 6.0 buy edit this value in debug found buy i don't find edit in code c#.