DarksideCookie

Come to the dark side...we have cookies!

Encryption is not everything

Sorry, for the cryptic title for this post, but it is sort of true, at least when it comes to client access policies. And I didn’t know it until a couple of days ago…

As a part of a project I am working on, we are deploying an STS (Secure Token Service) to handle authentication the users of an OOB Silverlight application. The STS is completely decoupled from the application, as it should be, and is hosted on its own, and the client requests a token from the service through a simple HTTP GET with basic authentication.

As we all know, unless you are using an OOB app with elevated permissions, we need to use a client access policy file when doing cross domain calls. So, I added a clientaccesspolicy.xml file to the STS, with the following content

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

This is a standard policy file that allows EVERYTHING. It allows requests from any address with any header, and does it for all paths… That is pretty bloody open if you ask me.

After having added the policy file, I fired up the client and logged in, and everything worked fin.

And then a couple of days later, I try to logging in, but I get a SecurityException… What!?

Ok, Fiddler to the rescue… But Fiddler didn’t show anything. It showed nothing at all to be honest…just as it does when you connect using SSL. A feature that a colleague of mine had added to the STS the day before.

After telling Fiddler to inspect SSL connections, I could tell that the policy was being downloaded properly, but the client still said that something was wrong.

Slightly confused, I Googled the problem and came across this, a very boring page about network security in Silverlight, which I guess is where I should have started before even Googling it. On the network security page, there is a table that says HTTPS-hosted Silverlight applications can access both secured and unsecured resources if the policy file uses a <domain /> element with the uri attribute set to *. You will also find a table saying that an HTTP hosted client is allowed to access unsecure resources, but not secured resources if the uri attribute is set to *. Instead, an HTTP hosted client requires the attribute to be explicitly set to “http://*” if the resource is hosted on HTTPS.

So to get this working for both secured and non-secured clients, the policy-file has to explicitly allow both types. Like this

<?xml version="1.0" encoding="utf-8"?>
<access-policy>
<cross-domain-access>
<policy>
<allow-from http-request-headers="*">
<domain uri="http://*"/>
<domain uri="https://*"/>
</allow-from>
<grant-to>
<resource path="/" include-subpaths="true"/>
</grant-to>
</policy>
</cross-domain-access>
</access-policy>

In this case, I’m talking about an OOB application, which means that it is actually hosted using the “file://” scheme. So I guess that means that Silverlight considers “file://” being the same as HTTP, which makes sense I guess. It would have been nice if the documentation mentioned this though…

That’s all for this time…

(I finally managed to write a “short” post…)

Posted: Jan 04 2012, 14:48 by ZeroKoll | Comments (0) |
  • Currently 0/5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5
Filed under: Security | Silverlight
Manage post: :)
Comments are closed