Wcf: SecurityBindingElement.CreateUserNameOverTransportBindingElement() not supported.

Created on 6 Jun 2016  路  30Comments  路  Source: dotnet/wcf

possibly related to #9 but I wasn't sure so I'm opening this because I wasn't sure what the roadmap was.

I get this error when trying to use the SecurityBindingElement.CreateUserNameOverTransportBindingElement(); binding element as part of a CustomBinding

(running on OSX with .NET core RC2)

Here is my code

    public class AcmeServiceChannelFactory : ChannelFactory<AcmeService>
    {
        public AcmeServiceChannelFactory()
            : base(CreateDefaultBinding(), new EndpointAddress("https://acme.com/service.asmx"))
        {
            Credentials.UserName.UserName = "username";
            Credentials.UserName.Password = "password";
        }

        internal static Binding CreateDefaultBinding()
        {
            var binding = new CustomBinding();
            var securityBinding = SecurityBindingElement.CreateUserNameOverTransportBindingElement();
            securityBinding.IncludeTimestamp = false;
            securityBinding.SecurityHeaderLayout = SecurityHeaderLayout.Lax;
            binding.Elements.Add(securityBinding);
            var textbinding = new TextMessageEncodingBindingElement
            {
                MessageVersion = MessageVersion.Soap11,
                ReaderQuotas = new XmlDictionaryReaderQuotas
                {
                    MaxArrayLength = int.MaxValue,
                    MaxDepth = 64,
                    MaxStringContentLength = int.MaxValue
                }
            };

            binding.Elements.Add(textbinding);

            var httpsBinding = new HttpsTransportBindingElement
            {
                MaxReceivedMessageSize = int.MaxValue,
                MaxBufferSize = int.MaxValue
            };

            binding.Elements.Add(httpsBinding);
            binding.OpenTimeout =
            binding.ReceiveTimeout =
            binding.SendTimeout = TimeSpan.FromMinutes(5);
            return binding;
        }
    }

error:

