I moved this to its own thread to keep things more organized. And because there are other people on the forum with differing (and very valid) opinions that may provide insight. You should search the forum though, because this topic has been discussed before.
In my view there are just two scenarios:
By far, most people fit into scenario 1. At runtime they check against a flat list of roles/permissions/whatever-you-want-to-call-them to see if the user is allowed.
Sometimes "roles" are merely containers for lists of "permissions" - they act as an administrative helper so some admin can assign entire groups of permissions to a user by putting the user in a role.
But at runtime only the "permissions" are checked - the "roles" are ignored. In this case you can "misuse" IsInRole() to see if the user has a permission. This is the simplest solution.
If you fit into scenario 2 then your code sometimes calls IsInRole() to check real roles. And sometimes your code calls HasPermission() to check a permission. And your code mixes and matches those two models. To me this seems overly complex, but it does happen from time to time.
In either case, remember that you can load the role/permissions required by your object from a database. These values are just strings after all, so loading them from a table is not hard. So your idea of a GetRolesForAction() method seems entirely possible, but wouldn't work as you describe without some effort on your part.
You wouldn't need to alter CSLA. CSLA isn't the issue, .NET is the issue. .NET defines the IPrincipal interface with IsInRoles(). This is the standard authz model in .NET, and that's why CSLA uses this model.
But you can (must anyway) create your own custom principal class. And in that class you can go beyond the IPrincipal interface by adding anything you want, including IsInRoles().
There are a couple catches though.
First, you must cast the User object to your custom type:
CustomPrincipal p = (CustomPrincipal)Csla.ApplicationContext.User;
bool result = p.IsInRoles(...);
Second, CSLA has no knowledge of anything beyond IPrincipal. But you can override CanReadProperty(), CanWriteProperty() and CanExecuteMethod() in your base class (because you should have a base class of your own between BusinessBase and your business objects anyway), and in that method you can call your custom IsInRoles() or whatever.
Unfortunately, this entirely bypasses CSLA's authz result caching and other features. The wish list includes a request to make the bottom-level IsInRole() call delegate based, allowing you to plug in at a lower level, and that would make this harder to implement, but more elegant and powerful. I don't know when I'll get to that change though.
jhoojharsinghyadav:
Rocky,
1 more thing , why there isnt any place for permissions . in CSLa , may be i could be wrong as i cant find them .
but as per mine understanding it should go like this ,
a permission base class should be there and instead of checking the user.inrole at every action (add,delete) etc it should go like for asking the user.haspermission(permissionname) .
See my previous post regarding the normal (admin-time) relationship between "roles" and "permissions".
Odds are I'll never support "permissions" as a concept in CSLA. I say this, because .NET supports a role-based model and I'm following their lead.
However, WCF introduces a claims-based model, and if that becomes more pervasive I could see providing some support for that - if needed. Right now the only infrastructure to support claims is in WCF though (System.IdentityModel and System.ServiceModel), and this model sits alongside the role model, so it isn't at all clear that CSLA needs to do anything extra to support the concept within a WCF service implementation.
Reusable .NET code must be role-based, because that's the only universal model. WCF service code can be claims based, but that can't extend into a business library without locking that library for use only by WCF...
The same would be true of a permissions model. A business library written against such a model could only work within your custom app environment, because there's no broader infrastructure support by .NET, WCF or anything else for such a model.
Copyright (c) Marimer LLC