Silverlight supports two types of security policy files:

• Flash policy file - the existing crossdomain.xml policy file used by Adobe Flash. This policy file can only be used by the WebClient and HTTP classes in the System.Net namespace. A Flash policy file must allow access to all domains to be used by the Silverlight runtime.

• Silverlight policy file - the Silverlight policy file that can be used by the WebClient and HTTP classes in the System.Net namespace and also by the sockets classes in the System.Net.Sockets namespace. This policy file has a different format than the Flash policy file.

Before allowing a connection to a network resource, the Silverlight runtime will try to download a security policy file from the domain that hosts the network resource. There are two different methods used to download the security policy that depend on whether the connection request was from a WebClient or HTTP class or whether the connection request was from sockets.

If the connection request was from a WebClient or an HTTP class to a cross-domain site, the Silverlight runtime tries to download the security policy file using the HTTP protocol. The Silverlight runtime first tries to download a Silverlight policy file with a name of "clientaccesspolicy.xml" at the root of the requested target domain using the HTTP protocol.

If the "clientaccesspolicy.xml" is either not found (the web request returns a 404 status code), returned with an unexpected mime-type, is not valid XML, or has an invalid root node, then the Silverlight runtime will issue a request for a for the Flash policy file with a name of "crossdomain.xml" at the root of the requested target domain, using the HTTP protocol.

HTTP redirects for the policy file are not allowed. A redirect for a policy file will result in a SecurityException of access denied.

If a "clientaccesspolicy.xml" file is returned, but contains an error other than the ones listed above, then no further cross domain requests to that domain will be allowed.

If a valid "clientaccesspolicy.xml" file is returned, that file will be used as the policy file for that cross-domain request for the remainder of the client session of the Silverlight application, and will be used to determine the validity of all subsequent cross-domain requests to that domain. 

The Flash policy file must allow connections to all domains for it to be used by the Silverlight WebClient and HTTP classes.

If a Silverlight policy file is returned (even if there is an error in parsing the file), it is used as the policy file for that cross-domain request and all subsequent requests to that server for the entire session of the Silverlight application. If a Silverlight policy file is not found, the Silverlight runtime then tries to download a Flash policy named "crossdomain.xml" at the root of the requested target domain using the HTTP protocol. The Flash policy file must allow connections to all domains for it to be used by the Silverlight WebClient and HTTP classes.

If the connection request was from sockets to the site (cross-domain or site of origin), the Silverlight runtime tries to open a connection using TCP to a well-known port (port 943) on the target site. If a TCP connection can be established, the Silverlight runtime sends the special string <policy-file-request/> to the server to request a Silverlight policy file. The Silverlight runtime then waits to receive a reply from the target site that contains a Silverlight policy file. If this Silverlight policy file is returned (even if there is an error in parsing the file), it is used as the policy file for that socket request and all subsequent requests to that target site for the entire session of the Silverlight application.

If the policy file retrieved is successfully parsed and grants permission, a connection is finally opened to the target host. If the policy file retrieved is invalid and cannot be correctly parsed, then connections to the network resource are denied by the Silverlight runtime and any connection requests will fail. If no policy file is found, then connections to the network resource are denied by the Silverlight runtime and any connection requests will fail.

One additional restriction on using the sockets classes is that the destination port range that a network application is allowed to connect to must be within the range of 4502-4534. These are the only destination ports allowed by a connection from a Silverlight application using sockets. If the target port is not within this port range, the attempt to connect will fail. It is possible for a target server to receive connections on a port from this restricted range and redirect it to a different port (a well-known port, for example) if this is needed to support a specific existing application protocol.

To deploy a security policy file for use by connections from the WebClient and HTTP classes, system administrators need to configure a web service for each IP address that is to provide the policy file definition and make the Silverlight or Flash policy file available over HTTP.

To deploy a security policy file on a server for sockets, system administrators need to configure a separate authentication service on port 943 for each IP address that is to provide the policy file definition.

The Silverlight policy file format is described below using a DTD.

<?xml version="1.0" encoding="ISO-8859-1"?>

<!-- A DTD for the Silverlight Policy File -->

<!ELEMENT access-policy (cross-domain-access)>

<!ELEMENT cross-domain-access (policy+)>

<!ELEMENT policy (allow-from)>

<!ELEMENT policy (grant-to)>

<!ELEMENT allow-from (domain+)>

<!ATTLIST allow-from http-request-headers CDATA>

<!ELEMENT domain EMPTY >

<!ATTLIST domain uri CDATA #REQUIRED>

<!ELEMENT allow-from http-methods CDATA>

<!ELEMENT grant-to (resource+)>

<!ELEMENT grant-to (socket-resource+)>

<!ELEMENT grant-to EMPTY>

<!ATTLIST resource path CDATA #REQUIRED>

<!ATTLIST resource include-subpaths (true|false) "false">

<!ATTLIST socket-resource port CDATA #REQUIRED protocol #REQUIRED>

<!-- End of file. --><!-- End of file. -->

The following table describes the possible ELEMENT entries.

The following table describes the possible ATTRIBUTE entries allowed on an ELEMENT.

