I'm trying to call an OData service (the OOTB one included with SharePoint 2010) that's secured with Windows Authentication from a Silverlight 5 app. In my research (specifically this post) I saw somewhere where it says:
Warning: While it is possible in Silverlight to do x-domain calls, so
long as the other domain has a correctly configured
ClientAccessPolicy.xml file, if the other domain needs you to logon,
there is no way to provide your credentials.
So my question is, is there really no way to call a OData service cross domain that's secured with Windows Auth? This seems to be what the above post is stating, but I find it hard to believe it just isn't possible...
Answering my own post to follow up on the research I found... Because NTLM is a negotation of each request, you can't do this very easily. I could override the generated DataContext proxy, but it would get pretty messy. Here's what the negotation looks like: innovation.ch/personal/ronald/ntlm.html
Related
Is it possible to access Rally's SOAP services from Silverlight? I am able to access the service from a .NET 2.0 proxy in a desktop application, but not via a WCF client proxy in Silverlight. I get the following familiar exception,
System.ServiceModel.CommunicationException:
An error occurred while
trying to make a request to URI .... 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 believe the problem is caused by trying to make a cross domain request from Silverlight, which requires a cross domain policy file installed on the server. If this is the case, why does the desktop application not require such a policy?
I'm not a Silverlight expert, but this looks like a cross-domain scripting/security sandbox that Silverlight imposes to make sure that Silverlight clients don't make requests to sites other than the server/host from which they were downloaded, unless the Silverlight client is specifically granted that right by the service provider/devloper. In the error message above:
"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."
I think the "owner of the service" means the owner of the Silverlight host, rather than the "external" webservice (in this case, Rally).
Desktop and/or console apps wouldn't have this same sandbox restriction. You would probably encounter the same issue trying to access another vendor's webservices via a Silverlight client.
You might find this Silverlight-specific thread:
Cross Domain Policy
Helpful for the specifics of how to setup and configure a Silverlight cross-domain policy file on your server.
Silverlight was built with security in mind. That means cross site scripting from the Silverlight application is turned off by default and must be enabled on a case by case basis. A .NET desktop application, on the other hand, generally has far greater security permissions and can call whatever web services, COM objects, and native APIs it pleases.
The way you work around this issue in Silverlight is to create a service on your server. The Silverlight client code calls your server side service which in turn calls a third party web service. The server side service can bet .NET, java, whatever. Web servers can generally call whatever they like -- problem solved.
Resolved this myself by using the extended permission features available in Silverlight 5. Since the xap is deployed on an internal internet, this solution was acceptable.
I'm trying to authenticate my silverlight application to get windows user name, which then I use to get some further information. Have looked it up, but the answers I found were about configuring the web service to get it. Is there a way, to get windows credentials strictly in Silverlight? I cannot find .Credentials, the only thing I see is .ClientCredentials, but apparently it doesn't show the required information. I am getting the string "System.ServiceModel.Security.UserNamePasswordClientCredential". It actually allows me to set up the name, not retrieve it. Also there is a web service called authentication.asmx, but as before it applies to other purposes. Neither do I have any web service I could reference to and configure them. Or am I missing something? Perhaps I can retrieve the windows credential by NTLM or Kerberos? I am using Visual Web Developer 2010 Express with Silverlight 5.
My Experience is that the Membership framework that is present in the asp.net world is not available in silverlight. In order to achieve something similar I had to implement a web service (WCF) that was directed at the domain's active directory (ldap) server. Silverlight is a very strict framework in terms of interoperability, its good for security but has some limitations.
I am not sure about your level of knowledge of the active directory but here is a link that deal with a lot of the possible operations and has sample C# code to go along.
http://www.codeproject.com/Articles/18102/Howto-Almost-Everything-In-Active-Directory-via-C#40a
I have a WCF.
I have a silverlight application.
I do not want anyone to be able to call the WCF except the Silverlight application.
I do not want to install any certificates on the client.
I do not want to hit any databases.
What would typically be the best way to do something like this?
You can address this using a cross domain policy file. Silverlight cannot connect to WCF services hosted on secondary domains without the implementation of this policy file.
Here are two links to get you in the right direction
http://msdn.microsoft.com/en-us/library/cc197955%28v=vs.95%29.aspx
Tim Heuer has a good writeup on the implementation of this file as well.
http://timheuer.com/blog/archive/2008/04/06/silverlight-cross-domain-policy-file-snippet-intellisense.aspx
To prevent a WCF services from being accessed by other applications you will need to implement authentication of some sort Here is a related post
How can I authenticate to a web service hosted in IIS that is secured with Integrated Windows Authentication?
Do I use HTTP headers to add username and pwd?
I am trying to call this web service from UNIX in C.
I'm rather a newbie to IIS myself, and I'm just starting to dance around this topic, but I saw your note and thought it was crazy that no one has answered in so long!
I believe that the typical way that windows authenticates is Kerberos. You may have to go through some gyrations to get the Windows Kerberos server to get you a ticket that you could put in the SOAP header. That is at least the direction in which I would start researching... but it could heavily depend on your Windows domain configuration. At the very least, you'll probably need to do quite a bit of poking into Windows Domain configurations and concepts.
We have a Silverlight app which we wrote which calls a Silverlight-enabled data service. The Silverlight app cannot require a login, as it is required to present data to the unauthenticated public.
We have some schmoe who took the time to examine our Silverlight app, one way or another figure out what service it is calling, and then wrote his own client to slurp off the data so he can post it on his site and pretend like it is his. We need to prevent this.
How can i limit my data service somehow to ONLY accept requests from my silverlight app? I tried using the allow-from domain uri setting in the clientaccesspolicy.xml file to limit access to the service only from the domain in which the silverlight app sits (say mydomain.com). This did absolutely nothing though, and the service is still serving up requests to clients from outside the domain. (I tested this by putting my SL app on a different domain under our control).
What is the proper/best/most effective way to limit the data service so only our app can use it? Thanks!!!
I'm using SL 3 and .NET 3.5.
The clientaccesspolicy.xml tells the Silverlight application which Webservice it can consume. Not preventing people accessing the Webservice.
You can try using a authentication login even though its not required. This prevents 'schmoes' accessing your webservice.
Also use Dotfuscator to prevent 'schoes' to disassemble your Silverlight application and acquire the login.
Silverlight webservice security follows the same patterns you'd use for ASP.NET security, especially services exposed to AJAX. The best way to do make use of ASP.NET's authentication.
RIA Services is an even better way to handle this. It rides on top of the ASP.NET authorization, but validates on both the client and server-side automatically to combat service spoofing. It let you take care of both client and server-side authorization by adding attributes to your methods indicating that the method requires authorized access, and by which groups or users if you need to be specific.
In addition to wire-side security and obfuscation, remember that clients can attach a debugger to Silverlight applications running in their browser. See this example from MSDN Magazine's Security IQ Test, November 2008.