In the sample applications such as ProjectTracker, authorization rules are applied to roles that are created in code such as Administrator and ProjectManager. My question is, what about a situation where the programmer doesnt know the roles a customer may choose to create and use? For instance a customer customer may choose to create a sub-admin role, which able to perform some, but not all of the activities assigned to a typical Power User (Admin), in such a case, what happens?
Is it not possible for one to pull out authorization roles from a database, and apply them as appropriete?
Please some sample code may really help. Or if there is any such implementation out there, pls help point me to it.
Thank you in advance.
Yes, you can load the roles from the database. Honestly I think that is way over-complicated and is just asking for trouble, but it is absolutely possible.
What you need is a ReadOnlyBase object that gets the roles for a business object. Basically, you need to create an object model that represents your authorization metadata - roles, properties, etc.
Then in your AddAuthorizationRules() method, get this read-only metadata object as normal (so it uses the data portal) and use the metadata to add the rules to your business object.
AddAuthorizationRules() is called one time per AppDomain per business object type, so you'll only be retrieving the metadata for a given business object type one time (twice if you have a 3-tier deployment - once on the client, once on the server). So this is generally pretty efficient.
Wow! Thanks Mr. Lhotka for replying this! Its great to have you yourself reply. I must say your Framework rocks! Its just perfect for our next project, which is a Microfinance Management application. We particularly love the Authentication and authorization components, and the idea of mobile objects. Thanks a million.
I have been thinking about it, and i agree with your opinion that loading it from the database with be quiet complicated. I do not understand well your solution above. Maybe as we make progress in understanding the framework, we will understand more. What I think we will do is maybe add different roles to every business object, such as such as to Customer BO, we could add roles like EditCustomer, AddCustomer, DeleteCustomer, etc, instead of using a more generic role such as Administrator. That way, we can take each individual user of the system and assign her these roles as appropriete.
It will mean a little more work when it comes to assigning roles to users, but other great software such as Microsoft Dynamics NAV does the same. We can live with that until we know more... Or we can create another table that goups individual roles into RoleGroups, e.g. Cashiers, CustomerOfficers, etc?
Thank you for taking the time to reply. Atleast we are able to understand from the onset that it will be complicated to load roles from a DB, as such we will avoid that approach and stick to the samples available.
You mgiht also find this blog post to be useful
I think the confusion starts when the term 'role' is used as synonym for 'permission'. Unfortunatly the MS security model (IIdentity and IPrincipal) and derived models enhance this misunderstanding.
Here's what we do:
Permissions are defined by us, as we develop the code and the app at all. So, it's our concern to ask whether someone has a certain permission to do something. Our customers define the users and give them certain permissions directly and/or assign them to roles, which can be defined by the customers, too. And not only defined, but also fitted with certain permissions. So we have USER, ROLE and PERMISSION as core-objects and assignment objects (USER-PERMISSION, USER-ROLE, ROLE-PERMISSION). We use CSLA for the User/Permission-management and authentification/authorization as well and it works fine.
Indeed we made it a little more complex by adding DIVISION (sub-organisation), forbidding permissions and inherited permissions (EDIT-Permission inherits from VIEW-Permission...), but all works fine.
Key for that was to divide the concerns of the classes that handle authorization/authentification from those that deal with user/permission-management.
Only our way, no golden rule, but it works fine with CSLA and customers are pleased.
Don't hesitate to ask, if any question
Thank you very much, vschaak.
I agree with you on the inappropriate use of "role" as synonymous to "permission". I am new to CSLA, and in the past every app we'd worked on used Role-Based permissions. This means there are users, who are assigned toroles, and roles assigned persmisions. So i am thinking that CSLA handles authorization in the sense of permissions, not roles. That is not to say i'm suggesting CSLA is doing something wrong, just that its how it handles authorization.
Now to ask you. was it easy for you to add roles to CSLA? Did it involve extending certain classes in the framework? My desire was to create permisions, allow the customer to create roles with common permissions, and assign users to those roles. How were you able to achieve that?
Pardon my english. Its second language to me. Hope you understand. Thanks. Waiting...
no need to excuse for beeing no native english speaker. This applies to me too, as I 'm german
As said, dividing the business cases of authentification/authorization on the one hand and the management of Users, Roles and Permissions on the other was the key.
The first case handles what's need to verify a users account/credentials and to tell the app he(or she) logs in, whether he has certain permissions. Roles don't come in here, since you don't want to know if he is in the role 'poweruser', but if he has the permission "saveThis" or "DoThat" (which may be assigned to that role, but more on that later). All data about that is stored in DB and retrieved from there. So there is a sproc that retrieves a list of all the permissions that are effectivly assigned to a user (directly and through assigned roles). This list is put into the roles of a CSLAIdentity-object. So we put permissions into what's called 'roles'. This is the only place to twist the framework (at least a little), but as this stays internal, not that bad.
Another story, but simple is the assignment etc. of all that stuff. This is quite similar to PTracker since it has root objects and children. Just look at users, roles and permissions as regular business objects. OK, they are used to have immidiate effect on authorization/authentification, but THESE are not made to fullfill those tasks, since that is handled by the objects mentioned above.
So we have two 'User' objects:
a) used to authentify and authorize a login and for changing a password by the logged in user itself (inheriting from CSLAIdentity)
b) which is responsible for editing users and all that in an admin's management-app. This one handles User <-> Roles assignment, which is written to the DB (and retrieved by a)). A very nice effect of that is, that admins can easily figure out, not only "What are the roles, that are assigned to Mr.X?", but also "Which users are assigned to role Y?" or "Which roles are assigned to permission Z?"
I hope I made my points clear? (If not, just question)
Thank you for the indepth explanation. Didnt have time to try it out, so couldnt reply you. I will try it out tonight however, and get back to you if i am able to implement it as you did.
Once again, thanks.
Copyright (c) Marimer LLC