The uri attribute of the domain element refers to the domains and specific Silverlight applications that are granted access to the paths specified by the <grant-to> element tags within the policy file. The included domain must exactly match the requesting domain. For example, a domain uri="http://contoso.com" only allows access from http://contoso.com, not from http://web.contoso.com.

There are three types of wildcards allowed:

1. A standalone '*' wildcard. This option is used to allow access to all domains of the same scheme. An HTTP service will allow all HTTP callers. An HTTPS service will allow all HTTPS callers.

2. An "http://*" literal wildcard. This option explicitly allows all HTTP callers, even if this is an HTTPS service.

3. A subdomain wildcard. This option uses a wildcard at the first segment of the path ("http://*.contoso.com", for example) that allows all subdomains of the domain specified. So for the example. http://web.contoso.com and http://mail.contoso.com would be allowed. Note that a uri path where the wildcard does not occur as a prefix (http://web.*.com, for example) is disallowed.

The Silverlight policy file allows connections to an HTTPS service using a cross- domain policy file. When an explicit allow-from attribute on a domain element is provided in the policy, that domain includes the scheme information. An example would be the following:

<allow-from>

<domain uri="https://contoso.com">

</allow-from>).

This above policy would allow only connection from https://contoso.com using the HTTPS scheme.

The wildcard behavior of a Silverlight policy file for a standalone '*' wildcard depends on the type of service being accessed:

This wildcard behavior allows all Silverlight applications hosted on HTTP and HTTPS to connect to an HTTP service. This allows only Silverlight applications hosted on HTTPS to connect to an HTTPS service.

The wildcard behavior of a Silverlight policy file for an "http://*" literal wildcard depends on the type of service being accessed:

This behavior for "http://*" literal wildcard allows all Silverlight applications hosted on HTTP to connect to an HTTP or HTTPS service.

The wildcard behavior of a Silverlight policy file for an "https://*" literal wildcard depends on the type of service being accessed:

This behavior for "http://*" literal wildcard allows all Silverlight applications hosted on HTTP to connect to an HTTP or HTTPS service.

If an HTTPS service wants to allow all connections from both HTTP and HTTPS, then there are two methods to accomplish this on Silverlight version 3 . One method is that the policy file must include domain uri entries for both the standalone '*' wildcard and the "http://*" literal wildcard. An example would be the following:

<allow-from>

<domain uri="*">

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

</allow-from>).

A second method is that the policy file must include domain uri entries for both the standalone "http://*" literal wildcard and the "https://*" literal wildcard. An example would be the following:

<allow-from>

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

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

</allow-from>).

You implicitly deny access for all domains not listed in a <domain> element tag in a Silverlight policy file.

Each domain must be in the following BNF format:

• domain = "http:"|"https:" authority

• authority = host [ ":" port ]

• host = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." )

• port = *DIGIT

Each Silverlight application uri is an absolute uri with no query or fragment for an .html, .xaml, or .xap file.

The Silverlight policy file allows custom methods other than GET and POST to be allowed when the client HTTP handler has been specified for a URI. The default browser HTTP handler allows only GET and POST requests to be used. When an allow-from http-methods element is specified, the allowed request methods must be specified as the wildcard of "*". The domain includes the scheme information. An example would be the following:

<allow-from http-methods="*">

<domain uri="*">

</allow-from>).

This above policy would allow only custom requests other than GET and POST requests to be used by the client HTTP handler. The allow-from http-methods policy element was added for Silverlight version 3. This policy element is not recognized by Silverlight version 2 clients. If a server needs to support both Silverlight 3  and Silverlight 2 clients, then the policy file should contain two policy sections, one with the allow-from http-methods policy element and one with the allow-from policy element. An example would be the following:

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
<!--Enables Silverlight 3 all methods functionality-->
    <policy>
      <allow-from http-methods=”*">      
        <domain uri="*"/>
      </allow-from>      
      <grant-to>      
        <resource path="/api" include-subpaths="true"/>
      </grant-to>      
    </policy>
<!--Enables Silverlight 2 clients to continue to work normally -->
    <policy>
      <allow-from >      
        <domain uri="*"/>
      </allow-from>      
      <grant-to>      
        <resource path="/api" include-subpaths="true"/>
      </grant-to>      
    </policy>
  </cross-domain-access>
</access-policy>

A single Silverlight policy file can have policies included for connection requests from WebClient and HTTP classes in the System.Net namespace and also policies for connection requests from sockets.

The process to determine if a request is permissible with the policy file is as follows:

Is the scheme of the requested URI the same as the application’s site of origin? Is HTTP the scheme of the requested URI and the scheme of the application's site of origin is HTTPS? Is HTTPS the scheme of the requested URI and the scheme of the application's site of origin is HTTP If not one of these three cases, the request does not have access and should not be sent.

For each <policy> element:

• Is the application’s site of origin allowed access? This can be done either explicitly in the <policy> allow-from domain attribute or the allow-from attribute can have a domain element with a wildcard for the uri attribute, indicating that everyone is allowed access. Note that if allow-from is omitted, the default behavior is that nobody is allowed access.

• Does the policy grant access to the request URI?

