We briefly mentioned client access policy in Chapter 4, Implementing Application Logic, when we discussed cross-domain networking. The reason behind Silverlight's requirement for the client access policy file is to prevent network threats and to give administrators more control over which resources a remote client, such as Silverlight, is allowed to connect to.

Silverlight 5, which was recently released, adds a new feature of creating in-browser trusted applications, which aren't restricted by the security policy (just like trusted out-of-browser applications). In Silverlight 4, the only way to connect to a service, which doesn't expose the client access policy is to create a web service of our own (using WCF or any other technology) on the same domain as the Silverlight application and let it handle the cross-domain call.

Every time Silverlight makes a cross-domain call, either by WebClient or by referencing a service, the Silverlight runtime will first try to download the client access policy file—clientaccesspolicy.xml from the root of the called domain. If the file is not found, if it has an invalid MIME type, or if its XML is invalid, the Silverlight runtime will fall back to looking for Adobe's Flash policy file named crossdomain.xml. If both files fail then the call will not get through and will result in a SecurityException of access denied.

A typical implementation of the clientaccesspolicy.xml file looks as follows:

<?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>

Pay attention to the policy node. That's where the security action happens. Under the allow-from node, we can specify which domains are allowed to access the resource. Specifying a * means everyone, no matter from which domain, can access the resource.

The grant-to node provides us a way to specify which resources are affected by the policy file. We can specify a specific resource, such as /api/items.svc, and only that web service will be affected by the policy file. Specifying / means everything under the root of this domain is affected by this policy file. Make sure that if you do use the general rule of /, you should also specify true for the include-subpaths attribute. If you do not set the attribute to true, the policy file will only affect the resource running at the root level of the domain.

The crossdomain.xml file is much simpler and easier to understand. A typical implementation of this file is as follows:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
<allow-http-request-headers-from domain="*" headers="SOAPAction,Content-Type"/>
</cross-domain-policy>

allow-http-request-headers-from allows us to specify, using the domain attribute, which domains are allowed to access the resource. The headers attribute allows us to specify what headers are allowed through. For SOAP-based services for example, we will use the SOAPAction header.

Don't forget to include either of the files in your project if you are planning to use Silverlight to make cross-domain calls. Always make sure you have the policy files in the root of the domain and not in a subfolder. Checking for these files before deployment will save you a bundle of headaches later.