Linking security (user) and a business objectLinking security (user) and a business object
Old forum URL: forums.lhotka.net/forums/t/2147.aspx
juddaman posted on Tuesday, January 16, 2007
Hello,
I'm developing a HR application, which will basically have two user interfaces. One will be a Windows App for HR staff to put on new jobs. The other will be a web interface for Applicants to apply for jobs.
I'm having trouble working out how to link the security (login process) to the business objects access.
What I need is for each Applicant only to be able to edit their own profile (i.e. Name, Address, Education history, etc).
So in the AddAuthorizationRules method I was looking to add something like
AuthorizationRules.AllowUserWrite("PropertyName",this.Username).
As this doesn't exist I'm not sure what to do. Also I see many issues arising about keeping the Principal and the business class "together" i.e. what happen when a user want to remove their account, change username, etc.
I've done a bit of searching and found some similar problems where it is suggested a "data owner" system is used, this seams to relate to my problem. I'm very new to the Business Objects framework and quite new to C# .NET so any gentle guidance would be much appreciated. :-)
Thank you,
GeorgeBrian Criswell replied on Tuesday, January 16, 2007
Take a look at overriding CanReadProperty and CanWriteProperty. Also, an applicant should not be able to retrieve anyone's profile other than their own. You may want to just keep them from loading anyone else's profile and leave it at that.
juddaman replied on Sunday, January 21, 2007
Hey Brian, thank you for pointing me in the right direction. Much appreciated. George
ajj3085 replied on Monday, January 22, 2007
George,
Check out the Proxy design pattern. In "Head First Design Patterns" they discuss how to control security to an object through a proxy. Might not be necessary with the features Csla provides, but it wouldn't hurt to check out another way to acomplish what you want.
Andy
skagen00 replied on Monday, January 22, 2007
If you are talking about the login process w/ controls of ASP.Net (Membership provider API) in conjunction with the Csla's Principal & Identity, etc - perhaps I can suggest a few things.
First, we are using the Membership API & Role API of ASP.Net, and we'll be utilizing it in both Web and Windows where necessary.
The login control's authenticate will do this:
e.Authenticated = ProPrincipal.Login(Login1.UserName, Login1.Password);
HttpContext.Current.Session["CslaPrincipal"] = Csla.ApplicationContext.User;
ProPrincipal will invoke the Membership API and utilize the Role API to establish the proper Identity & Roles. For the Membership API and Role API, I've created a CslaMembershipProvider and CslaRoleProvider, which wraps the entirety of the standard implementation of any appropriate provider to facilitate remoting where necessary. I hope to add this as a contribution once I have the opportunity to clean it up, because I think many developing in the Web would appreciate the ability to use all of the implementation of the AspSqlMembershipProvider and AspSqlRoleProvider, for example, with remoting enabled.
By fulfilling the Membership API and Role API in this way, we can leverage the Asp.Net configuration tool, which effectively gives us a simple manner to manage users. Beyond that, there's all that password hashing/changing/resetting and crap all built in to the provided implementations.
And the application's Csla type principal is attached to the Csla.ApplicationContext upon login, so that it's available for use in the business object logic - "IsInRole"...
May be off-target from what you were looking for but if it is on-target I hope it helps.
Copyright (c) Marimer LLC