Sunday, August 03, 2008
« CSLA .NET 3.5.1 released | Main | Using CSLA Light Part 3 »
CSLA Light Prerelease 2 available

I've put another prerelease of CSLA Light (CSLA for Silverlight) and CSLA .NET 3.6 online at www.lhotka.net/cslalight/download.aspx.

  1. Check out the new identity base classes in Csla.Security and Csla.Silverlight.Security - they are pretty darn cool!
  2. Check out the new Validator UI control - I think that is really cool!! It won't keep that name, because we're merging the Authorizer functionality directly into that control, so the result will be a consolidated control that does both things - we don't have a name for it yet...
  3. I'm pretty sure the ClientContext and GlobalContext work right, but the unit tests don't show that - so I'd recommend viewing that functionality with suspicion.
  4. I know some of the security tests don't work. Authentication is still evolving and some of the test apps are lagging a bit behind.

Please remember, these are very early preview builds. They are not stable. They are not complete. They may or may not work for you. They are not supported.

We have found, in testing, that Silverlight Beta 2 is not entirely stable. And that WCF in Silverlight is particularly unstable. If you run the unit tests in Silverlight you'll probably find what we find - that they randomly fail sometimes. They'll run. They'll fail. Then they'll run again. With no discernable pattern. Quite frustrating, but I guess this is the nature of working on a beta platform.

I have also put the sample app I've been blogging about at http://www.lhotka.net/files/cslalight/SimpleCslaLightAppvb-080803.zip. This sample app shows all the things I've talked about in my Part 1 and Part 2 posts, and I'll be coming out with more posts in the series in the next few days.

CSLA .NET | Silverlight
Sunday, August 03, 2008 10:47:53 PM (Central Standard Time, UTC-06:00)  #    Disclaimer  |  Comments [4]  |  Related posts:
CSLA 4 version 4.3.0 alpha available
Using CSLA 4: Windows Phone ebook available
CSLA 4 version 4.2 released
Improving CSLA 4 MobileFormatter behavior
Silverlight 6 doesn’t matter
DevCon slides
Friday, August 08, 2008 7:23:11 AM (Central Standard Time, UTC-06:00)
Great progress Rocky and the other Magenic guys.

I've been trying to get a Silverlight Principal working with a WindowsIdentity in my code, and either I'm doing something wrong, or the Windows auth isnt complete.
I've basically tried to copy what was done in the test harness regarding creating a subclass of the BusinessPrincipalBase and Csla.Silverlight.Security.WindowsIdentity respectively.

When I test doing an async Windows authentication the username that I keep getting back in the Principal object in Silverlight is the ASPNET user (I'm debugging through IIS).
The reason for this I'm guessing is that the PopulateWindowsIdentity call in the Csla.Silverlight.Security.WindowsIdentity class is executing against the WcfPortal web service user, with the browser user effectively being lost once the web service kicks in on the server.

Should I be trying to get the web service to impersonate as the browser user just for logins?
Or should I be looking at trying ASPNetCompatibility mode for the WCF?

I'd be interested to hear how you envisioned Windows authentication flowing from the Silverlight client user through to the CSLA.Net server.
Paul
Friday, August 08, 2008 8:13:01 AM (Central Standard Time, UTC-06:00)
The intent behind WindowsIdentity is to carry back data copied out of the Windows principal/identity on the web server. That directly implies that you have your web server configured to require the user to provide Windows credentials, and to impersonate the Windows user.
Rockford Lhotka
Friday, August 08, 2008 8:25:51 AM (Central Standard Time, UTC-06:00)
My issue with that approach is that then I need to make sure that all users of the Silverlight application have sufficient access to the web server files due to the impersonation occurring.

Which to me is more setup and less safe for the web files.
At least that's my understanding?
Paul
Friday, August 08, 2008 8:33:05 AM (Central Standard Time, UTC-06:00)
I'm open to suggestions on other approaches.

Ultimately the user is going to have to authenticate with some Windows server so a Windows principal/identity are created, thus allowing us to pull information from those objects into some objects that can be serialized back to the Silverlight client.

While we could get the username/password/domain from the user on the client, we'd have to pass that to the server and then do our own impersonation on the server. I don't like that idea, because it makes it too easy for a hacker to intercept the credentials - just one slip-up on deployment of this scheme and you'd have a nasty security hole.
Rockford Lhotka
Comments are closed.