Single Sign-On in ASP.NET and Silverlight

Single Sign-On in ASP.NET and Silverlight

Old forum URL: forums.lhotka.net/forums/t/6544.aspx


SWITCH posted on Monday, March 02, 2009

Hi,

I am using CLSA Light to build a Silveright app whose design calls for Single Sign-On (SSO). The goal is to protect the .aspx page that is hosting the Silverlight control with ASP.NET Forms Authentication. The user should only have to log in to the ASP.NET Forms Login page once and not have to log in again when the Silverlight app is loaded.

For SSO to be achieved, I'm thinking that somehow I need to set Csla.ApplicationContext.User to the valid Principal object (stored in HttpContext.Current.User) that was created when the user logged into the Forms login page. The Silverlight app needs a valid Principal object to leverage the CLSA authorization features. That said, I'm not really sure how to get access to the HttpContext.Current.User set by ASP.NET Forms Authentication or even if this is the right approach?

It seems wrong to force the user to have to log in to the Forms Login page and then login again within the Silverlight app.

Any ideas would be greatly appreciated!

Thanks, Richard

RockfordLhotka replied on Tuesday, March 03, 2009

This should be pretty easy, assuming the data portal is hosted in the same web app the user logged in to.

As your SL app starts up, just send a "login" request through the data portal and have that request return the Csla.ApplicationContext.User value. That object is serializable by definition, so it should just flow back to the SL client.

You can retrieve it using a CommandBase or ReadOnlyBase object - just put the server's IPrincipal object into a property of the business object, and when it gets back to the client set Csla.ApplicationContext.User to this value.

Something more or less like this:

using System;
using System.Security.Principal;
using Csla;
using Csla.Serialization;

[Serializable]
public class PrincipalGetter : ReadOnlyBase<PrincipalGetter>
{
  public static void BeginLogin()
  {
    var dp = new DataPortal<PrincipalGetter>();
    dp.FetchComplete += (o, e) =>
      {
        if (e.Object != null)
        {
           Csla.ApplicationContext.User = e.Object.User;
        }
      };
    dp.BeginFetch();
  }

  public static PropertyInfo<IPrincipal> UserProperty =
       RegisterProperty<IPrincipal>(c => c.User);
  public IPrincipal User
  {
    get { return ReadProperty(UserProperty); }
    private set { LoadProperty(UserProperty, value); }
  }

#if !SILVERLIGHT

  private void DataPortal_Fetch()
  {
    this.User = Csla.ApplicationContext.User;
  }

#endif
}

This presupposes your server-side principal and identity objects inherit from CSLA base classes and use managed property values so they can be serialized to the SL client.

Just make sure to call BeginLogin() as your SL app starts up. And you may need to add some code to make sure the user can't start interacting with the app until this returns (remember it is async).

SWITCH replied on Tuesday, March 03, 2009

Perfect! Thanks Rocky! That's what I was slowly coming to the conclusion I needed to do. Thanks for taking the time to put together the example. It's just what I need.

Cheers!

SWITCH replied on Tuesday, March 03, 2009

Hi Rocky,

I've had a chance to implement your suggestion to retrieve the principal using a ReadOnlyBase object, but for some reason, in the DataPortal_Fetch method the Csla.ApplicationContext.User property is always set to  {Csla.Security.UnauthenticatedPrincipal}. At this point even the HttpContext.Current.User property on the server is set to  {Csla.Security.UnauthenticatedPrincipal}. I would have expected a valid authenticated instance of a principal object.

I have the data portal hosted in the same web app that I logged in to. I am also able to access a valid HttpContext.Current.User object from a test ASP.NET page in the same site. I can't seem to figure out why the Csla.ApplicationContext.User is not set since I see in the ApplicationContext class that if the HttpContext.Current != null, it will be used to set the Csla.ApplictionContext.User. Does the framework ever reset the principal stored in HttpContext.Current.User?

I'm new to CSLA so I'm likely missing something simple. I've pasted my custom PrincipalGetter class below:

Thanks very much!

Richard
______________________________

using System;
using System.Security.Principal;
using Csla;
using Csla.Serialization;

namespace CeCslaAppPrototype.Business.Security
{
  [
Serializable]
  public class PrincipalGetter : ReadOnlyBase<PrincipalGetter>
  {
    public static void BeginLogin(EventHandler<EventArgs> completed)
    {
      var dp = new DataPortal<PrincipalGetter>();
      dp.FetchCompleted += (o, e) =>
      {
        if (e.Object != null)
        {
          Csla.
ApplicationContext.User = e.Object.User;
          completed(
null, EventArgs.Empty);
        }
      };
      dp.BeginFetch();
    }

