Mike Taulty's Blog
Bits and Bytes from Microsoft UK
Silverlight and WCF RIA Services (5–Authentication)

Blogs

Mike Taulty's Blog

Elsewhere

Archives

It’s a fairly common requirement that a business service authenticates a client and it’s usually (at least) for the purpose of authorisation whereby we can control which users have access to an application or to some of its functionality.

The two ways you usually go about it with a web site or web service are;

  • integrated – i.e. let the web server do it via something like Basic Authentication, Digest Authentication, Windows Authentication.
  • “forms” – i.e. the web server leaves the traffic well alone and something like ASP.NET steps in to make sure that each request carries an appropriate token (cookie) indicating that it has been authenticated. Unauthenticated traffic is usually redirected to a “login page” which harvests credentials and returns a suitable cookie to be replayed on subsequent requests.

Usually, the former is done against credentials managed by Windows whereas the latter is done against credentials managed by the application itself (or by ASP.NET on its behalf).

Where “forms” authentication can get a little odd is where you are using it to authenticate calls to web services and there perhaps aren’t any actual web pages in your application at all.

For instance, you can easily build a Silverlight client that calls web services and then put forms authentication in front of those services. This means that the first request from the client to a service is going to be bounced as it won’t be carrying the right cookie.

That kind of client needs some additional service to call to perform the authentication that’s not an HTML based web page and that’s made easy by ASP.NET offering its membership/roles/profiles services as web services (which I made use of here) so a Silverlight client can call the membership service, get credentials authenticated and then (usually) that translates into a cookie that then authenticates the client as it makes follow-on service calls.

But, that all takes a bit of work to get things in place and so RIA Services comes along and simplifies it by supporting both Windows (i.e. integrated) and Forms based authentication and any other custom scheme that you might want to plug in.

How do they do that then? Abstraction!

RIA Services already has the notion of a service than can be easily exposed to the client side – the DomainService.

In order to support authentication, there’s a derivation of DomainService called AuthenticationBase<T> on the server side. Because it’s a DomainService, the code-generation process will make it available to the client side.

AuthenticationBase<T> looks like;

image

the idea of the generic parameter <T> here is that it’s a class to represent the authenticated user down on the client side and IAuthentication<T> providing the plug-in point.

Whatever information you need to pass around about the user can be added to this class and then it’ll show up down on the client side. The primary example here would be properties that you’re storing in the ASP.NET profile system and there’s an automatic way to wire those up (later).

Anyway, you’re more than likely to want to know the user’s name and application roles on the client side so T here is constrained to be an IUser which looks like;

image

Running the code generation process on these server-side bits causes client side bits to get emitted;

  • a User class that’s derived from Entity, but also implements IPrincipal, IIdentity
    • I talked about Entity  a lot in this previous post – given that this is data returned from a DomainService, it makes sense that it derives from Entity
  • A class derived from AuthenticationDomainContextBase

at first, it doesn’t seem so obvious what you actually do with the AuthenticationDomainContextBase class unless you’ve seen these other classes;

image

So…we can do FormsAuthentication or WindowsAuthentication and we can treat either of these as an AuthenticationService and in doing so we need to plug in a DomainContext of type AuthenticationDomainContextBase and so that’s where our generated class plugs in.

AuthenticationService looks like;

image

and so I can write code that uses FormsAuthentication/WindowsAuthentication directly or I can take advantage of some more generation…

If you’ve got a direct link from your Silverlight project to your Web project then you’ll have a generated WebContext class (derives from WebContextBase) and that class;

  • implements IApplicationService which means you can drop it into your Application class’s ApplicationLifetimeObjects collection
  • has a static member on it called Current which returns the current WebContext so you can easily grab it from anywhere
  • has a property on it called Authentication of type AuthenticationService so this provides a slot where it’s easy to store/retrieve whatever authentication service you’re using

