A simple Permission based Architechture/RBAC/Permission control system with CSLA

Hello

In this post i am going to explain a simple permission based architechture with csla and to achive the RBAC i.e role based access control system.

taking the project tracker example from csla , we move ahead with a couple of new tables in security database .
1. Object tables (id, Objectname) - contains the name of all the editable busines objects
2. Permission tables (id,PermissionName)- contains the name of all the actions that can be performed (add,update,delete)
3.Roles (id,rolename)-the role master table
4.objectpermission (objectid,permissionid)-comibination of object and permission that can be performed validated against a object
4.RolePermissions(roleid,objectidPermissionID)-permissions being applied to role.

now getting on to the PTIdentity class , we customise it a little bit as follows
        private Hashtable _UserRights=new Hashtable() ; //hashtable to store userrights i.e rolepermission as the user belong to some role .
  public Hashtable UserRights
    {
        get { return _UserRights; }
    }

//and a simple function with
 /// <summary>
    /// checks whether the user has the permission
    /// </summary>
    /// <param name="Permission">the specific permission to check for</param>
    /// <returns></returns>
    public bool HasPermission(string Permission)
    {

        //read the userrights hash table
          return UserRights.ContainsValue(Permission);
    }


//now customisting the getidentiy function of PTPrincipal
// in this function the procedure used to validate the user also do returns the unique rights of the roles to //which the user belongs and we poplulate the hashtable for userrights with that resultset.
 
 private void DataPortal_Fetch(Criteria criteria)
    {
      using (SqlConnection cn =
        new SqlConnection(Database.DTCConnection))
      {
        cn.Open();
        using (SqlCommand cm = cn.CreateCommand())
        {
            //will authenticate the user and make the hashtable of user information and rights
            cm.CommandText = "spUser_Validate";
            cm.CommandType = CommandType.StoredProcedure;
            cm.Parameters.AddWithValue("@UserName", criteria.Username);
            cm.Parameters.AddWithValue("@Password", criteria.Password);



          using (SqlDataReader dr = cm.ExecuteReader())
          {
            if (dr.Read())
            {
              _name = criteria.Username;
              _isAuthenticated = true;
          
              //reading the user rights and making the hashtable of them .
              if (dr.NextResult())
              {
                  while (dr.Read())
                  {
                      _UserRights.Add(dr.GetInt32(0), dr.GetString(1));   
                  }
              }
          

        
            else
            {
              _name = string.Empty;
              _isAuthenticated = false;
              _roles.Clear();
            }
          }
        }
      }
    }
 

the ptidentity class is over and complete to use

now moving to the part of PTPrincipal
we do add a public static function named HasPermission as

 /// <summary>
        /// checks whether the user has the permission
        /// </summary>
        /// <param name="Permission">the specific permission to check for</param>
        /// <returns></returns>
        public static bool HasPermission(string Permission)
        {
    
                return ((PTIdentity)Csla.ApplicationContext.User.Identity).HasPermission( Permission);
          
        }


now we are done with at the PTPrincipal and PTIdentity class

moving to the objects level .
we now do modify the code as

 public static bool CanAddObject()
    {
     return PTPrincipal.HasPermission("Create User")
    }

    public static bool CanGetObject()
    {
      return PTPrincipal.HasPermission("View User")
    }

public static bool CanDeleteObject()
    {
      return PTPrincipal.HasPermission("Delete User")
    }

and goes so on with all other custom actions which we want to perform on the object .

for passing tbe permissions we can use up a resource file and customise it so as to it do matches with the returned result set of permissions by spuser_validate.

thats it , and we are done with a full fledged RBAC implementation with CSLA .

Hopes it helps.

Request Rocky to give his valuable comments / suggestions on the same.

Thanks
govind

along with it u need to maintain the role id in usertables if 1:1 relation in roles and users is there and if there is many:1 relation in roles and users then maintain a table separate for userinroles with (userid,roleid) structure .

for my requirement i had move ahead with a 1:1 relation coz now its RBAC so no many:1 role relationship is required any more .

the spuser_validate procedure looks like this .
create procedure spUser_Validate
    -- Add the parameters for the stored procedure here
        @UserName nvarchar(50),
        @Password nvarchar(128)

AS
--Declare local variables
    Declare @ErrString     VARCHAR(1000)
    Declare @iRows        INT
    Declare    @MyError INT
    declare @Status int
    DECLARE @iid INT

BEGIN
   
    SELECT username FROM  users WHERE susername=@UserName and password=@password
    --result set of rights
    select distinct permissionid,(objectname + permissionname) from rolepermissions where roleid in
    (select roleid from userinroles where userid=(select userid from users where username=@username))

i will post the complete working sample with the sqlscripts , modified ptprincipal,ptidentity and objects as is .


Govind

Hi Govind
This is very helpful . Can you please post more detailed implementation. Can you clarify more on "2. Permission tables (id,PermissionName)- contains the name of all the actions that can be performed (add,update,delete)"
Do you mean you will populate Permission able with Add, view and delete for all objects ?.
Thanks     

Hi,

Yes . we will populate the permission table with the add, view ,update,delte etc permissions at object level .

samplet entry would be like this . id(identity),Permission Name

1,Add

2,Update

3,delete

4,authorise

5,view

.....

this way as many as activities you think , you can create them and here the beauty of the objectpermission table i.e point 4 , is that the objects are free to implement any of the activities listed above .so just maintain these tables and have fun with RBAC ,

 

thanks

govind

Thanks I got it to work