Cross Domain Policy

Here are a few articles about Silverlight cross-domain communication that got bumped for announcements a few months back and I forgot to reinsert them into the normal posting order. Hopefully they are still timely enough to be useful.

Silverlight applications are run under a security policy system to prevent some common networking threats that can occur with untrusted or low-trusted application code. This type of security policy system is a standard part of executing applications from a web browser, where you may be downloading application code from a variety of sources without a lot of consideration beforehand of whose code you’re executing.

One aspect of the security policy system is that applications executing in the web browser are limited to creating connections back to the site of origin. The site of origin refers to the host and port pair from which the application code was downloaded. However, it’s common for a web service client application to want to interact with network resources at many different locations. Permission to access a network resource that is not the site of origin is defined by a cross-domain policy file.

The cross-domain policy file is a file called clientaccesspolicy.xml located at the root of the requested target domain. This policy file defines an access policy in terms of sites of origin that requests are allowed from and the permissions granted to those locations.

Here’s a quick example of an extremely permissive cross-domain policy file to demonstrate the syntax.

<?xml version="1.0" encoding="utf-8"?>
<allow-from http-request-headers="*">
<domain uri="*”/>
<resource path="/" include-subpaths="true"/>

I’ll go into more detail about cross-domain policy files next time.

Next time: Defining Cross Domain Policy

Comments (2)

  1. Last time I talked a bit about the need for a cross-domain access policy in the Silverlight security

  2. An index of all of the different standard stores for certificates used to authenticate with a service.