if you’ve used the “Silverlight Business Application” template then you’ll have seen that this template automatically instantiates a WebContext for you ( check out App.xaml.cs ) and automatically instantiates a FormsAuthentication instance and drops it into the WebContext’s property Authentication. You could equally well do a similar thing in XAML or code yourself like this XAML example below;

<Application xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:myWeb="clr-namespace:MyApplication.Web"
             xmlns:my="clr-namespace:MyApplication"
             xmlns:appSvcs="clr-namespace:System.ServiceModel.DomainServices.Client.ApplicationServices;assembly=System.ServiceModel.DomainServices.Client.Web"
             x:Class="MyApplication.App">
    <Application.ApplicationLifetimeObjects>
        <my:WebContext>
            <my:WebContext.Authentication>
                <appSvcs:FormsAuthentication />
            </my:WebContext.Authentication>
        </my:WebContext>
    </Application.ApplicationLifetimeObjects>
</Application>

and with that in place it means I can use WebContext.Current.Authentication to get to my AuthenticationService whenever I want.

If you don’t have a direct link then it’s pretty easy to create a WebContextBase derived class yourself (see link).

Either way, I’ve got an AuthenticationService (FormsAuthentication/WindowsAuthentication) that I can write code against. So, how’d you make this work in specific scenarios around both Forms authentication and Integrated authentication?

Starting from Scratch

In the previous post I walked through how to get set up with a new project that used RIA Services class libraries such that you ended up with (at least) 4 projects;

  • A Silverlight application
  • A web site
  • A RIA Services Silverlight class library linked to
  • A RIA Services web class library

and I had done nothing to switch any authentication on or off. I had a “dummy” service;

  [EnableClientAccess()]
  public class MyDomainService : DomainService
  {
    [Invoke]
    public int Add(int x, int y)
    {
      return (x + y);
    }
  } 

and so I can call this from the client-side;

MyDomainContext ctx = new MyDomainContext();

          InvokeOperation<int> operation = ctx.Add(10, 20);

          operation.Completed += (x, y) =>
            {
              if (!operation.HasError)
              {
                int result = operation.Value;
              }
            };

but, having done nothing about authentication I hit an immediate problem which looks to resolve to;

image

but I’m not trying to authenticate! What’s going on here? Well, if I look at my IIS set up then what I have is;

  • Default Web Site->Auth Site

and I have both of those set up to allow both anonymous and basic authentication;

image

and that’s causing me “a problem”. As far as I know, the problem it’s actually causing is to the webHttpBinding which is trying to “guess” which of these 2 options I want it to use. What if I change my configuration to try and help it out?

image

That seemed to stop WCF trying to guess about whether I wanted “Anonymous” or “Basic” and I’m now running unauthenticated calls from my client to my service.

I guess it’s time to switch on some authentication then…

Requiring Authentication

I can declaratively demand that access to my entire service or specific operations is authenticated by applying RequiresAuthenticationAttribute and be specific about roles (defined by ASP.NET roles/Windows) by using the  RequiresRoleAttribute and I can do that to either the entire domain service class or specific methods on it as in;

  [EnableClientAccess()]
  public class MyDomainService : DomainService
  {
    [Invoke]
    [RequiresAuthentication]
    public int Add(int x, int y)
    {
      return (x + y);
    }
  }
and now my client can no longer make calls to that particular operation ( fails with an “Access Denied” error as you’d expect ) so I need to get my client to authenticate.

On the server-side, I can switch on Forms authentication in my web.config;

image

and then I figured that I might be able to get away with just using the FormsAuthentication class on the client side without even making use of an Authentication Domain Service because I’m not doing anything fancy with users and so on. So, I tried;

         FormsAuthentication auth = new FormsAuthentication();

          LoginOperation operation = auth.Login("testUser", "Passw0rd!");

          operation.Completed += (sender, args) =>
            {
              if (!operation.HasError)
              {
              }
            };
but that’s no good. I get an exception;

The DomainContextType is null or invalid and there are no contexts generated from AuthenticationBase<T>.

Ok – fair enough. I add a new project item;

image