System.PlatformNotSupportedException: TransportSecurityBindingElement.BuildChannelFactoryCore is not supported.
   at System.ServiceModel.Channels.TransportSecurityBindingElement.BuildChannelFactoryCore[TChannel](BindingContext context)
   at System.ServiceModel.Channels.Binding.BuildChannelFactory[TChannel](BindingParameterCollection parameters)
   at System.ServiceModel.Channels.ServiceChannelFactory.BuildChannelFactory(ServiceEndpoint serviceEndpoint, Boolean useActiveAutoClose)
   at System.ServiceModel.ChannelFactory.OnOpening()
   at System.ServiceModel.Channels.CommunicationObject.<System-ServiceModel-IAsyncCommunicationObject-OpenAsync>d__71.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.ServiceModel.Channels.CommunicationObject.<OpenAsyncInternal>d__70.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
   at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
   at System.ServiceModel.ChannelFactory.EnsureOpened()
   at System.ServiceModel.ChannelFactory`1.CreateChannel(EndpointAddress address, Uri via)
Known Issue 2.1.0 Net Core 3.1 LTS Servicing feature request

Most helpful comment

I would like to know when WS-trust bindings will be supported for .NET Core

All 30 comments

Thanks for reporting this, @feinoujc!

As we're focusing on wrapping up the 1.0.0-rtm milestone, we won't look at what's involved in turning this on yet for the moment, but we'll keep it in our backlog - once we think about how this fits into the overall roadmap, we'll report back.

@iamjasonp -- I am starting work on this. Please let me know if this duplicates any work you have done already.

@feinoujc -- thanks for such great details. I can repro what you described, and I'm working on this now. Is it possible for you to include (without disclosing any sensitive information) what the server-side looks like to match? Ideally, I want to make a new functional test that replicates your scenario exactly, so I'd like to configure a server-wide endpoint to match yours.

@roncain the server side in this case is a 3rd party web service that I don't have any insight into. I'm not sure what I could provide here. Would the wsdl help at all?

@feinoujc -- yes, the wsdl could be useful to make some choices on our end. Is this 3rd party web service endpoint publically available (say for me to attempt to reach it)? The .asmx angle here could be interesting to ensure we're supporting and testing what's required to interact with the site.

@roncain Sure, it is public so I don't see a problem sharing it. here you go: https://ncarb--tst.custhelp.com/cgi-bin/ncarb.cfg/services/soap?wsdl

It might be worth mentioning I had massive issues using the WCF Connected Service add on with this wsdl. Not surprising due to the underlying limitations of WCF dotnet core at that time.

Thanks @feinoujc -- I'll start looking at it now.

Sorry to hear about the WCF Connected Service issues. Feel free to open new issues directly in this current repo, and we'll find the right owner. Some existing known issues can be seen in this query.

/cc: @mlacouture @zhenlan

The most recent code additions to enable this scenario are in the https://github.com/dotnet/wcf/tree/ws-trust branch. Significant work remains to light up the rest of ws-trust, but the scenario described by this issue works in that branch, both sync and async

Is BuildChannelFactoryCore going to be implemented in version 2.0 of dotnet core?

Is there a branch available where this is implemented which I could use as part of a project I am working on?

@roncain, I can't find your ws-trust branch from the link provided. Was this merged with the WCF Web Service Reference Provider? I am still getting the "TransportSecurityBindingElement.BuildChannelFactoryCore is not supported" message.

It's a surprise to me too the ws-trust branch is gone. The work is neither completed nor merged, but we will try to restore the ws-trust branch.

Hello , I am not getting way to call WCF service which is third party API i need to call it from Aws Lambda Core Project and i am getting error like "TransportSecurityBindingElement.BuildChannelFactoryCore is not supported." I have attached error picture that it will make you more clear. please give me any solution or idea it ll be appreciable ..thanks in advance.
error

Any updates on restoring the ws-trust branch?

@mconnew can you please help to restore ws-trust branch from #1591?

I am curious on the progress of the restore. Thanks

I would like to know when WS-trust bindings will be supported for .NET Core

Does anyone know of any workout arounds for .net core applications for this issue? Thanks

Frustrating that this was supposed to have been fixed long ago, but the fix vanished and was never restored. Is there any near-term resolution for this?

Hey everyone, any update on this for the 2.1?
Or it's gonna be a feature for the 2.2?

Any news on this, or a workaround? It is a very common scenario that has been blocking us for a good while. We have many projects depending on usernameovertransport. Even the docs states it should work with .net core

Is there an underlying issue that we can track to see the state of work? Is there something that we can provide to help it being prioritized? Thanks!

@StephenBonikowsky @mlacouture

We are limited by the lack of System.IdentityModel classes and I am currently actively investigating multiple options to work around this limitation. The option I'm currently attempting to prototype is to build on top of System.Security.Cryptography.Xml.SignedXml instead of the internal SignedXml implementation inside of System.IdentityModel.
As regards the docs, it's a difficult thing to express how things are in the docs for WCF as there's a central repository of docs for all platforms. .Net Framework and .Net Core share the same documentation and the only difference between them is a flag which says whether that API exists on the platform. The API is there on .Net Core even though it is not functional so it gets listed as being present on .Net Core.

Thank you for the response @mconnew . Do you think it might be feasible to setup a quick and high-level markdown showing the operating state of the different security modes. I think it would help a lot of people, including me, to have a glance at which scenarios are working on .NET Core and which are not, instead of having to crawl the github issues or getting burned by a PlatformNotSupportedException. Right now I'm wondering which binding I can fallback to if UserNameOverTransport is not working.

I can help to format it in a table or something if you have the infos. Cheers.

Hey @mfjerome we have a chart of supported features that we update with each release.
https://github.com/dotnet/wcf/blob/master/release-notes/SupportedFeatures-v2.1.0.md

It doesn't go into great detail but it does show that Message Security isn't currently supported.

@mconnew Encouraging to hear that work on this is underway. I'm running into this issue with the VMware vSphere 6.0 API - if you have a working prototype I'd be happy to give it a try.

Linking to parent issue #8 as this is one scenario of TransportSecurityWithMessageCredential

Code is in, needs unit tests.

@imcarolwang @HongGit
Carol, could your team take a look at PR #3657 and create unit tests for what was added please.
We'll use this Issue to track getting those tests in.

Unit tests done. Thanks @imcarolwang

3684

It's actually #3688 . :)

I'm having the same issue using .Net Core 3.1.201 on Windows 1809 build 17763.1158
Solved in #4242

Was this page helpful?
0 / 5 - 0 ratings