Search

I think these are positive changes and, from what I’ve seen so far both TCP and UDP sockets drop their security limitations for an elevated application.

In this article Robbe Morris shares a few thoughts about securing Silverlight applications that reference WCF services.

Even the defense department security protocols are breached on occassion. So, to think that the security policies we've put in place are 100% fool proof is a bit naive. Securing applications is all about determining risk if a breach occurs, lowering that level of risk, and reducing the number of people who are technically knowledgeable enough to pull it off (and not all attackers have the same skillset or background).

In this next post Al Pascual talks about security and authentication with .NET RIA Services. But first you better read the previous post from this series so you can catch up.

I have received many questions about the previous post of how the proxy files actually work. I was looking how .NET RIA Service connects ASP.NET and Silverlight, I was expecting the code that I call from Silverlight using the generated proxy file to call the ASP.NET in the server, yet this is not the case, .NET RIA Service makes a complete copy of the file and compiles it under Silverlight, so all the shared code is just that, 2 different classes, one running in ASP.NET and the other running in Silverlight. That’s why you need to make sure the classes you use in ASP.NET are 3.5 compatible.

I was trading tweets today with @pauliom about whether RIA Services would solve some Auth problems he was having out of the browser.  While RIA does do some interesting things with roles/users, I mentioned that typical Forms Auth out of the box should just work.

To that end I have created a simple example of how to protected WCF Services with Forms Auth (works with ADO.NET Data Services as well BTW).  Because I wanted to support it out of the browser as well, I used the new Forms Auth service. 

Lately I’ve worked with a number of customers who are familiar with non-service-based ways of accessing their business logic. They typically come from one of two backgrounds:

• Client developers where the only connection out of the application is to the database.
• Web developers where all the logic exists on the server

In both cases, they’re not typically working with physical application tiers, even if they logically separate their application. Internal n-tier/client-server developers typically don’t bother thinking about this problem, and Ajax devs, due to often being on the internet, paved this ground a while back.

I’m not at all sure if this is a new thing and suspect that it’s more likely that it’s always been there and I’d just missed it but it fell into the category of “learning something new every day” :-)

Regardless, I had a quick experiment with it – essentially TransportWithMessageCredential means that you’re using the transport ( e.g. in Siverlight this means HTTPS ) to ensure the privacy of the message that you’re transmitting and, because of that, it’s ok to transfer some credential as part of the message.

Al Pascual had some difficulties with the solution of his clientaccesspolicy problems and asks if anyone could give him a hand.

I deployed a Silverlight application that needs to access HTTPS resources, for the deployment of course I read the guidelines to declared on the clientaccesspolicy file the https explicitly. [...]

On some of my previous posts I explain my frustration believing that Silverlight was not able to read the security cookie to send it at each request, until a change was made to the client access policy file to do not state explicitly that HTTPS had access to that resource.

If integrated Windows authentication fails, due to improper user credentials or some other problem, the browser will prompt the user to enter their user name and password.

So if is Silverlight requesting that file protected by Integrated Windows authentication in a background thread, the browser will not display the prompt, therefore, Silverlight won’t access that resource and your application will fail miserably.

We all know it’s not possible yet to provide credentials when calling WCF Service. I’m telling yet, because I saw some signs that we might get support for credentials.

But what about now? Yes now, because Silverlight 3 isn’t release to the web yet.