to add a Authentication Domain Service to my service-side library project (AuthRIALibrary.Web) and called it MyAuthDomainService and that causes the generation of a MyAuthDomainContext on the client side and then I can authenticate and (on success) call my service operation;

          FormsAuthentication auth = new FormsAuthentication();

          auth.DomainContext = new MyAuthDomainContext();

          LoginOperation operation = auth.Login("mike", "Passw0rd!");

          operation.Completed += (sender, args) =>
            {
              if ((!operation.HasError) && (operation.LoginSuccess))
              {
                MyDomainContext ctx = new MyDomainContext();

                InvokeOperation<int> addOperation = ctx.Add(10, 20);

                addOperation.Completed += (s, e) =>
                {
                  if (!addOperation.HasError)
                  {
                    int result = addOperation.Value;
                  }
                };
              }
            };
and that works fine for me. Now, because of the way I’ve structured my projects I don’t get a WebContextBase-derived class generated for me in my main Silverlight application project but I can duplicate the generation process easily enough in that project;

public class MyWebContext : WebContextBase
  {
    public MyWebContext()
    {

    }
    public static new MyWebContext Current
    {
      get
      {
        return ((MyWebContext)WebContextBase.Current);
      }
    }
    public User User
    {
      get
      {
        return ((User)base.User);
      }
    }
  }

then I can ( maybe ) drop some of this into my App.xaml;

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="AuthClient.App"
    xmlns:local="clr-namespace:AuthClient"
    xmlns:remote="clr-namespace:AuthRIALibrary.Web;assembly=AuthRIALibrary"
    xmlns:riaWeb="clr-namespace:System.ServiceModel.DomainServices.Client.ApplicationServices;assembly=System.ServiceModel.DomainServices.Client.Web">
    <Application.ApplicationLifetimeObjects>
        <local:MyWebContext>
            <local:MyWebContext.Authentication>
                <riaWeb:FormsAuthentication>
                    <riaWeb:FormsAuthentication.DomainContext>
                        <remote:MyAuthDomainContext />
                    </riaWeb:FormsAuthentication.DomainContext>
                </riaWeb:FormsAuthentication>
            </local:MyWebContext.Authentication>
        </local:MyWebContext>
    </Application.ApplicationLifetimeObjects>
</Application>

and then that makes the rest of my code a lot simpler;

          MyWebContext.Current.Authentication.LoggedIn += (s, e) =>
            {
              MyDomainContext ctx = new MyDomainContext();

              var invokeOperation = ctx.Add(10, 20);

              invokeOperation.Completed += (sender, args) =>
                {
                  if (!invokeOperation.HasError)
                  {
                    MessageBox.Show(string.Format("User {0} got result {1}",
                      MyWebContext.Current.User.Name,
                      invokeOperation.Value));
                  }
                };
            };
          MyWebContext.Current.Authentication.Login("mike", "Passw0rd!");
( although not exactly equivalent code to what I did before but the intent is the same and now I can rely on MyWebContext.Current and not worry too much about what kind of Authentication service it’s providing ).

It’s not a great idea to do Forms authentication over HTTP though so it’d be better to make sure that I change the MyAuthDomainService class to state that it needs HTTPS as a requirement for use;

  [EnableClientAccess(RequiresSecureEndpoint=true)]
  public class MyAuthDomainService : AuthenticationBase<User>
  {
    // To enable Forms/Windows Authentication for the Web Application, 
    // edit the appropriate section of web.config file.
  }
and then my client code stopped working because it was trying to access the forms authentication service via https://localhost and that’s not going to work.

How did the client suddenly know it was meant to use HTTPS for access to the authentication domain service? A sneaky small trick – if you have RequiresSecureEndpoint=true set then the client code generation process spits out a slightly different constructor for your class derived from AuthenticationDomainContextBase. In my case, this is my MyAuthDomainContext class and the modification in the generated code is;

image

that true flag in the generated code says “Use HTTPS” and isn’t present if the RequiresSecureEndpoint isn’t set on the server.

