Skip to main content
Home Forums General Silverlight New Features in Silverlight 3 Silverlight 3... How to secure my traffic?
5 replies. Latest Post by party42 on November 11, 2009.
(0)
bobg2009
Member
10 points
42 Posts
11-08-2009 4:30 AM |
Hi Guys,
I'm developing an Internet based application with Silverlight as the FrontEnd. I will also have a backend application layer and a Database.
My concern is because it is Internet facing I need a way to protect my SQL transactions and also only let my silverlight application talk to the webservice or database that the webservice talks to.
I was looking at WSE. Then I found out that it has been super seeded by WFC. However with WFC and silverlight we can't use wsHttpBinding only basicHttpBinding whihc from 'my' understanding isn't really secure.
So the next thing I'm looking at is RIA .Net, but I don't know if thats going to do the trick either.
I am very interested in hearing how people are securing the communication between there Silverlight clients and thier database backends.
Any help is very much appreciated.
cheers.
ken tucker
All-Star
16302 points
2,487 Posts
11-08-2009 6:35 AM |
Use SSL to keep the data sent to the service secure. I would required the user be logged into asp.net membership to view my silverlight app. In the wcf service method I would check and see if the user is logged in. If they are not I would not return any data
if (HttpContext.Current.User.Identity.IsAuthenticated) { //Return your data } else { return null; }
party42
Participant
1102 points
338 Posts
11-08-2009 7:24 AM |
What you could also do is create an anonymous method called "StartSession" which accepts a username / password combination.
On the service, you authenticate these credentials and return a ticketID (guid) which matches the username / credentials against a ticketstore.
The other methods, you mark with custom attributions causing ticket information to be required as either parameters for the method or as a custom soap header.
On every other method call, you verify that the ticketID is still valid (meaning, the user logged in and has a valid ticket).
Thats our prefered way of authenticating method calls. Obviously, you can set some sliding experiation time on this ticket.
11-08-2009 5:08 PM |
Thanks guys, I appreciate both of your resonses. Both of them are very helpful. At the moment I am leaning towards using the ASP. Net membership method. However they both have thier merits. As I am relatively new to all of this I have a lot of reading to get through. I found this site which looks rathe informative.
"http://weblogs.asp.net/scottgu/archive/2006/05/07/asp.net-2.0-membership-and-roles-tutorial-series.aspx"
thanks again.
bartczer...
Contributor
4190 points
734 Posts
11-10-2009 8:28 PM |
Your questions should be how to secure the Silverlight client and the service layer. So here are a couple pointers:
- as mentioned above use SSL (that is a no brainer and the safest way to go)
- ensure that your Silverlight app is obfuscated. Remember all the assemblies in the app are cached on the client and a hacker can easily open them up in reflector and see what is going on in your code (they could also reverse engineer your service calls)
- custom authorization (i.e., custom message headers with expiration) can also provide an additional layer of security. Many people jump to forms auth because it "works like magic". Things like that have a tendency to be hacked a lot easier with scripts and esay hijack methods
- After you are done prototyping/designing profile your service calls with Fiddler to see how the calls are being made. This way you can spot any "security holes" easier
11-11-2009 5:46 AM |
ensure that your Silverlight app is obfuscated. Remember all the assemblies in the app are cached on the client and a hacker can easily open them up in reflector and see what is going on in your code (they could also reverse engineer your service calls)
I think its a better practice to ensure that your SL app doesn't contain any secrets... Obfuscation is by no means a valid way of protecting secrets. Its just a temporary slowdown...