Customizing Authorization

Customizing Authorization

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


rvlc05 posted on Thursday, February 28, 2008

I am new to CSLA and am developing an employee information management application. Each Employee is assigned to one of many Sites. Each Employee has (at least) one Supervisor and may have one or more ProjectManagers. The Employee, her Supervisor(s), and her ProjectManager(s) must belong to the same Site.

My challenge is that I have what appears to be three different types of Roles to be implemented.

The first role type is of global scope and the actions granted to these roles apply to all Employees. The management of authorizations for these roles can be handled by the PTracker model.

The actions granted to the second role type are based on one or more Sites assigned to the user for this role. For instance, an Employee object authorizes the RegionChief role only if the Employee's Site is assigned to this RegionChief.

The third type of role is similar to the second except it is based on the Employees assigned to the user. For instance, an Employee object authorizes the Supervisor role only if the Employee is assign to this Supervisor.

I guess I'm asking for some advice on how to gracefully integrate the second and third role types using modifications of the model provided in the PTracker.

Thanks for your help.

RockfordLhotka replied on Thursday, February 28, 2008

You are describing something other than role-based authorization.

Which is fine - you can override CanReadProperty and CanWriteProperty to accomodate arbitrary authorization rules at the property level - in addition to the existing role-based functionality.

In other words, it sounds like you do have normal role-based rules and can use the existing functionality for that. Then you can add extra functionality for the relationship-based rules:

public override bool CanReadProperty(string propertyName)
{
  if (base.CanReadProperty(propertyName))
  {
    // do your relationship-based checks here
  }
  else
    return false;
}

 

Copyright (c) Marimer LLC