How do I get my client code back to working? Up until now I’d be letting Visual Studio set the start page for my solutions but this means that it uses http://localhost so I need to switch that start page because localhost isn’t a machine name that I have SSL certificates for. My machine name is mtaulty and I have certificates for that name.

I switched my start page for the application to have a proper machine name in the URL http://mtaulty/ and then (not surprisingly) I hit a cross-domain issue because my application is being served up over HTTP and it straight away goes and does this HTTPS request in order to do its Forms authentication via MyAuthDomainContext.

Time for a cross-domain policy file (to allow the cross-scheme request). Mine looked like;

<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from>
        <domain uri="http://mtaulty.europe.corp.microsoft.com"/>
      </allow-from>
      <grant-to>
        <resource path="/AuthSite/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

and that’s enough to say that apps from my machine are allowed to do cross-scheme into my AuthSite virtual directory.

On the service-side, I can get hold of the authenticated user easily enough;

 [EnableClientAccess()]
  public class MyDomainService : DomainService
  {
    [Invoke]
    [RequiresAuthentication]
    public int Add(int x, int y)
    {
      // Who's calling this operation?
      bool isAuth = this.ServiceContext.User.Identity.IsAuthenticated;
      string user = this.ServiceContext.User.Identity.Name;
      bool isAdmin = this.ServiceContext.User.IsInRole("Admins");
      return (x + y);
    }
  } 
just like I can easily get to the user on the client side via MyWebContext.Current.User (see previou lumps of code).

If I also want to program against the Profile service from ASP.NET and store data on a per-user basis without having to write custom code then I can (e.g.) switch on the service in my web.config and add a per-user property such as;

 <profile enabled="true">
      <properties>
        <add name="Age" type="Integer" defaultValue="18"/>
      </properties>
    </profile>

and then add ( service-side in my RIAAuthLibrary.Web project ) to my User class which Visual Studio generated when I added an Authentication Domain Service;

  public class User : UserBase
  {
    public int Age { get; set; }
  }

and then that becomes available to me from the client side ( minus any kind of error handling );

MyWebContext.Current.Authentication.LoggedIn += (s, e) =>
            {
              MessageBox.Show(string.Format("User {0} is {1} years old",
                MyWebContext.Current.User.Name,
                MyWebContext.Current.User.Age));

              MyWebContext.Current.User.Age += 10;

              MyWebContext.Current.Authentication.SaveUser(false);
            };

          MyWebContext.Current.Authentication.Login("mike", "Passw0rd!");

so that’s all good and I’m doing read/write on those properties and persisting the changes back to the server. What about integrated authentication?

Integrated Authentication

I like to start simple so to experiment with integrated authentication I first backed out the HTTPS requirement on my service;

 [EnableClientAccess()]
  public class MyDomainService : DomainService
  {
    [Invoke]
    [RequiresAuthentication]
    public int Add(int x, int y)
    {
      // Who's calling this operation?
      bool isAuth = this.ServiceContext.User.Identity.IsAuthenticated;
      string user = this.ServiceContext.User.Identity.Name;
      bool isAdmin = this.ServiceContext.User.IsInRole("Admins");
      return (x + y);
    }
  } 
and then I edited my web.config in order to specify that I was using Windows authentication and that I wanted to use Basic authentication along with that;
<configuration>
  
  <system.web>
    
    <authentication mode="Windows"/>

and also to guide WCF;

 <system.serviceModel>

    <serviceHostingEnvironment aspNetCompatibilityEnabled="true">

    </serviceHostingEnvironment>

    <bindings>
      <webHttpBinding>
        <binding>
          <security mode="None">
            <transport clientCredentialType="Basic"/>
          </security>
        </binding>
      </webHttpBinding>
    </bindings>
    
  </system.serviceModel>

then I made sure that my IIS configuration was set up to allow (not force) Basic authentication for my site;

image

Then I changed my App.xaml to use WindowsAuthentication rather than FormsAuthentication;