    public static PropertyInfo<IPrincipal> UserProperty = 
        RegisterProperty(
new PropertyInfo<IPrincipal>("User", "User Principal"));

    public IPrincipal User
    {
      get { return GetProperty(UserProperty); }
      set { LoadProperty(UserProperty, value); }
    }

    #if !SILVERLIGHT
    private void DataPortal_Fetch()
    {
      // This is always {Csla.Security.UnauthenticatedPrincipal} 
      this.User = Csla.ApplicationContext.User; 
    }
    #endif
  }
}

RockfordLhotka replied on Tuesday, March 03, 2009

The thing you are missing is an ASP.NET thing, not a CSLA thing.

 

I don’t remember the setting off the top of my head, but you need to tell the WCF service (the data portal host) to use the user identity of the ASP.NET process.

 

I think one or two of our security samples does this. Certainly the Windows one does, though it is using a Windows identity rather than a membership identity.

 

Rocky

 

SWITCH replied on Wednesday, March 04, 2009

Hi Rocky, that makes sense now and I've been trying to locate the examples you mentioned but couldn't find them. Sorry to have to ask, but could you point me at the examples you were thinking of so I can dig into this further?

In the meantime I did some research and I believe the settings that I need to enable in the Web.Config are as follows:

Under system.serviceModel add the following to enable allow access to the HttpContext:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>

Under ServiceBehaviors add the following to enable impersonation:
<serviceAuthorization impersonateCallerForAllOperations="true"/>

