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
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
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