I've read a number of posts about this in the forum and I'm also trying to learn from the e-books, but I'm still somewhat confused. For an intranet Silverlight app, I want to use Windows authentication.
I had wanted my Silverlight 4 (CSLA 4.1) app to pass the Csla.ApplicationContext.User.Identity.Name value to the DP (WcfPortal service) so I could pass that, in turn, to the DAL. But the Identity.Name in Silverlight is always null. I guess that makes sense when I think about it. So I started to think that I should not worry about the Silverlight client passing the username and instead have the .NET (server) code pull this, since it would get it from IIS.
But then I read this older post from Rocky on a similar-sounding situation, and it sounds like he is stating that, while I could rely on the server-side code to deal with this, Silverlight could also store the Windows-provided identity for this type of purpose. But then he says:
"Arguably the SL client wouldn't need to pass this principal to the server each time, because the server should already know (via the browser login) which Windows user to impersonate on each call. But that'd preclude the use of an IAuthorizeDataPortal check to make sure the client principal still matches the server principal... "
I'm not quite sure what this last sentence means...what is preferred in my intranet scenario? Letting the server handle it with each request, or use an IAuthorizeDataPortal check?
Thanks.
Tim
I think I explain this pretty well in the Data Portal Configuration ebook.
Normally, nothing else needs to be done now, because the browser/server work together to ensure the server always impersonates the Windows user. And the SL client has the username and group/role information so it can do normal authorization.
This all presupposes IIS/ASP.NET are configured to require the user to log on, and to do impersonation.
Thanks for your reply. I am still working my way through (re-reading) the data portal e-book. What has to occur in the data portal call to get the user's identity information? And is this a particular DP method that I would be calling?
From the SL side it is a custom principal/identity. There's a pre-created WindowsIdentity type in CSLA (Csla.Silverlight.Security I think) that already knows how to copy the Windows identity information into a custom identity object.
There's an example in the download for the ebook - in the Authentication\Windows folder.
I've been looking at the example projects in the Auth\Windows folder and they are definitely helpful.
Sort of off topic, I wanted to ask why you implement INotifyPropertyChanged on the MainPageViewModel VM intsead of inheriting from Csla.Xaml.ViewModel. Was it just an easier way to demonstrate what you were doing? Or is this a recommended approach for a VM that manages authentication in Silverlight? Thanks.
Tim
The ViewModel<T> class is great for building a viewmodel that manages one business object.
The main page viewmodel (or presenter) for a typical app will expose/manage numerous objects - MainContent, StatusContent, ErrorContent, MenuContent, etc.
So ViewModel<T> isn't terribly useful. But any viewmodel must at least implement INotifyPropertyChanged (or subclass DependencyObject) to participate in XAML binding.
Copyright (c) Marimer LLC