I have a silverlight application hosted on an asp.net web application including a WCF SOAP web service. The application is running under an HTTPS://... link using SSL. When I deploy it on our test server running IIS 7.5, everything works fine and as expected.
I also have a second web application including a RESTful WCF service which runs using SSL on both my local machine and the mentioned test server (but no silverlight client in this case).
My problem is that the silverlight client receives a Security error when getting responses from the SOAP service in the part where deserialization should take place, but only on my local machine.
return base.Channel.EndGet...(IAsyncResult) // <-- exception reported here:
System.ServiceModel.CommunicationException: An error occurred while
trying to make a request to URI 'https://localmachinename.domain.com:8000/Service.svc'.
This could be due to attempting to access a service in a cross-domain way without a
proper cross-domain policy in place, or a policy that is unsuitable for SOAP services.
You may need to contact the owner of the service to publish a cross-domain policy file
and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be
caused by using internal types in the web service proxy without using the
InternalsVisibleToAttribute attribute. Please see the inner exception for more
details. ---> System.Security.SecurityException --->
System.Security.SecurityException: Security error.
at System.Net.Browser.BrowserHttpWebRequest.InternalEndGetResponse(IAsyncResult asyncResult)
at System.Net.Browser.BrowserHttpWebRequest.c__DisplayClassa.b__9(Object sendState)
at System.Net.Browser.AsyncHelper.c__DisplayClass4.b__0(Object sendState)
--- End of inner exception stack trace ---
at System.Net.Browser.AsyncHelper.BeginOnUI(SendOrPostCallback beginMethod, Object state)
at System.Net.Browser.BrowserHttpWebRequest.EndGetResponse(IAsyncResult asyncResult)
at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelAsyncRequest.CompleteGetResponse(IAsyncResult result)
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.Remoting.RealProxy.Invoke(Object[] args)
at proxy_2.EndGetTypes(IAsyncResult )
at NameSpace.ClientClass.ServiceContractInterfaceImplementation.EndGetTypes(IAsyncResult result)
My clientaccesspolicy.xml for the SOAP service looks like this:
<?xml version="1.0" encoding="utf-8" ?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="SOAPAction">
<domain uri="*" />
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
Any hints what I'm doing wrong?
The deployed application runs fine on our test web server.
Dec 06 2012: The problem still persists. Some updates / more information:
The web service uses windows authentication and impersonation. The only difference between test server and local machine is that the application pools run under different identities which in both cases is a technical domain user. The only difference I've found is that the user on my local machine was not granted the "Trusted for delegation" flag in Active Directory. So I assumed it could be a Kerberos problem. However, when I run my restful WCF service and client, this never was a problem. Besides, using a windows forms client for the SOAP service, everything runs fine on my local machine and developing/debugging is just possible as intended.
So it has to be a Silverlight problem.
What I do not get is, assuming this dreaded security error results from a crossdomain policy problem as it does in most cases, where are those domains crossed? Everything should be happining on the local machine, no other services are called. This shouldn't happen using IIS Express, should it?
Anybody able to help?
The clientaccesspolicy.xml should be placed in wwroot folder and also include crossdomain.xml
If you have multiple startup project in solution make sure you are running your Service and proper Silverlight project. I had two silverlight projects and was starting the wrong one that didnt contain clientaccesspolicy.xml.
Related
When trying to access my WCF service it is throwing following exception
The HTTP request was forbidden with client authentication scheme 'Anonymous'.
Inner Expeption: The remote server returned an error: (403) Forbidden.
Other observations:
It was working earlier
Same application when I set up on other system there is not error.
Using windows application from my system itself it works fine.
Situation:
WCF service is hosted in remote DEV server and I add as service reference in my web app.
For now Web app which consumes service is running from VS not by hosting in IIS
A real mess. Did anyone faced such situation? Please share with me. I google about the issue but non of them are helpful.
Check the application pool in which the service is hosted. If Windows authentication is turned on over there, then include it in the manifest xml file.
<system.web>
<authentication mode="Windows" />
</system.web>
For Reference : Click here
It could be that windows authentication is turned on on your local machine but not in IIS.
Double check the app pool your service is running under. Also, make sure the app pool is running integrated mode and that the version is correct.
See this article specifically step one.
An error occurred while trying to make a request to URI:
'http://localhost:8732/Design_Time_Addresses/WCF/Service1/'. This
could be due to attempting to
access a service in a cross-domain way without a proper cross-domain
policy in place, or a
policy that is unsuitable for SOAP services. You may need to contact
the owner of the service
to publish a cross-domain policy file and to ensure it allows
SOAP-related HTTP headers to be
sent. This error may also be caused by using internal types in the web
service proxy without
using the InternalsVisibleToAttribute attribute. Please see the inner
exception for more
details.
the error appears when result returned from the wcf
I consumed this wcf via console, website, win forms and it works properly
I use 2 xml files in the WCF library :
clientaccesspolicy.xml
crossdomain.xml
It used to make my brain hurt too.
I figured out for my use I needed this file:
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="SOAPAction">
<domain uri="*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>
named clientaccesspolicy.xml
The trick is that is has to be at the root of your web server. That being said you need to be able to browse the file. In your case located at:
http://localhost:8732/clientaccesspolicy.xml
If you cannot see the file silverlight will always complain and boy does it complain whenever it can!
I should point out that my policy file is not restrictive, so use it wisely.
Oh, that problem. Besides the crossdomain, you cannot run the debugger from VS2010 which is what i'm gather from that localhost URL. Try publishing silverlight app on the domain or server that your WCF is on. For example, if your web service is on http://10.xx.xx.xx/sites/myWCF, publish your silverlight app on http://10.xx.xx.xx/sites/MySilverlightApp. You're debugger is going to run as http://localhost:somePort which is definitely going to give you problems even with a cross-domain policy file. Apart from that, ensure that you config file for your web.service is correct. Ensure all the interfaces have endpoint bindings and there is a host on the main service location(sounds obvious, but is a common error).
I have a set of WCF Services Hosted in IIS7. I'm in the process of moving the services to a different folder in order to start specifying version and environment in the URL. For example:
http://myserver/MyServices/ServiceA.svc
Becomes:
http://myserver/MyServices/QA/1.1.0/ServiceA.svc
I configured the new folder to be an application in IIS, and set it up to run under the same service app pool we've been using. That has all worked fine, I am able to navigate to my .svc URL and view the WSDL or open up the endpoint in wcf test client. However, when trying to consume the service I am getting the following error:
The identity check failed for the outgoing message. The expected identity is 'identity(http://schemas.xmlsoap.org/ws/2005/05/identity/right/possessproperty: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn)' for the 'http://myserver/MyServices/QA/1.1.0/ServiceA.svc' target endpoint.
When I check the WSDL output, I noticed that the identity section seemed to leave out the identity of the app pool, which it usually includes:
<Identity xmlns="http://schemas.xmlsoap.org/ws/2006/02/addressingidentity">
<Upn>myappuser#mydomain.local</Upn>
</Identity>
After trying to redeploy and reconfigure the app in IIS, I was able to get the identity to appear in the metadata for only some of the services. Other services still don't include it, which is even more strange than before. There are zero configuration differences between the original stack and the new stack in IIS as far as I can tell. What sorts of issues could I be running in to that would causes these types of identity issues?
The issue was caused by trying to nest the new service stack web application inside of the existing service stack web application. I think that may have caused some confusion for IIS when services in the sub-application were exposing endpoints to the same contracts that the root web application (although in theory this should work just fine). I simply had to move the new service stack into a separate folder structure. Once I did that, I had no problems getting the app pool identity to be exposed in the metadata.
I have one worflow service named GetDataWorkflowService.xamlx that I want to use in Silverlight.
When I add a service reference to my application, it gives a message 'This Operation is not supported for the relative URI.' It still adds the reference, however.
When I use the referece:
Servicelient proxy=new ServiceClient();
proxy.GetDataCompleted += (o, a) => Debug.WriteLine("Result is " + a.Result);
proxy.GetDataAsync(123);
I get the following error:
An error occurred while trying to make a request to URI 'http://localhost:1234/GetDataWorkflowService.xamlx'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.
I don't understand what's happening.
A few things:
What happens if you use the WCF Test Client to call GetData()? Do you get an error or does that work just fine. If you get an error here concentrate on the server parts.
What happens if you set a service reference from a console application and call your workflow service. Same error or does that work?
Is the workflow service hosted in the same web site as the Silverlight client? If not do you have the cross domain policy files setup correctly.
Assuming the WCF Test Client works. Open up fiddler and compare the request from your Silverlight client with that from the WCF Test Client. What is different?
Enable tracing on the server to see if there are any exceptions or warnings that might provide more insight to what is wrong.
Check your startup project to be sure you are starting a web project and not the Silverlight project. For more details see Troubleshooting Workflow Services / Silverlight on my blog
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.