Silverlight and Authentication

I'm trying to get authentication and roles working in a silverlight application. I set up an authentication and role service to accomplish this. Everything works perfectly on my local machine but when I run the application on the discountasp.net server I cannot get it to work. I do not get any error messages or anything. When I click to login button nothing happens. I know that the roles and user were set up in the sql server, but I'm not sure where to go from here. Any help would be greatly appreciated. Thanks.

 

Just one additional thing I noticed. Throughout my application it refers to "localhost". Does this need to be changed to the domain name? Thanks again.

 

Just an update...I was using Firefox which didn't show an error. When I ran it in IE the following exception was thrown: Async_ExceptionOccurred. Not sure if that helps at all.

 

It works!

Finally. This was no fun for a noobie. For anyone else who may be struggling with this here are
the steps you'll need to take in order to get asp.net authentication and roles working with a silverlight client.


For this to work you are going to need to purchase the sql server add-on from discount asp.net (Please correct me if
this is not the case, but I don't think there is a way to run Sql server express).

First, you'll need to configure the asp.net 2.0 membership and role providers to use sql server 2008. There is
a great kb article located here that will take you through the setup:​

http://support.discountasp.net/KB/a337/how-to-configure-aspnet-20-membershiproles-provider.aspx

As indicated in the kb article copy and paste aspnet_regsql.exe -S DBServerName -U DBLogin -P
DBPassword -A all -d DBName at the command line. Then go to the discountasp.net control panel to get your information. Copy and paste in your
server, login, password and database name where. Hit enter and wait a few seconds and you are done.
Now if you log in to your sql server you'll see all of the tables you will need to set up authentication and
roles.

Next you need to do some work in the web.config file. First off, you'll need to add
the new connection string, as follows:
​

<connectionStrings>
<remove name="LocalSqlServer"/>
<clear/>
<add name="DiscountAspSqlServer"
connectionString="Data Source=tcp:your_server_name;
Integrated Security=false;Initial Catalog=your_database_name;
User ID=your_database_login;Password=your_password"
providerName="System.Data.SqlClient" />
</connectionStrings>

Note that you will have to remove the LocalSqlServer default connection. This overrides the setting in the machine.config
file, allowing you to specify the new connection.

OK, this is where the KB article ends, but there is a lot more to do still.

Still in the web.config file, you need to work on the membership provider. Add the following to the web.config file as a child of the system.web node.
​

<membership defaultProvider="AspNetSqlMembershipProvider">
<providers>
<remove name="AspNetSqlMembershipProvider" />
<add connectionStringName="DiscountAspSqlServer" name="AspNetSqlMembershipProvider"
enablePasswordRetrieval="false" enablePasswordReset="true"
applicationName="/" requiresUniqueEmail="false" passwordFormat="Hashed"
maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10"
passwordStrengthRegularExpression="" requiresQuestionAndAnswer="true"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>



Next you need to set up the roleManager:

<roleManager enabled="true">
<providers>
<remove name="AspNetSqlRoleProvider" />
<clear/>
<add connectionStringName="DiscountAspSqlServer"
name="AspNetSqlRoleProvider" type="System.Web.Security.SqlRoleProvider"/>
</providers>
</roleManager>




Now you can set up the service. I am including here an excellent article on how to do this:

http://blogs.msdn.com/brada/archive...-profile-and-role-service-in-silverlight.aspx

Or, follow this video tutorial:

http://silverlight.net/learn/applications/adventureops/

Now comes the part where you customize the service you just created to run on the discountasp.net server. There may be
a way to do this directly in the web.config file but I couldn't get it to work. What I found to be the most
used method was to create a Service Host Factory.

Add a code behind file to the svc file in the web
application you built in the tutorial. Add the following to the code behind. I created two files, one for the authentication service and one for the role service:​

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.ServiceModel;
using System.ServiceModel.Activation;

namespace my.Web
{
public class MyAuthenticationServiceHostFactory : ServiceHostFactory
{


protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
{

Uri webServiceAddress = new Uri("http://www.yourdomain.com/Services/AuthenticationService.svc");


ServiceHost webServiceHost = new ServiceHost(serviceType, webServiceAddress);


return webServiceHost;


}


}
}



Now make sure you wire this code behind up in your svc file, as follows:


<%@ ServiceHost Language="C#" Debug="true"
Service="System.Web.ApplicationServices.AuthenticationService"
Factory="my.Web.MyAuthenticationServiceHostFactory"
CodeBehind="~/Services/AuthenticationService.svc.cs"%>

Next, on the silverlight client side, open up the ServiceReferences.ClientConfig file and change the endpoint to
reflect your URL:​

<client>
<endpoint address="http://www.your_domain.com/Services/AuthenticationService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_AuthenticationService"
contract="AuthenticationService.AuthenticationService" name="BasicHttpBinding_AuthenticationService" />
<endpoint address="http://www.your_domain.com/Services/RoleService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_RoleService"
contract="RoleService.RoleService" name="BasicHttpBinding_RoleService" />
</client>

I hope I'm not forgetting any steps, but if you followed the links to the tutorials above and made the changes noted here, the service should work. I just wanted
to provide this to save someone else the time piecing it all together. Good luck.​

 

Well done, thanks for the detailed write up. I executed a proof of concept project in this area about 7 or 8 months ago. The sample was tested on the DASP platform and is detailed here including source code download links: http://community.discountasp.net/showthread.php?t=8055

It looks like the difference between your code and mine is that I chose to use the framework provided scriptable application services for authentication / roles etc. and you have developed your own service. To be fair both options do work well and it's probably personal preference as to which option is best.

 

This is great stuff Joe. Thanks for posting the link. The method I used is what they are pushing over on the silverlight site. I followed their video tutorials. I like you approach better. Are there any concerns other than personal preference (security, speed, etc...)

Thanks!

 

Security isn't an issue because with both of these methods, ssl transport would need to be used where security was a concern; that would be the case with Silverlight, ASP.NET and any web based system regardless of technology platform.

I'm not sure about performance so some benchmarking is probably needed if that is a concern. I suppose this is really a question of how heavily the authentication / roles / user profile data sub-system is going to be hit.

So far as choice goes, if the client side developer didn't like JavaScript then your solution will be easier to code against within the Silverlight application because you have a WCF service hosted server side (that you've developed yourself) and you can easily add a service reference in Visual Studio which auto-generates a client proxy.

If you like JavaScript then my solution might be the way to go since the Microsoft .NET framework scriptable application services expose themselves as JavaScript proxies.

As usual with most Microsoft technologies there is more than one way to skin the cat here. Either way the end result is really the same because with both of our solutions we have code running on the client calling a hosted web service asynchronously.