However, enabling the impersonateCallerForAllOperations setting causes the following exception to be raised in the EndFetch method in the WcfPortalClientChannel class in the CSLA Light framework:

   at System.ServiceModel.AsyncResult.End[TAsyncResult](IAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.SendAsyncResult.End(SendAsyncResult result)
   at System.ServiceModel.Channels.ServiceChannel.EndCall(String action, Object[] outs, IAsyncResult result)
   at System.ServiceModel.ClientBase`1.ChannelBase`1.EndInvoke(String methodName, Object[] args, IAsyncResult result)
   at Csla.WcfPortal.WcfPortalClient.WcfPortalClientChannel.EndFetch(IAsyncResult result)
   at Csla.WcfPortal.WcfPortalClient.Csla.WcfPortal.IWcfPortal.EndFetch(IAsyncResult result)
   at Csla.WcfPortal.WcfPortalClient.OnEndFetch(IAsyncResult result)
   at System.ServiceModel.ClientBase`1.OnAsyncCallCompleted(IAsyncResult result)

If I disable the impersonateCallerForAllOperations setting, the exception is no longer raised but it still gives a Null HttpContext.Current.User principle object in the DataPortal_Fetch method. Is it possible that the account WCF is impersonating does not have permissions to call the server?

This seems to be proving tricky for me to sort out, likely because this is my first real attempt at using WCF...

RockfordLhotka replied on Wednesday, March 04, 2009

The security “samples” are actually in the test download, because we created them to test the various authn models, not really as samples.

 

Rocky

 

 

SWITCH replied on Wednesday, March 04, 2009

Even through I'm using ASP.NET Forms Authentication instead of Windows auth, it appears I have my project configured correctly in the web.config. I can't see anything obvious in the security test examples that tells WCF to use the user identity of the ASP.NET process. I also confirmed that the WCF and ASP.NET are both running in the same AppDomain on the server. Based on what I have been reading, all you should have to do is enable asp.net compatibility in order to gain access to the HttpContext in WCF (<serviceHostingEnvironment aspNetCompatibilityEnabled="true"/>).

I plan to dig into this more tonight and I'll probably setup a simplified WCF service to test this outside of CSLA and make sure I can get that working first. I'm sure it's something simple I'm missing... security is fun!

Thanks for help so far Rocky!

SWITCH replied on Wednesday, March 04, 2009

Ok, so I think I have some more useful information on this problem.

It appears the issue is actually not with my ASP.NET configuration rather it is in the CSLA Silverlight Csla.Server.Hosts.Silverlight.WcfPortal class. I determined this because if I add a new WCF service to my web site and enable aspnet compatibility (as above), code in the WCF service is able to access the HttpContext no problem (so I'm not crazy!;)

When the Fetch(CriteriaRequest request) method is called by the data portal, the SetContext() method is called and a request object from the client (I'm assuming - sorry I'm new) is passed in. The SetContext() method then does the following:

ApplicationContext.User = (IPrincipal)MobileFormatter.Deserialize(request.Principal);

If I inspect the ApplicationContext.User prior to the above assignment, it contains a valid {System.Web.Security.RolePrincipal} object which is what I am after! However, after the assignment operation is complete, HttpContext.Current.User and Thread.CurrentPrincipal is overwritten and is set to a {Csla.Security.UnauthenticatedPrincipal} object.

It seems that the Silverlight WcfPortal assumes and expects to receive a valid authenticated Principal object in the request from the client, so it doesn't appear that it will be possible to send a "login" request through data portal and have that request return the Csla.ApplicationContext.User (which is really HttpContext.Current.User from ASP.NET).

I don't really know what the implications of this would be, but would it make more sense to prevent overwriting the HttpContext.Current.User principal (if it contains an authenticated Principal object) with an unathenticated Csla security Principal object?

The way I see it now, there is no way to accomplish my goal of Single Sign-On unless I stick with creating a separate non-Csla WCF Service to retrieve the HttpContext. (Wow, this is great! I feel like I'm learning lots!:)

Thoughts?

Thanks!


     

RockfordLhotka replied on Wednesday, March 04, 2009

That is interesting. Yes, I see exactly what you are saying.

 

I would prefer to support your scenario directly, though I’m not entirely sure what the solution should be.

 

Some sort of rule on whether to impersonate the client identity on the server seems like the answer, though I don’t know if it can be as arbitrary as looking at whether there’s already an authenticated principal on the server. That’d be a pretty simple answer though :)

 

Rocky

SWITCH replied on Thursday, March 05, 2009

It kind of makes sense to me that you could make some kind of a rule on the server that would always return the authenticated HttpContext.Current.User principal on the server when aspNetCompatibilityEnabled="true".

You wouldn't always have an authenticated HttpContext.Current.User principal object anyways... only when aspNetCompatibilityEnabled="true" in the web.config. The rest of the time it would be null I think.

If someone has aspNetCompt enabled, I suspect an assumption could be made that their intention was that they wanted to access/share the principal set by ASP.NET with the WCF data portal.

Hopefully that suggestion is not way off-base. I'm really new to CSLA but plan to use it for a new Silverlight project so hopefully my knowledge of Csla will improve quickly so I can provide more valuable feedback in the future.

Cheers, Richard

P.S. If you were to add support for this scenario to Csla.net, what version would you expect it to appear in? I think it's a pretty valuable feature.

 

RockfordLhotka replied on Thursday, March 05, 2009

I’m adding this to the wish list. Version 3.6.2 is feature-complete at this point, so some resolution to this will likely be in 3.6.3.

 

Rocky

SWITCH replied on Thursday, March 05, 2009

Great, thanks for doing that Rocky! I always hate doing it, but until then I'll likely just tweak the latest framework myself so it does what I need then make the changes necessary when the new feature is available in a future Csla release.

Thanks for all of you help with this. It's nice to know there's support behind the framework!

SWITCH replied on Friday, March 06, 2009

So I have had requests to publish my progress with this since it seems like a common scenario others are running into. However I have hit another stumbling block and haven't found a solution yet.

I am only using Forms authentication, so what I am attempting to do is modify the Csla framework (until the enhancement is made) to prevent overwriting the ApplicationContext.User principal with a UnauthenticatedPrincipal principal found in the request from the Silverlight client by modifying the Csla.Server.Hosts.Silverlight.WcfPoral class as follows:

private void SetContext(CriteriaRequest request)
{
  ApplicationContext.SetContext((ContextDictionary)MobileFormatter.Deserialize(request.ClientContext), (ContextDictionary)MobileFormatter.Deserialize(request.GlobalContext));
  IPrincipal principal = (IPrincipal)MobileFormatter.Deserialize(request.Principal);
  if ((principal.GetType() != typeof(Csla.Security.UnauthenticatedPrincipal)) && (HttpContext.Current.User != null) && HttpContext.Current.User.Identity.IsAuthenticated)
    ApplicationContext.User = principal;
}

With the above change, the ApplicationContext.User is not overwritten and is now available to return to the client.

The next issue becomes returning a Principal object in my PrincipalGetter business object that I created (see below). If I create a managed backing field to return the principal I get the following error from the MobileFormatter class:

Type 'System.Web.Security.RolePrincipal' with data contract name 'RolePrincipal:http://schemas.datacontract.org/2004/07/System.Web.Security' is not expected. Add any types not known statically to the list of known types - for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.

It seems that the MobileFormatter does not understand how to serialize the RolePrincipal object that is now stored in my PrincipalGetter class (shown below). I'm not sure how I can get the RolePrincipal serialized and sent back to the client?

Any guidance would be greatly appreciated!

Thanks, Richard

More info:

The PrincipalGetter ReadOnlyBase object is defined as follows:

[Serializable]
public class PrincipalGetter : ReadOnlyBase<PrincipalGetter>
{
  public static void BeginLogin(EventHandler<EventArgs> completed)
  {
    var dp = new DataPortal<PrincipalGetter>();
    dp.FetchCompleted += (o, e) =>
    {
      if (e.Object != null)
      {
        Csla.
ApplicationContext.User = e.Object.User;
        completed(
null, EventArgs.Empty);
      }
    };
    dp.BeginFetch();
  }
  private static PropertyInfo<IPrincipal> UserProperty = RegisterProperty(new PropertyInfo<IPrincipal>("User", "User Principal"));
 
public IPrincipal User
  {
    get { return GetProperty(UserProperty); }
    set { LoadProperty(UserProperty, value); }
  }

  #if !SILVERLIGHT
  private void DataPortal_Fetch()
  {
    this.User = Csla.ApplicationContext.User; 
  }
  #endif
  }
}

RockfordLhotka replied on Friday, March 06, 2009

The MobileFormatter only knows how to serialize things that implement IMobileObject (or that inherit from MobileObject, MobileList, etc - because they implement the interface).

The MembershipIdentity, CslaIdentity and WindowsIdentity classes in CSLA .NET all inherit from MobileObject, and so can be serialized.

You'll probably need to do something like the WindowsIdentity class does - which is to load itself with a copy of the data from the server-side principal/identity, because the server-side WindowsPrincipal and WindowsIdentity objects aren't serializable at all.

So what is on the SL client is just a copy of the server-side data, but that works because it is the same list of roles and the same username, which is all that really matters.

SWITCH replied on Wednesday, March 11, 2009

Thanks Rocky! That was the issue.

I created a custom principal that derives from CslaIdentity and in my PrincipalGetter business object's DataPortal_Fetch() method I load the custom principal with data with from HttpContext.Current.User principal object. In order to get access to the HttpContext, I had to change both of the SetContext() methods in the Csla.Server.Hosts.Silverlight.WcfPortal class as follows:

private void SetContext(CriteriaRequest request)
{
  ApplicationContext.SetContext((ContextDictionary)MobileFormatter.Deserialize(request.ClientContext), (ContextDictionary)MobileFormatter.Deserialize(request.GlobalContext));
  IPrincipal principal = (IPrincipal)MobileFormatter.Deserialize(request.Principal);

  // Check to see if the client is already authenticated in ASP.NET. If the principal received from the client is a Csla UnauthenticatedPrincipal,
  // check to see if there is an authenticated principal in the HttpContext. In order for this to work, aspnet compatibility mode must be enabled and
  // Forms authentication must be enabled so that the HttpContext.Current.User principal is available to the WCF Data Portal service.
  if ((principal.GetType() != typeof(Csla.Security.UnauthenticatedPrincipal)) && (HttpContext.Current.User != null) && HttpContext.Current.User.Identity.IsAuthenticated)
    ApplicationContext.User = principal;
  else
    ApplicationContext.User = HttpContext.Current.User as IPrincipal;
}

I think I have a workable solution now, but I did hit a few more snags. Since I wanted to secure the DataPortal service AND Silverlight client app using Forms Authentication, the issue I had is that when the Forms session expires, a communication error is raised to the client because the dataportal service is unavailable.

To get around this, I created a new WCF service that uses the ASP.NET System.Web.ApplicationServices.AuthenticationService. This server was not protected by Forms Authentication and is used to handle requests from the Silverlight Client related to authentication. When an error is encountered in the Silverlight client, I can use this new service to check to see if the client is authenticated by using the IsLoggedInAsync() method of the unsecured service. If the user is no longer logged in, I can pop-up a dialog window and ask for their credentials and I can call the WCF service's LoginAsync() method to log in again and get a new token. This allows the user to continue with their workflow in the client app instead of having to refresh the browser window and get redirected to a Forms Login page. That would cause any work they may have done when the session times out to be lost. If the user is still logged in, I just pass through the original error message because I can assume it is not related to authentication.

My approach may not be the best approach but I think it should work for what I need.

I think the scenario I've been fighting with will become very common place so it may be worth trying to come up with a cleaner solution that integrates better into the CSLA framework or design patterns in the future. I've listed the key requirements I had below for future reference:

Single Sign On Requirements:

  1. The download of the Silverlight App itself is protected by Forms Authentication.
  2. The Data Portal is protected by Forms Authentication.
  3. The user does not want to log in again to the Silverlight client application if they have already logged in using Forms Authentication prior to downloading the Silverlight app.
  4. If the Forms Authentication session times out, the Silverlight client must be able to prompt for credentials and let the user continue their workflow once valid credentials are entered without losing their work, OR cancel the request to the server if authentication failed so they can at least copy any of their work out of the app.

Anyways, hope this helps people out there hitting the same issues.

Cheers, Richard

RobKraft replied on Tuesday, November 24, 2009

Thanks Richard and Rocky for your posts on this thread. I intend to do something similar; but I plan to put the CSLA Principal object in the session, then pull it out of the session and assign it to ApplicationContext.User.

private void DataPortal_Fetch()
{
ApplicationContext.User = (OurPrincipal)System.Web.HttpContext.Current.Session["Principal"];

I will pull it from the session variable any time I feel the need to "recheck" on the server side that the user credentials allow the attempted action.
Does this approach seem reasonable, or am I overlooking something fundamental?
I think this approach also reduces the risk that a hacker on the client side could forge a false identity.

RockfordLhotka replied on Tuesday, November 24, 2009

You can create an authorizer (I think it is IAuthorizeDataPortal) method
that is invoked first-thing when a data portal call comes in from the
client. That way you'd always get the principal set without having to
remember to do it in each DataPortal_XYZ method.

decius replied on Tuesday, October 04, 2011

Has this been resolved since this discussion? I too am need SSO for a silverlight csla.net app that lives in a forms based website.

RockfordLhotka replied on Tuesday, October 04, 2011

Yes. The Using CSLA 4 ebook series covers this in the Data Portal Configuration and WPF/Silverlight ebooks.

However, there's a bug in 4.1 that blocks the scenario. That bug is resolved in 4.2. Otherwise it works as described in the Data Portal Configuration ebook.

decius replied on Wednesday, October 05, 2011

 may have just missed it, but I can't find anywhere in the DataPortal Configuration book that references single sign on for silverlight application specifically.

Do I just need to simply utilize the "Membership" authentication type? Is it that simple? Wouldn't the WCF call need to send the Forms cookie somehow etc?

I think I see my problem, I'm trying to run an out of browser SSO scenario. My goal was to allow the user to launch the app in two ways:

  1. while logged into the website they can launch it from the "attached" SL app which simply "detached" the app or
  2. Startup "detached" and prompt them with credentials

The goal is to prevent them from having to log in twice if they've already logged into the website. Unfortunately, in scenario 1, once detached I can't pull from session at that point and I can't pull from Csla.ApplicationContext.User.... Looks like this is simply not possible, am I wrong?

(The out of browser is somewhat of a requirement here, because the application needs access to the My Documents folder)

RockfordLhotka replied on Wednesday, October 05, 2011

Look at the section starting on page 100-102.

RockfordLhotka replied on Wednesday, October 05, 2011

The technique works with custom and membership models (they are really the same).

Basically, follow these steps:

 

  1. Implement a custom identity that goes to the server and retrieves the username and roles of the server-side principal (the ebook shows how to do this for membership and Windows server-side principals)
  2. As the SL app starts up, immediately fetch that custom identity and put the resulting principal in ApplicationContext.User - now the client has a principal that is a copy of the server-side data - as close to the server principal as you can get really
  3. Set the client-side AuthenticationType to Windows so it doesn't send the client-side principal to the server on every data portal call
  4. Set the server-side AuthenticationType to Windows so it doesn't expect the client to send the principal

This all works, assuming that the user has authenticated with the server before the SL app launches. Basically, if using custom or membership authentication, the user must log into the web site before the SL app is loaded. If using Windows authentication, the user must log into the web site with their Windows credentials before the SL app is loaded.

RockfordLhotka replied on Wednesday, October 05, 2011

And again, there was a bug (fixed in 4.2) that blocked this scenario from completely working. Specifically steps 3-4 in my previous post require 4.2.

decius replied on Wednesday, October 05, 2011

Thanks for the help Rocky. I must be missing something though, because I've followed these steps explicitly, but once the PrincipalGetter gets to the server-side in the DataPortal_Fetch method, the Principal is an unauthenticated System.Security.Principal.GenericPrincipal.

1. Implemented custom CslaIdentity and CslaPrincipal (Didn't use membership identity because app was built before native support)

2. Async is made call to the PrincipalGetter class to fetch the principal values from the server as soon as the startup object is initialized

3. Before initializeComponent in App.xaml.cs: Csla.ApplicationContext.AuthenticationType = "Windows";

4. Server side web.config: <add key="CslaAuthentication" value="Windows"/>

Logged in to the web app, loaded the SL app with breakpoint on the server-side PrincipalGetter fetch method and the principal is System.Security.Principal.GenericPrincipal rather than my custom authenticated principal. Interestingly, I tried pulling the persisted value in the Session, but found that 'System.Web.HttpContext.Current' is null.  Seems as though my Silverlight application isn't running in the httpcontext. I suppose this problem is non-Csla, but can anyone shove me in the right direction here?

SWITCH replied on Wednesday, October 05, 2011

Have you checked your web.config to make sure aspNetCompatibilityEnabled="true"? I once had an issue where this was not set, in which case I think HttpContext.Current is always null.

 

decius replied on Wednesday, October 05, 2011

Thanks SWITCH! That helps me make progress. I'm now seeing the authenticated System.Web.Security.RolePrincipal in the Csla.ApplicationContext.User property. I was hoping/expecting to see my custom Principal, is there anyway to configure Csla so that my CustomPrincipal value is loaded?

I suppose I COULD just load the principal manually once on the server and store my needed values into the PrincipalGetter and send it back to the client (but only if the RolePrincipal was indeed properly authenticated).

Can I safely trust the RolePrincipal and do this? Or is there an easier way?

RockfordLhotka replied on Wednesday, October 05, 2011

This is discussed in the Using CSLA 4: ASP.NET MVC ebook - and I think in the 2008 book too. To have your custom principal available on the web site, request after request after request, you need to implement code in global.asax.cs to reload the principal on each page request.

decius replied on Thursday, October 06, 2011

Thanks Rocky, though I am implementing the global.aspx.cs persisting code for principal. However I had forgot about one very relevant line of code that I had taken from the Sample project I snagged it from a year ago:

if(Csla.ApplicationContext.AuthenticationType="Windows") return;

I suppose this was written so that the code was smart enough to be prepared for various auth types for demonstration... but it was written before using the Windows Auth type in this way for Silverlight.

So, since I'm not TRUELY using windows authentication  (just doing that to "trick" the server to not expect the client to send the principal) I should just remove this line from my global app code, right?

Thanks so much yet again, Rocky!

decius replied on Thursday, October 06, 2011

I'm sorry to drag this thread on, but in taking my own advice above, it seems that DataPortalResult object is null when it gets back to the client.

I notice that my compress host is properly compressing the object during convertresponse, but on the compressedProxy, ConvertResponse is never getting called. Strange because this was working fine until implementing the above. :(

NOTE: as soon as I change the server's authtype back from "Windows" to "Csla" the proxyhost works again but the Principal on the server is now null as would be expected. What am I missing?

decius replied on Thursday, October 06, 2011

Got it! A stupid moment on my part. I was just missing an assembly reference. The DataPortalResult error property spelled this out for me plain as day, but it took me hooking up the CSLA source code and stepping through to realize to check those contents. Doh!

Adding the reference that contained my principal object resolved the problem.

EDIT: Actually, I decided to just send it to the client as a CslaPrincipal because my custom principal has a ton of other custom child objects that had been developed over time, and I was going to have to add each object to the client library and silverlightify them (yuk).

EDIT AGAIN: Okay, so that won't work either, it's still requiring the custom type during deserialization even if I cast it. If I only need to check if the user is logged in on the web server or not, is there any harm to just passing the bool IsAuthenticated value back alone? That would save me a lot of trouble.

NET-H24 replied on Monday, April 29, 2013

Cant we achieve this keeping Authentication to be CSLA instead of Windows

Copyright (c) Marimer LLC