Need help with Security and Roles

Need help with Security and Roles

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


nj609eagle posted on Tuesday, September 01, 2009

In our old home-grown architecture, we did a lot of permission testing in the front end. There was no way to handle it within the business object.

Moving to CSLA we really like the idea of doing this in the business object.  The problem is when an object is being used within a different application. 

For example, we have a Membership system. The Membership systems is the central point for all People across all of the enterprise applications.  The membership system has a permission called "CanEditSSN" this permission is in one of several Roles, say "Clerk" and "Admin".  All of the role checking when using the Person object in the membership system works.  Now we are going to use  that Person object in another application, called "NewsLetters".  NewsLetters also has a role called "Admin", but that role does not include "CanEditSSN" in the Person Object.  Additionally, if the Person is in the Role of "Clerk" or "Admin" in the Membership System, and they are using the NewsLetters system, then they "CanEditSSN"

I'm sure i'm not the first person to come across this.  Any help or direction would be greatly appreciated

JoeFallon1 replied on Wednesday, September 02, 2009

In your Identity BO you assign the roles and permissions during log in and store the Identity for re-use.

You could add a test to the code that assigns roles and permissions to see if you are in AppX or AppY and then add fake roles and permissions as required for that app (since they do not really exist for that app.) Then your Identity will work for that app. e.g. you can ask it if it HasPermission("x") and get back True/False.

Joe

 

nj609eagle replied on Wednesday, September 02, 2009

After reading this article http://www.lhotka.net/weblog/PermissionbasedAuthorizationVsRolebasedAuthorization.aspx)

I think we are going to load our "Roles" with the permissions from all applications.  Using a Naming convention like Application.Permission.  Might me a little more to load upfront but should be able to pass it around when necessary

Then we can use these in the AuthorizationRules and CanEdit areas

Copyright (c) Marimer LLC