I'm working on an WCF-based client/server application (WCF is self-hosted, not in IIS).
The WCF service has an operation to upload a chunk of data to the server. The contract roughly looks like this:
void UploadChunk(int clientId, byte[] chunk);
We are using Windows Authentication (Kerberos/NTLM) so we cannot use streaming here.
The binding looks like this (client- and server-side):
new BasicHttpBinding
{
Security = new BasicHttpSecurity
{
Mode = BasicHttpSecurityMode.TransportCredentialOnly,
Transport = { ClientCredentialType = HttpClientCredentialType.Windows },
},
MaxReceivedMessageSize = 0x7fffffff,
ReaderQuotas = { MaxArrayLength = 0x800000 },
};
The client talks to the service via proxy objects derived from System.ServiceModel.ClientBase<TChannel>.
All of this works perfectly fine, but we observed that the WCF client sends each HTTP request twice, once without auth header and once again with the correct auth header. This is problematic because the requests will be pretty big and this behavior causes the request size to be two times the actual chunk size.
I already found out (https://weblog.west-wind.com/posts/2010/Feb/18/NET-WebRequestPreAuthenticate-not-quite-what-it-sounds-like) that setting WebRequest.PreAuthenticate to true remembers the auth header and reuses it for subsequent requests.
However from what I've seen up to now WCF does not expose a mechanism to modify the WebRequest instance.
Is there any solution for this problem`?
For Windows Authentication there will always be a challenge response (401) for your first request .
If you're in control of all clients I think the most practical solution is to implement an operation with a minimal payload.
Operation void IsAuthenticated() should do. For each client proxy instance you would then call IsAuthenticated before UploadChunk.
The IsAuthenticated request would get you over the 401 challenge response without sending the large payload but will authenticate the connection. Subsequent requests for that connection will not be challenged.
Edit :
The behaviour I described seems to only be applicable with IIS 8. So I took a closer look with two http.sys traces, one for an IIS hosted service and one for a self hosted service.
The IIS hosted service seems to utilize some sort of optimization with regards to authentication. The first request for the connection is authenticated using the Authenticator Sspi Authenticator. Subsequent requests are authenticated using the Fast Authenticator.
None of these events are present in the self host trace which leads me to the conclusion that self hosting is not optimized for Windows Authentication.
http.sys - trace IIS
http.sys - trace self host
Then I found this blog entry that proposes a solution using NTLM, a custom binding and the unsafeConnectionNtlmAuthentication setting for the HTTP transport. If you're willing to only use NTLM and the security concerns highlighted in the documentation are not a concern this seems to provide the behaviour you're looking for as per the http.sys trace.
http.sys trace - self host with custom binding
For the server use binding
<customBinding>
<binding name="myBinding">
<textMessageEncoding messageVersion="Soap11" />
<httpTransport authenticationScheme="Ntlm" unsafeConnectionNtlmAuthentication="true"/>
</binding>
</customBinding>
For your client you can use a regular basicHttpBinding with Ntlm security:
<basicHttpBinding>
<binding name="BasicHttpBinding_ITest">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Ntlm" />
</security>
</binding>
</basicHttpBinding>
Use HttWebRequest to call WCF service, creating full SOAP message manually. That will allow to set PreAuthenticate to true. Make first call with no payload, Authenticate(). Then make request with payload.
Related
I'm trying to write a client against a customer's SOAP webservice, using VS2013 and WCF. The webservice itself is behind their firewall, so they've established a proxy that I'm trying to contact. (The proxy seems to be implemented using MuleSoft's ESB, which may or may not be relevant.)
I've been given an https: url, and a username/password. When I load the url into a browser, I'm prompted for the username/password, and then I see the .wsdl. The .wsdl specifies an internal url that I can't access, but I figure that's for the actual site.
When I create a Service Reference in VS2013, using the proxy URL, I'm prompted for the username/password three times, then I get a proper client, settings in app.config, etc.
The generated bindings in the app.config are for a basicHttpBinding with security mode Transport, and an endpoint address pointing to that inaccessible internal url.
So, from the generated bindings, I:
Replace the inaccessible internal url with the proxy url I've been given.
Change the security mode to "TransportWithMessageCredentials"
<bindings>
<basicHttpBinding>
<binding name="MyCustomersServiceSoapBinding">
<security mode="TransportWithMessageCredential" >
<message clientCredentialType="UserName" />
</security>
</binding>
<binding name="MyCustomersServiceSoapBinding1" />
</basicHttpBinding>
</bindings>
Replace the ClientCredentials with username and password:
using (var client = new MyCustomersServiceClient())
{
var loginCredentials = new ClientCredentials();
loginCredentials.UserName.UserName = "ausername";
loginCredentials.UserName.Password = "apassword";
var defaultCredentials = client.Endpoint.Behaviors.Find<ClientCredentials>();
client.Endpoint.Behaviors.Remove(defaultCredentials);
client.Endpoint.Behaviors.Add(loginCredentials);
var myData = new MyData
{
};
var result = client.receiveData(myData);
}
When I run it, I get an exception:
Could not establish secure channel for SSL/TLS with authority 'xxxxx.com'.
Browsing around, most of what I find suggests problems with ssl certificates, but I'm not sure that makes sense. If that were the case, I'd expect to see issues when I view the .wsdl through the browser. And I thought that by removing the default client credentials, I'd be bypassing the certificate check. And I am seeing a few posts about more obscure problems that result in this same error message.
I've turned on SOAP message logging, but that's provided me with no information. It shows the failed outgoing message, but nothing of use.
So I've been looking at the traffic in Fiddler. I see two messages, an HTTP message to "Tunnel to" with Result 200, and an HTTPS message to the proxy url with Result 401.
At this point, I see two possibilities:
I need to install an SSL certificate, the way the error message would suggest, or
the problem is simply that I'm not providing the username/password to the service in a way that it understands, and it's rejecting my attempt to connect.
I'm leaning towards the latter. My problem? I know nothing about the system that's hosting the service. I'm passing username/password in what I thought was the usual mechanism for WCF, and it's not working.
So, finally, the questions:
Have I misled myself, and I do need to be messing about with SSL certificates?
If not, what do I do in WCF to pass a username/password to an HTTPS webservice, hosted by MuleSoft
ESB? (Mule EE Core Extensions/3.5.1, if that helps).
Not sure if the issue I encountered shares the same cause as your issue, but just in case I can help someone with this, adding requireClientCertificate=true solved my problem:
<bindings>
<customBinding>
<binding name="bindingName">
...
<httpsTransport requireClientCertificate="true"/>
</binding>
</customBinding>
</bindings>
I had the same error message, but the web service I'm consuming is over HTTPS and requires a SSL certificate as authentication.
Many endpoints have been disabling TLSV1.0 and TLSV1.1 recently
try:
CURL https://<<service host>> -v -TLSV1.0
and
CURL https://<<service host>> -v -TLSV1.2
For instance, https://www.comodo.com doesn't allow TLSV1.0 or TLSV1.1 but does allow TLSV1.2.
I have a WCF service hosted by a Windows Application of my own. I want the service to authenticate the client at the transport level using the client's Certificate and when the client communicates with the service, it must pass its Kerberos Ticket of the client's user account. Looking around on the internet i found this configuration for the service:
<bindings>
<customBinding>
<binding name="Kerberos (MsgHeader) over Transport (Certificate)">
<textMessageEncoding messageVersion="Soap11" />
<security authenticationMode="KerberosOverTransport">
<secureConversationBootstrap />
</security>
<httpsTransport requireClientCertificate="true" />
</binding>
</customBinding>
</bindings>
They say that this configuration worked with Microsoft's help. Now, i tried to duplicate this configuration through code, so i used the following snippet:
BindingElementCollection elementCollection = new BindingElementCollection();
elementCollection.Add(SecurityBindingElement.CreateKerberosOverTransportBindingElement());
elementCollection.Add(new TextMessageEncodingBindingElement() { MessageVersion = MessageVersion.Soap11 });
elementCollection.Add(new HttpsTransportBindingElement() { RequireClientCertificate = true });
return new CustomBinding(elementCollection);
I configured the endpoint with this binding along with a valid certificate bound to the port. I then added a service reference at the client project in Visual Studio.
To this end, everthing is working great! I also configured the client to send its certificate when communicating with the service, this also worked fine. However, when I try to invoke any method of the service, I get the following error:
An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail.
And when I examined the inner exception, I found the following error:
An error occurred when processing the security tokens in the message.
Any help, please? Do i need to configure the client further to send its Kerberos token, or what?
P.S. The service and client machine clocks are synchronized. In addition, the service and the client are on two different machines joined to a domain.
I have a WCF service deployed to IIS on my local machine configured for Win Auth
<basicHttpBinding>
<binding name="NewBinding0">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" />
</security>
</binding>
</basicHttpBinding>
I have a test WPF project that call it which works just fine.
I tried to create a Windows Store app and use my logged on (domain) user to call the service but can't get this to work
My user is a domain user and I can see it by calling Windows.System.UserProfile.UserInformation.GetDomainNameAsync()
If I implement the partial ConfigureEndpoint and set the credentials explicitly I can get to the service just fine -
static partial void ConfigureEndpoint(System.ServiceModel.Description.ServiceEndpoint serviceEndpoint, System.ServiceModel.Description.ClientCredentials clientCredentials)
{
clientCredentials.Windows.ClientCredential = new System.Net.NetworkCredential("<domain>\\<username>", "<password>");
}
but if I simply put
clientCredentials.Windows.AllowedImpersonationLevel = System.Security.Principal.TokenImpersonationLevel.Impersonation;
I get the following error
{"The HTTP request is unauthorized with client authentication scheme 'Ntlm'. The authentication header received from the server was 'Negotiate,NTLM'."}
I have configured the Enterprise Authentication and Private Networks (Client & Server) capabilities
What do I need to do to call the service in the context of the logged on domain user?
(I've found this unanswered question which probably refers to the same issue, but no answer yet?
Turns out that the issue was a result of me hosting the service (for testing) on my laptop and calling it using 'localhost'.
I've deployed the same service to another server on our domain and updated the endpoint address in the app and it all worked just fine.
Looks like there's a restriction on windows store app calling services on localhost
Not quite sure why this is working fine if I provide the credentials explicitly and does not if I just carry the logged on user though..
I have WCF service that uses wsHttpBinding and authentication with certificate.
I run this service on multiple machines and my firewall routes the request to the different servers.
The problem is when the client open proxy and works with one server and on the next call the firewall routes the request to another server I get an exception on the client:
An unsecured or incorrectly secured
fault was received from the other
party. See the inner FaultException
for the fault code and detail.
With inner Exception:
The message could not be processed.
This is most likely because the action
'http://www.site.com/api/contract/IService/DoAction'
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.
Is there any solution?
Use : establishSecurityContext="false"
<security mode="Message">
<message clientCredentialType="Certificate" negotiateServiceCredential="false"
algorithmSuite="Default" establishSecurityContext="false" />
</security>
I am attempting to consume an intranet web service with WCF. I added reference to the service via the Add Service Reference feature in VS2008. In doing so I was prompted for network credentials to access the service which I provided and the service reference was added.
I then wrote some code that I would expect to fail as it doesn't pass credentials along with the call of the service:
FooServiceClient proxy = new FooServiceClient();
bool isValid = proxy.ValidateBar(baz);
When I use this code I receieve the exception:The HTTP request is unauthorized with client authentication scheme 'Negotiate'.The authentication header received from the server was 'Basic realm="Kerberos"'.Which is the same error I receieve when using either of the two code examples below.
FooServiceClient proxy = new FooServiceClient();
proxy.ClientCredentials.UserName.UserName = "USERNAME";
proxy.ClientCredentials.UserName.Password = "PASSWORD";
bool isValid = proxy.ValidateBar(baz);
or
FooServiceClient proxy = new FooServiceClient();
NetworkCredential creds = new NetworkCredential("USERNAME", "PASSWORD");
proxy.ClientCredentials.Windows.AllowedImpersonationLevel =
TokenImpersonationLevel.Identification;
proxy.ClientCredentials.Windows.AllowNtlm = false;
proxy.ClientCredentials.Windows.ClientCredential = creds;
bool isValid = proxy.ValidateBar(baz);
My gut tells me that I have the security mode configured incorrectly. According to the server manager the end point that I am attempting to bind to is looking for a Basic Http Credential via SSL. Which after reading about WCF-BasicHttp Transport Properties lead me to believe that I should use this configuration:
<security mode="Transport">
<transport clientCredentialType="Windows" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
Unfortunately, I continued to receive the same error.
Again, I am sure my troubles have to do with a configuration issue on my part as I've previously consumed this service in other projects with the outdated Add Web Reference.
You have to really understand what the endpoint on the other end is configured under. If it is self hosted and running under SSL then it should be Transport, but if its running under IIS with SSL then it could possibly be TransportWithMessageCredentials and the Transport credentials might be "None".
It is very tricky to get this to bind correctly.
As far as the Exception you are getting
The provided URI scheme 'https' is
invalid; expected 'http'. Parameter
name:
When you use TransportCredentialOnly you have to use HTTP binding rather than HTTPS, and I am sure you didn't change your endpoint address to HTTP because that's not what the service reference is.
What binding are you using for your intranet scenario? The recommended best practice would be NetTCP with transport security and Windows credentials (assuming all your callers are intranet-clients with an account in your corporate Active Directory)
That would avoid any of the http/https mess.
However, to host netTcp, you either needs WAS (Windows Process Activation Server) which is part of IIS7 and that only runs on Windows Server 2008 (Vista Server) or 2008 R2 (Win7 Server). Or you need to host your service yourself in a e.g. NT Service.
Lots of information still missing! Please update your question accordingly. Thanks!
The below WCF binding configuration ended up being the solution.
<security mode="Transport">
<transport clientCredentialType="Basic" proxyCredentialType="None"
realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>