<Application
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    x:Class="AuthClient.App"
    xmlns:local="clr-namespace:AuthClient"
    xmlns:remote="clr-namespace:AuthRIALibrary.Web;assembly=AuthRIALibrary"
    xmlns:riaWeb="clr-namespace:System.ServiceModel.DomainServices.Client.ApplicationServices;assembly=System.ServiceModel.DomainServices.Client.Web">
    <Application.ApplicationLifetimeObjects>
        <local:MyWebContext>
            <local:MyWebContext.Authentication>
                <riaWeb:WindowsAuthentication>
                    <riaWeb:WindowsAuthentication.DomainContext>
                        <remote:MyAuthDomainContext />
                    </riaWeb:WindowsAuthentication.DomainContext>
                </riaWeb:WindowsAuthentication>
            </local:MyWebContext.Authentication>
        </local:MyWebContext>
    </Application.ApplicationLifetimeObjects>
</Application>

Then I hit a snag when running my client side code because running it produces an exception;

A first chance exception of type 'System.NotSupportedException' occurred in System.ServiceModel.DomainServices.Client.Web

Additional information: Windows authentication does not support logging in.

so it seems like if you’re using integrated authentication then you are going to let the “transport” figure out the credentials rather than providing them programmatically and so you don’t explicitly Login with a user name and password.

Silverlight has 2 stacks for HTTP – client and browser with different capabilities. It’s a trade-off as to which one you use. Specifically, here, the client stack is capable of doing integrated authentication by either allowing the transport to gather credentials or by having them provided by code. The browser stack does not support the idea of credentials coming from code. I suspect (to get ASP.NET cookie integration) that RIA services is running over the browser stack and so you can’t pass credentials when doing an integrated authentication.

I need to change my client-side code a little in order to call LoadUser rather than Login – it’s “fun” to note that even though I’ve moved to integrated authentication, I can still rely on the ASP.NET profile service and get custom per-user data represented on the client side by the generated User class and so most of my code still works if I call LoadUser() instead of Login;

 MyWebContext.Current.Authentication.LoggedIn += (s, e) =>
            {
              MessageBox.Show(string.Format("User {0} is {1} years old",
                MyWebContext.Current.User.Name,
                MyWebContext.Current.User.Age));

              MyWebContext.Current.User.Age += 10;

              MyWebContext.Current.Authentication.SaveUser(false);
            };

          MyWebContext.Current.Authentication.LoadUser();        

Personally, I’d perhaps want to put the difference between FormsAuthentication and WindowsAuthentication behind some other class that abstracts the differences here around Login/LoadUser.

When I run that code, I see the browser prompt;

image

and then the client-server interaction happens and I can see in Fiddler what’s going on;

image

Great. I can switch to using Windows authentication by changing my web.config;

<bindings>
      <webHttpBinding>
        <binding>
          <security mode="None">
            <transport clientCredentialType="Windows"/>
          </security>
        </binding>
      </webHttpBinding>
    </bindings>

and re-configuring IIS;

image

and that seems to work fine – it does not involve me typing in credentials because (in my setup) my web server and my client machine are in the same domain and I’m already authenticated so Windows just does the “right thing” here.

Note – I also tried changing my configuration to “digest” here and for whatever reason I couldn’t get that to work – not sure that’s going on with my configuration there.

Now, naturally, if I’m going to use something like “Basic” then I need to secure it with HTTPS.

So, I switched my configuration back to “basic” and then altered my authentication service to demand HTTPS;

  [EnableClientAccess(RequiresSecureEndpoint=true)]
  public class MyAuthDomainService : AuthenticationBase<User>
  {
    // To enable Forms/Windows Authentication for the Web Application, 
    // edit the appropriate section of web.config file.
  }

and my actual domain service;

  [EnableClientAccess(RequiresSecureEndpoint=true)]
  public class MyDomainService : DomainService
  {
    [Invoke]
    [RequiresAuthentication]
    public int Add(int x, int y)
    {
      return (x + y);
    }
  } 

