Athorization in CSLA 4

Athorization in CSLA 4

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


Mar72Vin posted on Wednesday, April 10, 2013

Hi,

I am transitioning from CSLA3 to 4. The new eBooks only really talk about IsInRole. I liked how the old CSLA used AccessGroups and Roles.

i.e. "Administrator" group access could have many "Role" types. "Job_Read", "Job_Write", "Task_Read", "Role_thatAllowsYouToDoSomethingElse".

 

The new membership seems to just have Roles categorized like "Administrator", "Power User", "Standard User"...

 

//Here is a standard way to set authorization permission for a user to read the "CityProperty" in CSLA4

BusinessRules.AddRule(new Csla.Rules.CommonRules.IsInRole( Csla.Rules.AuthorizationActions.ReadProperty, CityProperty, "Administrator", "Power User"));

 

//The old CSLA 3 would  do something like this, where "CityName_Read" is a role type the user is in.

AuthorizationRules.AllowRead("CityName", "CityName_Read");

 

In the CSLA3 way, both Administrator and PowerUser could be in the "CityName_read" role.

 

Is it possible to mimic the way CSLA3 handled Authorization? Perhaps making a custom rule for each and every property? (could be quite time prohibitive doing it this way?)

 

Cheers,

Tim

 

 


Actually.... thinking back to when I first setup my original CSLA 3 project I may have just blurred the use of "Role" by labeling each role like "CityName_Read", "CityName_Write", etc.... then implemented my own List for "AccessGroup" and "IsInAccessGroup" method in the Identity object.

Can anyone see any performance issues with having a huge number of "Roles" loaded into the Identity object? Using many roles in an MVC stateless environment may slow things down a little?

(it was a long time ago)...

JonnyBee replied on Wednesday, April 10, 2013

The Autorization part works just the same as before -  so this is just as valid for CSLA 4:

http://www.lhotka.net/weblog/PermissionbasedAuthorizationVsRolebasedAuthorization.aspx  

I wouldn't worry so much about loading many roles - just to make sure that loading is very efficient and maybe cached on the server.

 

 

skagen00 replied on Wednesday, April 10, 2013

As a suggestion, our roles are enumerated in an enumeration and we store them as a bit array in order of the enumeration on the identity.  Since it's passed on each call I would echo Jonny in keeping it efficient and lightweight.

 

Mar72Vin replied on Wednesday, April 10, 2013

Hi skagen00, The enumeration sounds interesting. Does it make the code any less readable doing it your way?

skagen00 replied on Wednesday, April 10, 2013

No not at all, because IsInRole is just what is exposed and the implementation to handle the bit array is encapsulated within the identity/principal.

Since it's an enumeration, IsInRole is called with our RolePermission enumeration values.

The method on our identity (we end up actually invoking it w/ an enumeration on a static class, not usually directly) looks like this.  Permissions is our bit array.

         bool ICheckRoles.IsInRole(string permissionName)
        {
            if (String.IsNullOrWhiteSpace(permissionName))
            {
                return false;
            }

            RolePermissions permission;
            if (!Enum.TryParse<RolePermissions>(permissionName, out permission))
            {
                return false;
            }

            int index = (int)permission;
            if (index < 0 || index >= Permissions.Length)
            {
                return false;
            }

            return Permissions[index];
        }

 

Mar72Vin replied on Wednesday, April 10, 2013

Hi JonnyBee, Thanks for the response and the link, This is exactly how I have previously implemented permissions. I had just forgotten that I took this tact.

It's great to know that it is also a recommended solution.

Copyright (c) Marimer LLC