If any of the following conditions are true, then the request does have access and should be sent. Otherwise, go to next <policy> in file.

• The requested URI exactly matches the domain and path in a <resource> tag.

• The requested URI falls beneath the domain and path in a <grant-to> tag and the <grant-to> tag include-subpaths attribute has the value set to true.

• For a socket request, the protocol and port attribute in a <socket-resource> tag in the <grant-to> section of this <policy> specifies tcp for the protocol and a port or port range within the allowable range of 4502-4534.

A following is a sample Silverlight policy file for connections using sockets.

<?xml version="1.0" encoding ="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from>
        <domain uri="file:///" />
      </allow-from>
      <grant-to>
        <socket-resource port="4502-4506" protocol="tcp" />
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

The follow sample implements a simple policy server for sockets in managed code. The sample policy server requires the name of the policy file to use as an argument when the server is started.

using System;
using System.IO;
using System.Net;
using System.Net.Sockets;

namespace PolicyServer
{
    // Encapsulate and manage state for a single connection from a client
    class PolicyConnection
    {
        private Socket m_connection;

        // buffer to receive the request from the client
        private byte[] m_buffer;
        private int m_received;

        // the policy to return to the client
        private byte[] m_policy;

        // the request that we're expecting from the client
        private static string s_policyRequestString = "<policy-file-request/>";



        public PolicyConnection(Socket client, byte[] policy)
        {
            m_connection = client;
            m_policy = policy;

            m_buffer = new byte[s_policyRequestString.Length];
            m_received = 0;

            try
            {
                // receive the request from the client
                m_connection.BeginReceive(m_buffer, 0, s_policyRequestString.Length, SocketFlags.None, new AsyncCallback(OnReceive), null);
            }
            catch (SocketException)
            {
                m_connection.Close();
            }
        }

        // Called when we receive data from the client
        private void OnReceive(IAsyncResult res)
        {
            try
            {
                m_received += m_connection.EndReceive(res);

                // if we haven't gotten enough for a full request yet, receive again
                if (m_received < s_policyRequestString.Length)
                {
                    m_connection.BeginReceive(m_buffer, m_received, s_policyRequestString.Length - m_received, SocketFlags.None, new AsyncCallback(OnReceive), null);
                    return;
                }

                // make sure the request is valid
                string request = System.Text.Encoding.UTF8.GetString(m_buffer, 0, m_received);
                if (StringComparer.InvariantCultureIgnoreCase.Compare(request, s_policyRequestString) != 0)
                {
                    m_connection.Close();
                    return;
                }

                // send the policy
                m_connection.BeginSend(m_policy, 0, m_policy.Length, SocketFlags.None, new AsyncCallback(OnSend), null);
            }
            catch (SocketException)
            {
                m_connection.Close();
            }
        }

        // called after sending the policy to the client; close the connection.
        public void OnSend(IAsyncResult res)
        {
            try
            {
                m_connection.EndSend(res);
            }
            finally
            {
                m_connection.Close();
            }
        }
    }

    // Listens for connections on port 943 and dispatches requests to a PolicyConnection
    class PolicyServer
    {
        private Socket m_listener;
        private byte[] m_policy;

        // pass in the path of an XML file containing the socket policy
        public PolicyServer(string policyFile)
        {
            // Load the policy file
            FileStream policyStream = new FileStream(policyFile, FileMode.Open);

            m_policy = new byte[policyStream.Length];
            policyStream.Read(m_policy, 0, m_policy.Length);

            policyStream.Close();


            // Create the Listening Socket
            m_listener = new Socket(AddressFamily.InterNetworkV6, SocketType.Stream, ProtocolType.Tcp);

            // Put the socket into dual mode to allow a single socket 
            // to accept both IPv4 and IPv6 connections
            // Otherwise, server needs to listen on two sockets,
            // one for IPv4 and one for IPv6
            // NOTE: dual-mode sockets are supported on Vista and later
            m_listener.SetSocketOption(SocketOptionLevel.IPv6, (SocketOptionName)27, 0);

            m_listener.Bind(new IPEndPoint(IPAddress.IPv6Any, 943));
            m_listener.Listen(10);

            m_listener.BeginAccept(new AsyncCallback(OnConnection), null);
        }

        // Called when we receive a connection from a client
        public void OnConnection(IAsyncResult res)
        {
            Socket client = null;

            try
            {
                client = m_listener.EndAccept(res);
            }
            catch (SocketException)
            {
                return;
            }

            // handle this policy request with a PolicyConnection
            PolicyConnection pc = new PolicyConnection(client, m_policy);

            // look for more connections
            m_listener.BeginAccept(new AsyncCallback(OnConnection), null);
        }

        public void Close()
        {
            m_listener.Close();
        }
    }



    public class Program
    {
        static void Main(string[] args)
        {
            if (args.Length == 0)
            {
                Console.WriteLine("usage: PolicyServer.exe PolicyFile.xml");
                return;
            }

            PolicyServer ps = new PolicyServer(args[0]);
            System.Threading.Thread.Sleep(System.Threading.Timeout.Infinite);
        }

    }
}

Tasks

Concepts

Other Resources