Howdy All,
We are starting to implement security on our application and I'm realizing I don't know near enough about CSLA and permissions to fully make these decisions. I have been reading but I'm still wondering some things. To start this is a Silverlight Application using CSLA and the Data_Portal. We have not yet migrated to the new await functionality recently released.
We have a "ProcessingGroup" which is a field on each of our primary working objects called a "case". I need to be able to limit the user can see based on the "ProccesingGroup(s)" they have been assigned to.
We had originally our own MembershipProvider/RoleProvider/User following the .net Forms Authentication model and added a customCollection called ProcessingGroups to the user. And that works great for having client side acess to this. But it doesn't get the data serverside. What is the best way to do this?
I have the CSLA books and am reading through them. Right now I'm looking through the 04-DataPortal.pdf but thought I would see if somebody might point me in the right direction. Also will the principles here change when we do migrate to the latest release of CSLA and use the await protocol?
is there a good working sample of a silverlight app with some level of security implemented out there somewhere that I could use as a reference?
thanks
dbl
The data portal book does discuss how and when the principal flows from a SL client to the app server. There are a couple models you can use that will ensure your server code has the same principal as the client.
Ok, I've read the ebooks and several posts on this site about implementing an authentication model with CSLA. When I read Rockies post in http://forums.lhotka.net/forums/p/10033/47084.aspx#47084 it shows using "Forms Authentication" and then it says that you have to use an IAuthorizeDataPortal implementation to get the Principal object server side. But if I read book for on page 91 is says this is only required if you do not want to send the principal with ever call. Since our call to validate the Principal is an expensive one we were planing on just including it with ever call.
Problem is I can't seem to get the Csla.ApplicationContext.User to get populated. In our current code I can see the User object in the Login Callback as below but the Csla.ApplicationContext.User object does not match. Is there some setting or some code that I'm missing? I've tried adding identity impersonate="true" setting in the Web.config but that doesn't seem to have made any difference.:
private void PerformLoginCallback(LoginOperation lo) { if (lo.HasError) { LoginResultToDisplay = lo.Error.Message; lo.MarkErrorAsHandled(); } else if (lo.LoginSuccess == false) { LoginResultToDisplay = "Login failed. Please check user name and password."; } else if (lo.LoginSuccess == true) { //notify our conductor that login succeeded so it can show what it should (controls, notification login worked) _loginSuccess = true; Debug.WriteLine(WebContext.Current.User); Debug.WriteLine(Csla.ApplicationContext.User.Identity.Name); Login loginMessage = new Login(_loginSuccess); eventAggregator.Publish(loginMessage); this.TryClose(); } CanPerformLogin = true; }
I have the Csla.Web reference included in my Web project.
Thanks
dbl
The web is different from smart client scenarios.
In the web, the web server (ASP.NET/IIS) is designed to forget everything in between client requests.
This is good because it provides scalability and enables relatively low-cost fault tolerance.
It is bad, because you can't easily keep anything in server memory between client requests - including the user's principal object.
You can overcome this by using Session. You can put the user's principal object in Session, and get it back from Session on each page request. The ProjectTracker web projects do this.
The drawback to using Session is that you are now maintaining state on the web server, so you lose scalability and low-cost fault tolerance. You can overcome some of that by using multi-server in-memory caching, or a centralized Session state server. Any good ASP.NET book should cover these topics around Session management quite thoroughly.
Rocky,
Thanks for the quick reply but I don't want to implement anything with Session. At least on on the DataPortal calls. I'm just trying to figure out how to get the User object to flow from the client to the server on the dataportal calls. The book does a good job of telling what not to do but I can't seem to put all the pieces together of what to do. For example on page 88 under "Accessing the Principal in Silverlight and WP7" it says:
Although the Silverlight platform defines the IPrincipal and IIdentity types, it does not provide a standard location to store or access the current principal. For example, there is no CurrentPrincipal property on the Thread type.
CSLA .NET addresses this issue by supporting the User property on the Csla.ApplicationContext type on Silverlight just like it does on .NET. The result is that any code using this User property will compile and work on .NET or Silverlight interchangeably.
But as you can see from my example code above the WebContext.Current.User is a valid implementation of the IPrincipal and IIdentity interfaces.
Then on page 92 is says:
Server Configuration for Silverlight Clients
For Silverlight and WP7 client applications, the server-side data portal does not verify that the principal sent from the client is null or not null based on the authentication type. This means that the authentication type on the client and server don’t have to match.
You should understand the ramifications of the values not matching.
If the client’s authentication type is custom and the server’s authentication type is Windows authentication, impersonation will not work properly because the server will ignore the principal object sent from the client.
This tells me how it "won't" work and implies if I don't these things it will work ... but maybe not.
So I tried adding the following line to my code from above:
Csla.ApplicationContext.User = WebContext.Current.User;
This causes a Serialization error even though I've marked the User object as [Serializable].
dbl
Copyright (c) Marimer LLC