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 :smiley: 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 :)

[roncain]

I will use this issue as the main tracking issue for bringing WS* online. First step is #1257 which enables many of the core product pieces necessary for the rest. Transport level security with WS* is the first goal using a CustomBinding, with additional API's to follow.

[zhenlan]

This needs message protection from message security feature, which is unavailable currently.

[coreyakaplan]

Any updates as to when this may be available or if there are any reasonable work arounds?

[brizo001]

Need an update on this, we are considering using .net core for a project but we are currently blocked by this.

[zhenlan]

@coreyakaplan @brizo001 sorry for late response. The work involved for this feature is non-trivial for WCF, aside from blocking issues/missing dependencies,. This is not on any of our short term plan. There are a lot of great feedback/discussions on this thread. Please also vote the issue - it will be easier to tell the number of requests in future planning.

[gtaborga]

Hello. I am working on HR software that integrates with E-Verify, a government WCF service to verify employment eligibility. We wanted to migrate a currently .NET 4.6 WepAPI service to .NET Core, however, found a limitation. I believe this particular API may warrant some consideration of implementing this binding.

The E-Verify web service requires using wsHttpBinding with TransportWithMessageCredential and SecurityType.None. This specific combination seems to be very proprietary of .NET WCF services. This tells me that potentially all consumers of this government API may be forced to integrate either with .NET 4.6 or have a solution to doing this without using .NET. I am currently researching the E-Verify API for options on other ways to use this service but the default service reference added in .NET generates this particular binding for communication out of the box.

Many examples I found to implement this specific protocol in another language always end up using a WCF site as a proxy in between their NodeJS or Java client. If anyone has a solution that can be implemented without WCF please let me know.

It is very likely that either the Department of Homeland Security needs to make their API less proprietary to make integration from other languages easier (unlikely), or we should support this in .NET Core if any modern .NET applications are going to be built to integrate with it. Thanks for any help you can offer.

[mconnew]

I've been thinking about this issue quite a bit lately and I really want to find a solution. Unfortunately our dependencies are absent for us to enable this in an identical way as exists on the full framework. So I have two questions.

1. Do you own both the client and server sides of your scenario?
2. Is full message security with signing and encrypting of messages necessary, or would token authentication be sufficient?

For full transparency, I'm investigating the feasibility of supporting asp.net core style WS-Fed authentication which is done via HTTP headers and making that consumable on the server side via a behavior.

[gtaborga]

Thanks for the response. I was trying to be very explicit when mentioning the E-Verify DHS system. To answer your questions:

1. We only own the client. The server is hosted by the Department of Homeland Security and many other clients nationwide exist.
2. I have tried several configurations of different WCF bindings and I was unable to get anything successful other than what the generated code of the E-Verify service provides which is using the settings I mentioned in the previous post. Any change that requires the server to modify their implementation is likely something we cannot affect considering how many other consumers the service has around the U.S.

E-Verify just released an updated binding configuration for their latest setup. Previously it was: <binding name="WSHttpBinding_IEmployerWebService"> <security mode="TransportWithMessageCredential"> <transport clientCredentialType="None" /> <message clientCredentialType="UserName" /> </security> </binding>

The latest is that they require establishSecurityContext=false as described here <binding name="WSHttpBinding_IEmployerWebService"> <security mode="TransportWithMessageCredential"> <transport clientCredentialType="None" /> <message clientCredentialType="UserName" establishSecurityContext="false" /> </security> </binding>

[brizo001]

E-Verify also supports BasiHttpBinding but only with the security mode set to BasicHttpsSecurityMode.TransportWithMessageCredential, which is also not supported in the current implementation.

[jgreene]

ExactTargets FuelSDK seems to require this. Unfortunately their rest api does not support all operations necessary for my use case so I am not able to use .net standard 2.0 for this project.