and in web.config;

<bindings>
      <webHttpBinding>
        <binding>
          <security mode="Transport">
            <transport clientCredentialType="Basic"/>
          </security>
        </binding>
      </webHttpBinding>
    </bindings>

and then things went slightly awry for a while in that I hit an exception;

Additional information: Could not find a base address that matches scheme https for the endpoint with binding WebHttpBinding. Registered base address schemes are [http]

and it took me a little while to figure out how to get past it and I’m not entirely sure that I got past it in the right way.

What I did was set the security mode up there back to None.

I’m not nearly 100% sure on this one. I’ve told the client to always use HTTPS so that seems fine but with mode=”None” it feels like I might be allowing my service to be called over HTTP but then I’ve got the RequiresSecureEndpoint setting set to true. So am I configuring this the right way? Not sure!

I’ll come back to this if I figure it out better.

Providing a .SVC File

Up until now, for integrated authentication I’ve been setting up IIS so that my site is using;

  • Anonymous + Basic
  • Anonymous + Windows

with the rationale being that I want the unauthenticated user to be able to get to my HTML page and my Silverlight XAP but then I want to have my Silverlight application’s calls across to my domain services to be authenticated and I’ve been using the standard webHttpBinding in my web.config to ensure that WCF knows whether I’m actually using Basic/Windows;

image

If I was using WCF on its own and wanted to do something like basic authentication over HTTPS what I usually do is drop my service SVC files into a folder called something like secure and then I set up IIS to demand HTTPS and basic authentication for that particular folder (and I config up WCF to tell it that’s what I’m doing).

But how to do that with RIA Services where there are no SVC files to drop into a folder?

Whilst RIA Services usually dynamically generates a .SVC file (see earlier post) you can author them manually yourself.

If I create a folder called Services in my web site then I can create SVC files for my services ( the authentication service and the domain service ) naming them in my case;

image
and the content of one of those files looks like;

<%@ ServiceHost Language="C#" Debug="true" Service="AuthRIALibrary.Web.MyDomainService"
    Factory="System.ServiceModel.DomainServices.Hosting.DomainServiceHostFactory" %>

and I can alter my main web.config to remove the service definitions;

<?xml version="1.0"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
	<system.web>
		<authentication mode="Windows"/>
		<profile enabled="true">
			<properties>
				<add name="Age" type="Integer" defaultValue="18"/>
			</properties>
		</profile>
		<compilation debug="true" targetFramework="4.0">
			<assemblies>
				<add assembly="System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/></assemblies></compilation>
	</system.web>
	<system.webServer>
		<modules runAllManagedModulesForAllRequests="true">
			<add name="DomainServiceModule" type="System.ServiceModel.DomainServices.Hosting.DomainServiceHttpModule, System.ServiceModel.DomainServices.Hosting, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
		</modules>
	</system.webServer>
  <system.serviceModel>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true"
                               multipleSiteBindingsEnabled="true"/>
  </system.serviceModel>
</configuration>

and then I can have the web.config in the Services sub-folder;

<?xml version="1.0"?>
<!--
  For more information on how to configure your ASP.NET application, please visit
  http://go.microsoft.com/fwlink/?LinkId=169433
  -->
<configuration>
	<system.serviceModel>
		<behaviors>
			<serviceBehaviors>
				<behavior name="">
					<serviceMetadata httpGetEnabled="true"/>
					<serviceDebug includeExceptionDetailInFaults="false"/>
				</behavior>
			</serviceBehaviors>
		</behaviors>    
	</system.serviceModel>
</configuration>

Note that in that sub-folder, I don’t need to include that webHttpBinding section because I’m going to configure this folder in IIS to force Basic authentication and HTTPS so there’s no “confusion” for WCF as to whether I want Basic auth or not.

Note that I also had to add a reference to System.ServiceModel.DomainServices.Hosting in order to be able to use the right service host factory here.


