Home > Products > BPC PowerForms - Silverlight > Knowledge Base > General > Network Security Access Restrictions in Silverlight

Network Security Access Restrictions in Silverlight

Cross-domain service access in Silverlight

Silverlight uses services as its primary source of retrieving data across domain boundaries. To prevent applications from launching malicious attacks on web sites, Silverlight uses opt-in cross-domain access. A web site needs to be allowed to receive and respond to requests being made from a particular domain. This safe-guarding role is being undertaken by a clientaccesspolicy.xml file.

Suppose we have a Silverlight application hosted on http://sharepointSite.com/ (where the XAP file is deployed).  This application has a service backend that retrieves data from http://sharepointService.com/.  These are obviously located on two separate domains and we have a cross-domain issue. By default, this scenario will not work.  We need to create a clientaccesspolicy.xml file on the http://sharepointService.com/ site that will allow calls from http://sharepointSite.com/.  The file must be copied on the root of the site (http://sharepointService.com/clientaccesspolicy.xml). On IIS, we would simply copy the clientaccesspolicy.xml file on the root of our website (default IIS: c:\inetpub\wwwroot folder).

The clientaccesspolicy.xml file is located where the service is hosted.  This is a very important point. The clientacesspolicy.xml NEEDS to be deployed on the server hosting the WCF service so that Silverlight can properly consume it.

Example clientaccesspolicy.xml file that grants all domains access:

Example clientaccesspolicy.xml file that grants access ONLY to sharepointSite.com:

Silverlight Policy File Format

• allow-from

Nested within this part of the policy lie all the domains/sites which are allowed access to Silverlight resources. All domains not listed in the policy will be denied access. If allow-from is left empty, then no sites will be allowed access.

• http-request-headers

By Default, no headers are allowed. Wildcard character “*” can be used to declare that all request headers can be sent. Example http headers: MyHeader, X-API-*

<allow-from http-request-headers="MyHeader, X-API-*">

• domain uri


<domain uri="*" />

<domain uri="http://*" />

<domain uri="http:// sharepointSite.com:8080"/>

<domain uri="http://sharepointSite.com" />

<domain uri="http://*.sharepointSite.com" />

Used to list the domains that are allowed to access the Silverlight sources defined in the clientaccesspolicy.xml policy file.

The following types of wildcards are accepted:

1. Wildcard character '*' can be used alone to declare that all connections are allowed from same Silverlight schemed applications hosted on any domain.

2. "http://*" accepts all connections from HTTP applications on any domain.

3. Port numbers can also be used to restrict access, defining that connections from the said port will only be allowed access.

4. '*.' is defined as the sub domain wildcard option followed by the rest of the hostname. This will allow connections from Silverlight applications hosted on any sub domain of "sharepointSite.com ".

• grant-to

Defines the server’s resources affected by the policy.

• path, include-subpaths

It refers to a specific path that can represent a web service or a file.

<resource path="/test" include-subpaths="false"/>

"include-subpaths" specifies whether sub-paths of the defined resource path are allowed access. A "true" value will allow access to a designated path and any appended sub-paths. A "false" value will only allow a match to the exact path designated by the path attribute. The default value is false.

For the above resource path, these resources can be accessed from Silverlight HTTP applications hosted on any site:



For the above resource path, these resources cannot be accessed:








The Silverlight policy file for connections can also be used for sockets:

<socket-resource port="4502-4506" protocol="tcp" />