I have some collegues who have build a WCF Service. Their security settings are the following:
security mode="None"
transport clientCredentialType="Windows" proxyCredentialType="None" realm=""
message clientCredentialType="Windows" negotiateServiceCredential="true"
establishSecurityContext="true"
security
Does it makes sense to specify the security mode="None" and then specify transport/message security underneath?
This is just basically NO SECURITY at all - that doesn't make any sense at all - except for maybe development time :-)
If you have <security mode="None"> then anything you specify below is not taken into account - you could leave that out just as well.
It does no harm, the mode="None" value means none of the individual settings for either message or transport will be used.
Related
Im using this binding
<basicHttpBinding>
<binding name="abc_Windows" maxReceivedMessageSize="2147483647" messageEncoding="Mtom" transferMode="Streamed">
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
Im getting this error when calling it.
HTTP request streaming cannot be used in conjunction with HTTP authentication.
Either disable request streaming or specify anonymous HTTP authentication.
Parameter name: bindingElement
Im using windows authentication and need large files to be uploaded and downloaded via this service. What changes should i do to avoid this error? Does any other binding works with streaming and windows mode authentication?
Kindly help.
So what we have here is a fairly trivial WCF service with a bunch of operations. Now, all but one operation work just fine, but that single one fails with MessageSecurityException.
This particular method is just like any other method in this particular service: no fancy authentication or authorization attributes, no impersonation, no nothing. Just plain hit-the-DB-and-return-results kind of method. Security is set up as follows:
<security mode="TransportCredentialOnly">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName" algorithmSuite="Default" />
</security>
Yet whenever it gets invoked, it fails with
The HTTP request is unauthorized with client authentication scheme 'Negotiate'. The authentication header received from the server was 'Negotiate,NTLM'
I know this is a very open-ended question, but I hope someone has experienced the same.
I'm using WCF to create a Client-Server Application and I'm having some problems with authentication, with wsHttpBinding Windowsauthentication seems to be turned on by default. The webservice worked perfectly inside my network but when I installed it somewhere else I suddenly had all these securityexceptions.
Though I want the webservice to be encrypted with https, i dont want windows authentication.
Although I can't try it at the moment I've found this Configuration:
<security mode="Transport">
<transport clientCredentialType="Certificate" />
</security>
Which might do the trick. This is my "old" one:
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
<message clientCredentialType="Windows" negotiateServiceCredential="true" algorithmSuite="Default" />
</security>
This is the configuration on the client side which i dont quite understand cause anybody could just change this easily. I'd expect to configure this on the server side but i havent yet found out how.
Ideas?
You can disable it through IIS Authentication settings for the site hosting your WCF by turning it off there and leaving anonymous on.
http://technet.microsoft.com/en-us/library/cc754628(v=ws.10).aspx
I am trying to add WCF service with wsHttpBinding to soapUI.
I am using message security and it works with test client but SoapUI returns
An error occurred when verifying security for the message
Here is service configuration:
<wsHttpBinding>
<binding name="wsHttpSecure">
<security mode="Message">
<message clientCredentialType="UserName" negotiateServiceCredential="true"
establishSecurityContext="false" algorithmSuite="Default" />
</security>
</binding>
</wsHttpBinding>
Here http://www.soapui.org/SOAP-and-WSDL/applying-ws-security.html is a document but they say I need .jks file. I only have encoded public key value generated by SvcUtil in test client configuration file.
after a lot of research I found a solution on a blog.
You need to check the WS-A:To checkbox, located on the WS-A options tab.
After doing that, my problem was solved.
This is the blog containing the solution. Thanks David!!
this setting is not interoperable with soapUI:
negotiateServiceCredential="true"
change it to false
I have a binding configuration for wsHttpBinding defined as:
<wsHttpBinding>
<binding name="CustomAuthentication">
<security mode="Message">
<!-- Change to Message-->
<message clientCredentialType="UserName"/>
<!-- Change to UserName -->
</security>
</binding>
</wsHttpBinding>
When I generate my proxy code using svcutil and look at the app.config it generates for the client, I see this in the security section:
<security mode="Message">
<transport clientCredentialType="Windows" proxyCredentialType="None" realm="" />
<message clientCredentialType="UserName"
negotiateServiceCredential="true"
algorithmSuite="Default" />
</security>
I did not specify transport security in my service config, so why did it create a transport node with clientCredentialType="Windows". Is this by design and does it matter? I watched a video my Michele Leroux Bustamante and she said that you can't use Transport and Message, it will ignore one of them, so it doesn't matter if you specify both. I just want to know why it created it it in the client app.config
The reason is probably the same that svcutil and VS create huge config files for most services: They generate bindings/config with default settings, tweak them, and then serialize them into the config files, which means you get fairly extensive, verbose config files out of them because they include values (default or otherwise) for all properties in those configuration objects.