Posted Fri, Jul 2 2010 2:51 PM by mtaulty

Comments

DotNetShoutout wrote Silverlight and WCF RIA Services (5–Authentication) - Mike Taulty
on Fri, Jul 2 2010 7:15 PM

Thank you for submitting this cool story - Trackback from DotNetShoutout

Sanjeev Agarwal wrote Daily tech links for .net and related technologies - June 5-7, 2010
on Mon, Jul 5 2010 9:27 AM

Daily tech links for .net and related technologies - June 5-7, 2010 Web Development Introducing “Razor

Raymond Pecilla wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Mon, Jul 5 2010 12:01 PM

Great Post Mike! Your posts are clear and cover useful content. THanks

Community Blogs wrote Learning WCF RIA Services
on Sat, Jul 10 2010 8:34 PM

In my quest to learn WCF RIA Services I read a lot of articles and I thought I could share the most useful

Andrea p wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Sun, Jul 11 2010 9:52 PM

I tried to replicate your silution structure.

I got a 4004 error... So i thougt to add a silverlight application set to work with the website with ria support. Probably that fixed the configuration because removing the sl application the error disappeared!:)

adjollybuoy wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Mon, Jul 19 2010 7:09 PM

I also get a 4004 error saying that "Access to path c:\inetpub\wwwroot\AuthSite\App_Data' is denied.

How can I resolve this issue?

Pravin Gundawar wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Tue, Jul 20 2010 2:31 AM

I love your way explaining. I always reach end of the article.

Thomas SilverlightNoob wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Tue, Jul 27 2010 4:23 PM

Great blog Mike!

I have an issue with my RIA based application, it allows duplicate login. (Ie, a user can login in 2 separate browsers, with the same credentials). How can I stop the user from doing so? I did try to block a login based on the "IsOnline" property, but that just prevent the user from login while the IsOnline is active, even if a user logged out. The IsOnline attribute is set to clear after 15 minutes, which doesn't help me.

Dhinesh Kumar wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Wed, Jul 28 2010 11:47 AM

Hello Mike

Wonderful Blog on WCF RIA Applications. I have a query on this. Do you use code generator or T4 templates in order to generate Domain Service,Domain Client, Entity Client, Entity objects, please let us know.

Regards

Dhinesh Kumar

mtaulty wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Wed, Jul 28 2010 3:53 PM

Dinesh,

Not as far as I'm aware.

Mike.

Devinder wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Mon, Aug 23 2010 3:31 PM

Thanks For This Nice Tutorial

Josh wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Wed, Aug 25 2010 11:09 PM

Hi Mike, thanks for this tutorial.  Do you have any tips for WPF clients accessing RIA Services via FormsAuthentication?  My issue is that even after I authenticate with the Forms Service with:

AuthenticationServiceClient auth = new AuthenticationServiceClient();

           auth.Login(u, p, null, false);

calls from my 'actual' data service fail with a Access Denied message, despite that I have already authenticated.  Is there something with cookies that isn't happening that does with a Silverlight app?  Any help would be appreciated, thanks!

seonsoo wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Fri, Aug 27 2010 2:33 AM

This article is really great

very well laid out.. wish I had read this sooner.

keep them posting!

seonsoo wrote re: Silverlight and WCF RIA Services (5–Authentication)
on Tue, Aug 31 2010 3:23 AM

This article is really, really useful!

IVisualDeveloper.net wrote RIA Services authentication problems on a standard web hosting environment
on Sat, Feb 11 2012 8:39 AM

RIA Services authentication problems on a standard web hosting environment

click through the up coming web page wrote click through the up coming web page
on Sun, Sep 21 2014 6:36 AM

Silverlight and WCF RIA Services (5–Authentication) - Mike Taulty's Blog - Mike Taulty's Blog

azaq-net.com wrote azaq-net.com
on Sat, Nov 15 2014 1:20 PM

Silverlight and WCF RIA Services (5–Authentication) - Mike Taulty's Blog - Mike Taulty's Blog