I'm trying to do HMAC-SHA256 authentication for my WCF webservices.
After much reading about HMAC-SHA on the web, I started to apply them into my project.
Now that I've successfully encrypt the message on the client-side, but how do I go about authenticating the request before the request entering the WebMethods?
I suppose I should add a HttpModule to tap into the Init() event and do validation there?
But as soon as I added the HttpModule to my WCF project and configure the web.config, I'm getting error saying:
An error occurred while receiving the HTTP response to http://localhost:61884/MyService.svc.
This could be due to the service endpoint binding not using the HTTP protocol.
This could also be due to an HTTP request context being aborted by the server (possibly due to the service shutting down).
See server logs for more details.
Am I right about using HttpModule in this context?
My web.config, just in-case
<system.web>
<compilation debug="true" targetFramework="4.0" />
<httpModules>
<add name="HttpAuthenticationModule" type="WcfService.HttpAuthenticationModule" />
</httpModules>
</system.web>
I figured that HttpModule doesn't work for self-hosted WCF services that launched from VisualStudio. After I host the WCF service in IIS, HttpModule is hitting breakpoint at BeginRequest() as what I expected now.
Hope this helps those who face the same problem.
Related
I have a very old asmx webservice. Due to restrictions i cannot call this service directly. So i am creating a WCF web service, which will act like a proxy between the client and the actual web service. My client application, which was actually calling the asmx web service is now going to call the wcf service. Also this way, i should not make any code changes in my client.
I created the service successfully. While trying to access from my client, i get this message. The message with Action cannot be processed at the receive, due to a ContractFilter mismatch at the EndpointDispatcher.
I tried to match my proxy web service to match the existing webservice. May be i am missing something. Please help.
The ContractFilter mismatch is almost always due to versioning problems. You could try to update your "Connected Services" reference to WCF Service or manually rerun SvcUtil or use ChannelFactory of the ServiceContract of your WCF Service by putting this in a shared class library for the Client and the WCF service. You can also add more logging in WCF and use the util SvcTraceViewer to see where it fails. Add the following to the web.config of your WCF service for example:
<system.diagnostics>
<sources>
<source name="System.ServiceModel.MessageLogging">
<listeners>
<add name="messages"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData="c:\logs\messages.svclog" />
</listeners>
</source>
</sources>
</system.diagnostics>
<system.serviceModel>
<diagnostics>
<messageLogging
logEntireMessage="true"
logMalformedMessages="false"
logMessagesAtServiceLevel="true"
logMessagesAtTransportLevel="false"
maxMessagesToLog="3000"
maxSizeOfMessageToLog="2000"/>
</diagnostics>
</system.serviceModel>
Then you can open up the .svclog file in SvcTraceViewer and see why it fails. But if the client call already fails, it is possible that you will not see any log item anyways. So moving your Service Contract to a Shared class library and let the client use a ChannelFactory will ensure that your clients are more up to date with the service. Now it is also possible that it is the WCF service that fails a call against the older ASMX service, then firing up Fiddler is perhaps the next step (or add more logging in the old ASMX service).
I have an ASP.NET WebApi application running locally using IISExpress that allows me to accept requests from any domain. I am doing this using a DelegatingHandler similar to the one provided one this blob post.
Locally this runs perfectly however after uploading to an Azure Website, I get the typical 'Origin http://localhost:8080 is not allowed by Access-Control-Allow-Origin.' under Chrome.
I've tried to debug this by adding trace statements into the Handler with no output and it seems like SendAsync is never being executed, almost as if IIS is responding to the OPTIONS request instead of passing it on to my application.
Has anyone come across anything similar going from development to production?
IIS (including the one in your Azure web site) has a default OPTIONS handler. You will need to remove it in Web.config. It answers the OPTIONS call before your message handler has an opportunity to respond.
<configuration>
...
<system.webServer>
<handlers>
<remove name="OPTIONSVerbHandler" />
...
</handlers>
</system.webServer>
</configuration>
i added
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" />
but it's giving me an error"
The service cannot be activated because it requires ASP.NET compatibility. ASP.NET compatibility is not enabled for this application
it seems like the WCF service has no HTTP context related to it? please help
It has check out the following link
http://msdn.microsoft.com/en-us/library/aa702682.aspx
and make sure you have added this tag in your web config
In a related post, I am having trouble connecting to a basicHttp endpoint and it seems that it is due to WCF impersonation issues when connecting to a downstream service. The funny thing is that it works fine when I replace the basicHttp WCF service with an ASMX web service. Both services use <identity impersonate="true" userName=".." password=".." /> from ASP.NET web.config file, but the ASMX service works while the basicHttp WCF service doesn't.
Does this seem likely to be some sort if Kerberos delegation issue between ASP.NET and WCF?
Or is there something that I can add to my WCF configuration to pass this impersonated user (note I am using framework 4, so I currently have almost no configurtation)?
Finally worked out that I needed to add <serviceHostingEnvironment aspNetCompatibilityEnabled="true"/> to the WCF part of the web.config file, and an AspNetCompatibilityRequirementsMode attribute to the implementation of the basicHttp endpoint. This will then call the downstream netTcp endpoint using the credentials defined in <identity impersonate="true" userName=".." password=".." />.
Trying to create an framework 4.0 WCF basicHttp service hosted by IIS (6) that is completely unauthenticated. Once deployed, I can successfully retrive the WSDL via a browser.
However whenever I try and connect to it via WCF Test Client or via a visual studio generated proxy, I'm getting "The server has rejected the client credentials.".
This still occurs when I add <security mode="None"/>, but my understanding is that this is the default anyway ...
In the IIS virtual directory properties I only have anonymous ticked, and in the web.config file <authentication mode="None"/> is set as well.
Any ideas?
Seems like the IIS site has anonymous authentication disabled. Check out this article on IIS 6 anonymous access configuration.
Turns out that the source of the exception was from an immediate attempt to connect to a downstream tcp service. As a workaround I ended up creating a plain jane webservice wrapper which successfully connects to the downstream service fine using a domain account specified in the <identity impersonate="true" userName=".." password=".." />.
Note, I've added a related question asking why one works and the other doesn't.