Silverlight Design Question

Question

I am going to be developing an application for work, and I am trying to decide whether to use Silverlight Business App or Asp.Net Web App. My manager is concerned about the performance and download time it would take if I created the entire application as a Silverlight app, with authentication. I have been playing around with some tutorials over the last week trying to get a perspective on my situation and have come up with a design question I need to ask those that are more experienced than me.

Is it possible to use a Asp.Net application and just embed a silverlight application in one of the pages that will be used inside a folder that is configured with the roles authorization? And if so, would it be possible to get user credentials from the client silverlight app without passing them through the initParams.

I understand that I can set the authentication to "useCookies", so I was thinking I would be able to get the cookie on the client and hopefully get a property verifying if the user is authenticated.

Also, would this be a risky practice? Thanks for any advice and direction.

Answer 1

1.) It's absolutely possible to embed a Silverlight xap on an ASP.NET page. 2.) As far as credentials, using cookies could work, or you could pass in a token over initparams and validate that token via a web service to see if the user is valid

It's always a risk passing credentials around, especially when it's running on a clients computer. That said, Silverlight buys you a lot, so don't let the challenge of authentication hold you back.

Answer 2

There are a few approaches you could take. While I know you don't want to expose the credential in init params, you could generate a "ticket" (claims-based authentication) for the credential, and include the ticket (for example, a GUID) in the init params. When the Silverlight application launches, it would consume the ticket, possibly validating it via a secured web service call, and the ticket would no longer be valid so even if someone spoofed it or viewed the source, it couldn't be used.

Quite a bit depends on your architecture. For example, if you are using the roles-based authentication, and most of the business logic and/or decision making is based on web service calls, the web services can use HttpContext.Current.Identity to validate the user. Even if someone opens the Silverlight application, any service calls would fail unless they were appropriately authenticated. Otherwise, I would either go with passing a ticket so Silverlight trustst the user is valid (you can create a service that accepts the Guid and returns the role information) or have the user log in from Silverlight (you have a service facing in front of the authentication mechanism and then return a ticket and/or role information).

It gets even more interesting if you decide to use WCF RIA, check out these examples for baked-in authentication: http://code.msdn.microsoft.com/RiaServices/Release/ProjectReleases.aspx?ReleaseId=2661